mirror of
https://codeberg.org/ziglang/zig.git
synced 2025-12-06 13:54:21 +00:00
Fix minor langref typos
This commit is contained in:
parent
e915b905e0
commit
f7f15e99c4
1 changed files with 11 additions and 14 deletions
|
|
@ -6499,7 +6499,7 @@ export fn entry() void {
|
|||
14: 5d pop %rbp
|
||||
15: c3 retq </code></pre>
|
||||
<p>These assembly instructions do not have any code associated with the void values -
|
||||
they only perform the function call prologue and epilog.</p>
|
||||
they only perform the function call prologue and epilogue.</p>
|
||||
|
||||
{#header_open|void#}
|
||||
<p>
|
||||
|
|
@ -8334,9 +8334,6 @@ test "main" {
|
|||
}
|
||||
{#code_end#}
|
||||
<p>
|
||||
will output:
|
||||
</p>
|
||||
<p>
|
||||
If all {#syntax#}@compileLog{#endsyntax#} calls are removed or
|
||||
not encountered by analysis, the
|
||||
program compiles successfully and the generated executable prints:
|
||||
|
|
@ -8679,7 +8676,7 @@ fn func() void {
|
|||
This function returns the base pointer of the current stack frame.
|
||||
</p>
|
||||
<p>
|
||||
The implications of this are target specific and not consistent across all
|
||||
The implications of this are target-specific and not consistent across all
|
||||
platforms. The frame address may not be available in release mode due to
|
||||
aggressive optimizations.
|
||||
</p>
|
||||
|
|
@ -8768,10 +8765,10 @@ test "@hasDecl" {
|
|||
</p>
|
||||
<ul>
|
||||
<li>{#syntax#}@import("std"){#endsyntax#} - Zig Standard Library</li>
|
||||
<li>{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information
|
||||
<li>{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information.
|
||||
The command <code>zig build-exe --show-builtin</code> outputs the source to stdout for reference.
|
||||
</li>
|
||||
<li>{#syntax#}@import("root"){#endsyntax#} - Points to the root source file
|
||||
<li>{#syntax#}@import("root"){#endsyntax#} - Points to the root source file.
|
||||
This is usually <code>src/main.zig</code> but it depends on what file is chosen to be built.
|
||||
</li>
|
||||
</ul>
|
||||
|
|
@ -9012,7 +9009,7 @@ test "@wasmMemoryGrow" {
|
|||
<p>
|
||||
This builtin tells the compiler to emit a prefetch instruction if supported by the
|
||||
target CPU. If the target CPU does not support the requested prefetch instruction,
|
||||
this builtin is a noop. This function has no effect on the behavior of the program,
|
||||
this builtin is a no-op. This function has no effect on the behavior of the program,
|
||||
only on the performance characteristics.
|
||||
</p>
|
||||
<p>
|
||||
|
|
@ -9094,7 +9091,7 @@ pub const PrefetchOptions = struct {
|
|||
when the current function returns.
|
||||
</p>
|
||||
<p>
|
||||
The implications of this are target specific and not consistent across
|
||||
The implications of this are target-specific and not consistent across
|
||||
all platforms.
|
||||
</p>
|
||||
<p>
|
||||
|
|
@ -9281,7 +9278,7 @@ test "@setRuntimeSafety" {
|
|||
Each element in {#syntax#}mask{#endsyntax#} selects an element from either {#syntax#}a{#endsyntax#} or
|
||||
{#syntax#}b{#endsyntax#}. Positive numbers select from {#syntax#}a{#endsyntax#} starting at 0.
|
||||
Negative values select from {#syntax#}b{#endsyntax#}, starting at {#syntax#}-1{#endsyntax#} and going down.
|
||||
It is recommended to use the {#syntax#}~{#endsyntax#} operator from indexes from {#syntax#}b{#endsyntax#}
|
||||
It is recommended to use the {#syntax#}~{#endsyntax#} operator for indexes from {#syntax#}b{#endsyntax#}
|
||||
so that both indexes can start from {#syntax#}0{#endsyntax#} (i.e. {#syntax#}~@as(i32, 0){#endsyntax#} is
|
||||
{#syntax#}-1{#endsyntax#}).
|
||||
</p>
|
||||
|
|
@ -9721,7 +9718,7 @@ test "integer truncation" {
|
|||
</p>
|
||||
<p>
|
||||
Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and
|
||||
{#link|error sets|Error Set Type#} has fields which are are guaranteed to be in the same
|
||||
{#link|error sets|Error Set Type#} has fields which are guaranteed to be in the same
|
||||
order as appearance in the source file.
|
||||
</p>
|
||||
<p>
|
||||
|
|
@ -10545,7 +10542,7 @@ fn concat(allocator: Allocator, a: []const u8, b: []const u8) ![]u8 {
|
|||
{#syntax#}FixedBufferAllocator{#endsyntax#}, which is then passed to a function.
|
||||
As a convenience there is a global {#syntax#}FixedBufferAllocator{#endsyntax#}
|
||||
available for quick tests at {#syntax#}std.testing.allocator{#endsyntax#},
|
||||
which will also do perform basic leak detection.
|
||||
which will also perform basic leak detection.
|
||||
</p>
|
||||
<p>
|
||||
Zig has a general purpose allocator available to be imported
|
||||
|
|
@ -11079,7 +11076,7 @@ pub fn main() void {
|
|||
<p>
|
||||
C Translation makes a best-effort attempt to translate function-like macros into equivalent
|
||||
Zig functions. Since C macros operate at the level of lexical tokens, not all C macros
|
||||
can be translated to Zig. Macros that cannot be translated will be be demoted to
|
||||
can be translated to Zig. Macros that cannot be translated will be demoted to
|
||||
{#syntax#}@compileError{#endsyntax#}. Note that C code which <em>uses</em> macros will be
|
||||
translated without any additional issues (since Zig operates on the pre-processed source
|
||||
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
|
|||
please!</li>
|
||||
</ul>
|
||||
<p>When a C pointer is pointing to a single struct (not an array), dereference the C pointer to
|
||||
access to the struct's fields or member data. That syntax looks like
|
||||
access the struct's fields or member data. That syntax looks like
|
||||
this: </p>
|
||||
<p>{#syntax#}ptr_to_struct.*.struct_member{#endsyntax#}</p>
|
||||
<p>This is comparable to doing {#syntax#}->{#endsyntax#} in C.</p>
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue