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 {...@@ -6499,7 +6499,7 @@ export fn entry() void {
6499 14: 5d pop %rbp6499 14: 5d pop %rbp
6500 15: c3 retq </code></pre>6500 15: c3 retq </code></pre>
6501 <p>These assembly instructions do not have any code associated with the void values -6501 <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
6504 {#header_open|void#}6504 {#header_open|void#}
6505 <p>6505 <p>
...@@ -8334,9 +8334,6 @@ test "main" {...@@ -8334,9 +8334,6 @@ test "main" {
8334}8334}
8335 {#code_end#}8335 {#code_end#}
8336 <p>8336 <p>
8337 will output:
8338 </p>
8339 <p>
8340 If all {#syntax#}@compileLog{#endsyntax#} calls are removed or8337 If all {#syntax#}@compileLog{#endsyntax#} calls are removed or
8341 not encountered by analysis, the8338 not encountered by analysis, the
8342 program compiles successfully and the generated executable prints:8339 program compiles successfully and the generated executable prints:
...@@ -8679,7 +8676,7 @@ fn func() void {...@@ -8679,7 +8676,7 @@ fn func() void {
8679 This function returns the base pointer of the current stack frame.8676 This function returns the base pointer of the current stack frame.
8680 </p>8677 </p>
8681 <p>8678 <p>
8682 The implications of this are target specific and not consistent across all8679 The implications of this are target-specific and not consistent across all
8683 platforms. The frame address may not be available in release mode due to8680 platforms. The frame address may not be available in release mode due to
8684 aggressive optimizations.8681 aggressive optimizations.
8685 </p>8682 </p>
...@@ -8768,10 +8765,10 @@ test "@hasDecl" {...@@ -8768,10 +8765,10 @@ test "@hasDecl" {
8768 </p>8765 </p>
8769 <ul>8766 <ul>
8770 <li>{#syntax#}@import("std"){#endsyntax#} - Zig Standard Library</li>8767 <li>{#syntax#}@import("std"){#endsyntax#} - Zig Standard Library</li>
8771 <li>{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information8768 <li>{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information.
8772 The command <code>zig build-exe --show-builtin</code> outputs the source to stdout for reference.8769 The command <code>zig build-exe --show-builtin</code> outputs the source to stdout for reference.
8773 </li>8770 </li>
8774 <li>{#syntax#}@import("root"){#endsyntax#} - Points to the root source file8771 <li>{#syntax#}@import("root"){#endsyntax#} - Points to the root source file.
8775 This is usually <code>src/main.zig</code> but it depends on what file is chosen to be built.8772 This is usually <code>src/main.zig</code> but it depends on what file is chosen to be built.
8776 </li>8773 </li>
8777 </ul>8774 </ul>
...@@ -9012,7 +9009,7 @@ test "@wasmMemoryGrow" {...@@ -9012,7 +9009,7 @@ test "@wasmMemoryGrow" {
9012 <p>9009 <p>
9013 This builtin tells the compiler to emit a prefetch instruction if supported by the9010 This builtin tells the compiler to emit a prefetch instruction if supported by the
9014 target CPU. If the target CPU does not support the requested prefetch instruction,9011 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,
9016 only on the performance characteristics.9013 only on the performance characteristics.
9017 </p>9014 </p>
9018 <p>9015 <p>
...@@ -9094,7 +9091,7 @@ pub const PrefetchOptions = struct {...@@ -9094,7 +9091,7 @@ pub const PrefetchOptions = struct {
9094 when the current function returns.9091 when the current function returns.
9095 </p>9092 </p>
9096 <p>9093 <p>
9097 The implications of this are target specific and not consistent across9094 The implications of this are target-specific and not consistent across
9098 all platforms.9095 all platforms.
9099 </p>9096 </p>
9100 <p>9097 <p>
...@@ -9281,7 +9278,7 @@ test "@setRuntimeSafety" {...@@ -9281,7 +9278,7 @@ test "@setRuntimeSafety" {
9281 Each element in {#syntax#}mask{#endsyntax#} selects an element from either {#syntax#}a{#endsyntax#} or9278 Each element in {#syntax#}mask{#endsyntax#} selects an element from either {#syntax#}a{#endsyntax#} or
9282 {#syntax#}b{#endsyntax#}. Positive numbers select from {#syntax#}a{#endsyntax#} starting at 0.9279 {#syntax#}b{#endsyntax#}. Positive numbers select from {#syntax#}a{#endsyntax#} starting at 0.
9283 Negative values select from {#syntax#}b{#endsyntax#}, starting at {#syntax#}-1{#endsyntax#} and going down.9280 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#}
9285 so that both indexes can start from {#syntax#}0{#endsyntax#} (i.e. {#syntax#}~@as(i32, 0){#endsyntax#} is9282 so that both indexes can start from {#syntax#}0{#endsyntax#} (i.e. {#syntax#}~@as(i32, 0){#endsyntax#} is
9286 {#syntax#}-1{#endsyntax#}).9283 {#syntax#}-1{#endsyntax#}).
9287 </p>9284 </p>
...@@ -9721,7 +9718,7 @@ test "integer truncation" {...@@ -9721,7 +9718,7 @@ test "integer truncation" {
9721 </p>9718 </p>
9722 <p>9719 <p>
9723 Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and9720 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 same9721 {#link|error sets|Error Set Type#} has fields which are guaranteed to be in the same
9725 order as appearance in the source file.9722 order as appearance in the source file.
9726 </p>9723 </p>
9727 <p>9724 <p>
...@@ -10545,7 +10542,7 @@ fn concat(allocator: Allocator, a: []const u8, b: []const u8) ![]u8 {...@@ -10545,7 +10542,7 @@ fn concat(allocator: Allocator, a: []const u8, b: []const u8) ![]u8 {
10545 {#syntax#}FixedBufferAllocator{#endsyntax#}, which is then passed to a function.10542 {#syntax#}FixedBufferAllocator{#endsyntax#}, which is then passed to a function.
10546 As a convenience there is a global {#syntax#}FixedBufferAllocator{#endsyntax#}10543 As a convenience there is a global {#syntax#}FixedBufferAllocator{#endsyntax#}
10547 available for quick tests at {#syntax#}std.testing.allocator{#endsyntax#},10544 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.
10549 </p>10546 </p>
10550 <p>10547 <p>
10551 Zig has a general purpose allocator available to be imported10548 Zig has a general purpose allocator available to be imported
...@@ -11079,7 +11076,7 @@ pub fn main() void {...@@ -11079,7 +11076,7 @@ pub fn main() void {
11079 <p>11076 <p>
11080 C Translation makes a best-effort attempt to translate function-like macros into equivalent11077 C Translation makes a best-effort attempt to translate function-like macros into equivalent
11081 Zig functions. Since C macros operate at the level of lexical tokens, not all C macros11078 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 to11079 can be translated to Zig. Macros that cannot be translated will be demoted to
11083 {#syntax#}@compileError{#endsyntax#}. Note that C code which <em>uses</em> macros will be11080 {#syntax#}@compileError{#endsyntax#}. Note that C code which <em>uses</em> macros will be
11084 translated without any additional issues (since Zig operates on the pre-processed source11081 translated without any additional issues (since Zig operates on the pre-processed source
11085 with macros expanded). It is merely the macros themselves which may not be translatable to11082 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...@@ -11138,7 +11135,7 @@ pub const MAKELOCAL = @compileError("unable to translate C expr: unexpected toke
11138 please!</li>11135 please!</li>
11139 </ul>11136 </ul>
11140 <p>When a C pointer is pointing to a single struct (not an array), dereference the C pointer to11137 <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 like11138 access the struct's fields or member data. That syntax looks like
11142 this: </p>11139 this: </p>
11143 <p>{#syntax#}ptr_to_struct.*.struct_member{#endsyntax#}</p>11140 <p>{#syntax#}ptr_to_struct.*.struct_member{#endsyntax#}</p>
11144 <p>This is comparable to doing {#syntax#}->{#endsyntax#} in C.</p>11141 <p>This is comparable to doing {#syntax#}->{#endsyntax#} in C.</p>