authorgravatar for tensorush@gmail.comZhora Trush <tensorush@gmail.com> 2022-09-24 21:42:00+03:00
committergravatar for git@vexu.euVeikka Tuominen <git@vexu.eu> 2022-09-27 13:22:57+03:00
logf7f15e99c418ab0efac268e9087ce45d55744edc
tree6a952aa8e7e0a9002a19dc606a31c380fc11d4c2
parente915b905e0d5e397cc298abee1c34cda357bb573

Fix minor langref typos

1 files changed, 11 insertions(+), 14 deletions(-)

doc/langref.html.in+11-14
......@@ -6499,7 +6499,7 @@ export fn entry() void {
64996499 14: 5d pop %rbp
65006500 15: c3 retq </code></pre>
65016501 <p>These assembly instructions do not have any code associated with the void values -
6502 they only perform the function call prologue and epilog.</p>
6502 they only perform the function call prologue and epilogue.</p>
65036503
65046504 {#header_open|void#}
65056505 <p>
......@@ -8334,9 +8334,6 @@ test "main" {
83348334}
83358335 {#code_end#}
83368336 <p>
8337 will output:
8338 </p>
8339 <p>
83408337 If all {#syntax#}@compileLog{#endsyntax#} calls are removed or
83418338 not encountered by analysis, the
83428339 program compiles successfully and the generated executable prints:
......@@ -8679,7 +8676,7 @@ fn func() void {
86798676 This function returns the base pointer of the current stack frame.
86808677 </p>
86818678 <p>
8682 The implications of this are target specific and not consistent across all
8679 The implications of this are target-specific and not consistent across all
86838680 platforms. The frame address may not be available in release mode due to
86848681 aggressive optimizations.
86858682 </p>
......@@ -8768,10 +8765,10 @@ test "@hasDecl" {
87688765 </p>
87698766 <ul>
87708767 <li>{#syntax#}@import("std"){#endsyntax#} - Zig Standard Library</li>
8771 <li>{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information
8768 <li>{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information.
87728769 The command <code>zig build-exe --show-builtin</code> outputs the source to stdout for reference.
87738770 </li>
8774 <li>{#syntax#}@import("root"){#endsyntax#} - Points to the root source file
8771 <li>{#syntax#}@import("root"){#endsyntax#} - Points to the root source file.
87758772 This is usually <code>src/main.zig</code> but it depends on what file is chosen to be built.
87768773 </li>
87778774 </ul>
......@@ -9012,7 +9009,7 @@ test "@wasmMemoryGrow" {
90129009 <p>
90139010 This builtin tells the compiler to emit a prefetch instruction if supported by the
90149011 target CPU. If the target CPU does not support the requested prefetch instruction,
9015 this builtin is a noop. This function has no effect on the behavior of the program,
9012 this builtin is a no-op. This function has no effect on the behavior of the program,
90169013 only on the performance characteristics.
90179014 </p>
90189015 <p>
......@@ -9094,7 +9091,7 @@ pub const PrefetchOptions = struct {
90949091 when the current function returns.
90959092 </p>
90969093 <p>
9097 The implications of this are target specific and not consistent across
9094 The implications of this are target-specific and not consistent across
90989095 all platforms.
90999096 </p>
91009097 <p>
......@@ -9281,7 +9278,7 @@ test "@setRuntimeSafety" {
92819278 Each element in {#syntax#}mask{#endsyntax#} selects an element from either {#syntax#}a{#endsyntax#} or
92829279 {#syntax#}b{#endsyntax#}. Positive numbers select from {#syntax#}a{#endsyntax#} starting at 0.
92839280 Negative values select from {#syntax#}b{#endsyntax#}, starting at {#syntax#}-1{#endsyntax#} and going down.
9284 It is recommended to use the {#syntax#}~{#endsyntax#} operator from indexes from {#syntax#}b{#endsyntax#}
9281 It is recommended to use the {#syntax#}~{#endsyntax#} operator for indexes from {#syntax#}b{#endsyntax#}
92859282 so that both indexes can start from {#syntax#}0{#endsyntax#} (i.e. {#syntax#}~@as(i32, 0){#endsyntax#} is
92869283 {#syntax#}-1{#endsyntax#}).
92879284 </p>
......@@ -9721,7 +9718,7 @@ test "integer truncation" {
97219718 </p>
97229719 <p>
97239720 Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and
9724 {#link|error sets|Error Set Type#} has fields which are are guaranteed to be in the same
9721 {#link|error sets|Error Set Type#} has fields which are guaranteed to be in the same
97259722 order as appearance in the source file.
97269723 </p>
97279724 <p>
......@@ -10545,7 +10542,7 @@ fn concat(allocator: Allocator, a: []const u8, b: []const u8) ![]u8 {
1054510542 {#syntax#}FixedBufferAllocator{#endsyntax#}, which is then passed to a function.
1054610543 As a convenience there is a global {#syntax#}FixedBufferAllocator{#endsyntax#}
1054710544 available for quick tests at {#syntax#}std.testing.allocator{#endsyntax#},
10548 which will also do perform basic leak detection.
10545 which will also perform basic leak detection.
1054910546 </p>
1055010547 <p>
1055110548 Zig has a general purpose allocator available to be imported
......@@ -11079,7 +11076,7 @@ pub fn main() void {
1107911076 <p>
1108011077 C Translation makes a best-effort attempt to translate function-like macros into equivalent
1108111078 Zig functions. Since C macros operate at the level of lexical tokens, not all C macros
11082 can be translated to Zig. Macros that cannot be translated will be be demoted to
11079 can be translated to Zig. Macros that cannot be translated will be demoted to
1108311080 {#syntax#}@compileError{#endsyntax#}. Note that C code which <em>uses</em> macros will be
1108411081 translated without any additional issues (since Zig operates on the pre-processed source
1108511082 with macros expanded). It is merely the macros themselves which may not be translatable to
......@@ -11138,7 +11135,7 @@ pub const MAKELOCAL = @compileError("unable to translate C expr: unexpected toke
1113811135 please!</li>
1113911136 </ul>
1114011137 <p>When a C pointer is pointing to a single struct (not an array), dereference the C pointer to
11141 access to the struct's fields or member data. That syntax looks like
11138 access the struct's fields or member data. That syntax looks like
1114211139 this: </p>
1114311140 <p>{#syntax#}ptr_to_struct.*.struct_member{#endsyntax#}</p>
1114411141 <p>This is comparable to doing {#syntax#}->{#endsyntax#} in C.</p>