The TODO comment in safetyPanic mentions introducing the concept of
reference-counted decls. That sounds like Zig current semantics for
normal declarations. By placing the panic messages in builtin there is
no need for another concept in the compiler.
spirv: introduce SpvModule.Fn to generate function code into
spirv: assembler error message setup
spirv: runtime spec info
spirv: inline assembly tokenizer
spirv: inline assembly lhs result/opcode parsing
spirv: forgot to fmt
spirv: tokenize opcodes and assigned result-ids
spirv: operand parsing setup
spirv: assembler string literals
spirv: assembler integer literals
spirv: assembler value enums
spirv: assembler bit masks
spirv: update assembler to new asm air format
spirv: target 1.5 for now
Current vulkan sdk version (1.3.204) ships spirv tools targetting 1.5,
and so these do not work with binaries targetting 1.6 yet. In the
future, this version number should be decided by the target.
spirv: store operands in flat arraylist.
Instead of having dedicated Operand variants for variadic operands,
just flatten them and store them in the normal inst.operands list.
This is a little simpler, but is not easily decodable in the operand
data representation.
spirv: parse variadic assembly operands
spirv: improve assembler result-id tokenization
spirv: begin instruction processing
spirv: only remove decl if it was actually allocated
spirv: work around weird miscompilation
Seems like there are problems with switch in anonymous struct literals.
spirv: begin resolving some types in assembler
spirv: improve instruction processing
spirv: rename some types + process OpTypeInt
spirv: process OpTypeVector
spirv: process OpTypeMatrix and OpTypeSampler
spirv: add opcode class to spec, remove @exclude'd instructions
spirv: process more type instructions
spirv: OpTypeFunction
spirv: OpTypeOpaque
spirv: parse LiteralContextDependentNumber operands
spirv: emit assembly instruction into right section
spirv: parse OpPhi parameters
spirv: inline assembly inputs
spirv: also copy air types
spirv: inline assembly outputs
spirv: spir-v address spaces
spirv: basic vector constants/types and shuffle
spirv: assembler OpTypeImage
spirv: some stuff
spirv: remove spirv address spaces for now
* Update for the breaking changes to std.fs.path.resolve. This had a
happy side effect of deleting some error handling code which is no
longer needed.
* Introduce cache_exempt_flags field to CSourceFile. This is used only
for include directories when building libc++ and libc++abi which
depend only on the zig lib path.
* libc_include_dir_list is only added to the cache hash when it
contains directories which have been obtained from system probing. It
is exempt when the directories depend only on the zig lib path.
Before, cache manifest files would have absolute file paths. This is
problematic for two reasons:
* Absolute file paths are not portable. Some operating systems such as
WASI have trouble with them. The files themselves are less portable;
they cannot be migrated from one user's home directory to another's.
And finally they can break due to file paths exceeding maximum path
component size.
* They would prevent some advanced use cases of Zig, where the lib dir
has a different path in a different invocation but is ultimately the
same Zig version and lib directory as before.
This commit adds a new column that specifies the prefix directory for
each file. 0 is an escape hatch and has the previous behavior. The other
two prefixes introduced are zig lib directory, and the cache directory.
This means files in zig-cache manifests can reference files local to
these directories.
In practice, this means it is possible to use a different file path for
the zig lib directory in a subsequent run of zig and have it still take
advantage of the global cache, provided that the files inside remain
unchanged.
closes#13050
PR #12837 handled control flow for break and return, but I forgot
about `continue`. This is effectively another break, so we just
need another `.restore_err_ret_index` ZIR instruction.
Resolves#13618.
Closes#7484. Right now for UEFI targets an alignment
of 32 is being used for no reason other than support
a rare bytecode. As this is far from the standard case,
removing this alignment and using the default one,
as most toolchains do, should be the desired behavior.
I wasn't able to create a reduced test case for this but the reasoning
can be seen in `abiAlignmentAdvancedUnion` where if `strat` was lazy
`hasRuntimeBitsAdvanced` would be given `null` instead of `sema`
which would cause eager evaluation when it is not valid or desired.
This also modifies the inline assembly to be more optimizable - instead of
doing explicit movs, we instead communicate to LLVM which registers we
would like to, somehow, have the correct values. This is how the x86_64
code already worked and thus allows the code to be unified across the
two architectures.
As a bonus, I threw in x86 support.
There was no check for linker errors after flushing,
which meant that if the link failed the build would
continue and try to copy the non-existant exe, and
also write the manifest as if it had succeeded.
Also adds parsing of lld output, which is surfaced at the
end of the compilation with the other errors instead
of via stderr
