aboutsummaryrefslogtreecommitdiff
path: root/src/Type.zig
AgeCommit message (Collapse)Author
2025-04-02compiler: allow `@import` of ZON without a result typeMason Remaley
In particular, this allows importing `build.zig.zon` at comptime.
2025-03-21x86_64: rewrite wrapping multiplicationJacob Young
2025-03-07std.zig.Ast: improve type safetyTechatrix
This commits adds the following distinct integer types to std.zig.Ast: - OptionalTokenIndex - TokenOffset - OptionalTokenOffset - Node.OptionalIndex - Node.Offset - Node.OptionalOffset The `Node.Index` type has also been converted to a distinct type while `TokenIndex` remains unchanged. `Ast.Node.Data` has also been changed to a (untagged) union to provide safety checks.
2025-02-22Dwarf: fix lowering of comptime-only optional pointer `null` valuesJacob Young
Closes #22974
2025-02-22Type: resolve union tag type before checking for runtime bitsDavid Rubin
2025-02-22zig build fmtAndrew Kelley
2025-02-22Sema: Fix fnptr alignment safety checks to account for potential ISA tag.Alex Rønne Petersen
As seen on e.g. Arm/Thumb and MIPS (MIPS16/microMIPS). Fixes #22888.
2025-02-17std.Target: Remove Cpu.Arch.propeller2 and use a CPU feature instead.Alex Rønne Petersen
2025-02-17std.Target: Remove Cpu.Arch.spu_2.Alex Rønne Petersen
This was for a hobby project that appears to be dormant for now. This can be added back if the project is resumed in the future.
2025-02-15x86_64: implement error set and enum safetyJacob Young
This is all of the expected 0.14.0 progress on #21530, which can now be postponed once this commit is merged. This required rewriting the (un)wrap operations since the original implementations were extremely buggy. Also adds an easy way to retrigger Sema OPV bugs so that I don't have to keep updating #22419 all the time.
2025-02-04Zcu: remove `*_loaded` fields on `File`mlugg
Instead, `source`, `tree`, and `zir` should all be optional. This is precisely what we're actually trying to model here; and `File` isn't optimized for memory consumption or serializability anyway, so it's fine to use a couple of extra bytes on actual optionals here.
2025-02-01Merge pull request #22672 from jacobly0/x86_64-rewriteAndrew Kelley
x86_64: rewrite float conversions
2025-02-01Sema: skip aliasing check and runtime operation for `@memcpy` of zero-bit typemlugg
This check isn't valid in such cases, because the source and destination pointers both refer to zero bits of memory, meaning they effectively never alias. Resolves: #21655
2025-01-31x86_64: rewrite float vector conversionsJacob Young
2025-01-29Sema: `@memcpy` changesmlugg
* The langspec definition of `@memcpy` has been changed so that the source and destination element types must be in-memory coercible, allowing all such calls to be raw copying operations, not actually applying any coercions. * Implement aliasing check for comptime `@memcpy`; a compile error will now be emitted if the arguments alias. * Implement more efficient comptime `@memcpy` by loading and storing a whole array at once, similar to how `@memset` is implemented.
2025-01-24x86_64: rewrite scalar and vector int `@min` and `@max`Jacob Young
2025-01-24x86_64: rewrite float vector `@abs` and equality comparisonsJacob Young
2025-01-21compiler: simplify generic functions, fix issues with inline callsmlugg
The original motivation here was to fix regressions caused by #22414. However, while working on this, I ended up discussing a language simplification with Andrew, which changes things a little from how they worked before #22414. The main user-facing change here is that any reference to a prior function parameter, even if potentially comptime-known at the usage site or even not analyzed, now makes a function generic. This applies even if the parameter being referenced is not a `comptime` parameter, since it could still be populated when performing an inline call. This is a breaking language change. The detection of this is done in AstGen; when evaluating a parameter type or return type, we track whether it referenced any prior parameter, and if so, we mark this type as being "generic" in ZIR. This will cause Sema to not evaluate it until the time of instantiation or inline call. A lovely consequence of this from an implementation perspective is that it eliminates the need for most of the "generic poison" system. In particular, `error.GenericPoison` is now completely unnecessary, because we identify generic expressions earlier in the pipeline; this simplifies the compiler and avoids redundant work. This also entirely eliminates the concept of the "generic poison value". The only remnant of this system is the "generic poison type" (`Type.generic_poison` and `InternPool.Index.generic_poison_type`). This type is used in two places: * During semantic analysis, to represent an unknown result type. * When storing generic function types, to represent a generic parameter/return type. It's possible that these use cases should instead use `.none`, but I leave that investigation to a future adventurer. One last thing. Prior to #22414, inline calls were a little inefficient, because they re-evaluated even non-generic parameter types whenever they were called. Changing this behavior is what ultimately led to #22538. Well, because the new logic will mark a type expression as generic if there is any change its resolved type could differ in an inline call, this redundant work is unnecessary! So, this is another way in which the new design reduces redundant work and complexity. Resolves: #22494 Resolves: #22532 Resolves: #22538
2025-01-21Sema: fix `is_non_null_ptr` handling for runtime-known pointersmlugg
We can still often determine a comptime result based on the type, even if the pointer is runtime-known. Also, we previously used load -> is non null instead of AIR `is_non_null_ptr` if the pointer is comptime-known, but that's a bad heuristic. Instead, we should check for the pointer to be comptime-known, *and* for the load to be comptime-known, and only in that case should we call `Sema.analyzeIsNonNull`. Resolves: #22556
2025-01-16x86_64: implement a custom calling convention for the Zig languageJacob Young
2025-01-16x86_64: implement fallback for pcmpeqqJacob Young
2025-01-16all: update to `std.builtin.Type.Pointer.Size` field renamesmlugg
This was done by regex substitution with `sed`. I then manually went over the entire diff and fixed any incorrect changes. This diff also changes a lot of `callconv(.C)` to `callconv(.c)`, since my regex happened to also trigger here. I opted to leave these changes in, since they *are* a correct migration, even if they're not the one I was trying to do!
2025-01-15frontend: add const to more Zcu pointersAndrew Kelley
2025-01-14Type: `struct {}` does not have a well-defined layoutmlugg
`Type.hasWellDefinedLayout` was in disagreement with pointer loading logic about auto-layout structs with zero fields, `struct {}`. For consistency, these types should not have a well-defined layout. This is technically a breaking change.
2024-12-24compiler: remove Caumlugg
The `Cau` abstraction originated from noting that one of the two primary roles of the legacy `Decl` type was to be the subject of comptime semantic analysis. However, the data stored in `Cau` has always had some level of redundancy. While preparing for #131, I went to remove that redundany, and realised that `Cau` now had exactly one field: `owner`. This led me to conclude that `Cau` is, in fact, an unnecessary level of abstraction over what are in reality *fundamentally different* kinds of analysis unit (`AnalUnit`). Types, `Nav` vals, and `comptime` declarations are all analyzed in different ways, and trying to treat them as the same thing is counterproductive! So, these 3 cases are now different alternatives in `AnalUnit`. To avoid stealing bits from `InternPool`-based IDs, which are already a little starved for bits due to the sharding datastructures, `AnalUnit` is expanded to 64 bits (30 of which are currently unused). This doesn't impact memory usage too much by default, because we don't store `AnalUnit`s all too often; however, we do store them a lot under `-fincremental`, so a non-trivial bump to peak RSS can be observed there. This will be improved in the future when I made `InternPool.DepEntry` less memory-inefficient. `Zcu.PerThread.ensureCauAnalyzed` is split into 3 functions, for each of the 3 new types of `AnalUnit`. The new logic is much easier to understand, because it avoids conflating the logic of these fundamentally different cases.
2024-12-20lldb: add pretty printer for intern pool indicesJacob Young
2024-12-16Dwarf: include comptime-only values in debug infoJacob Young
2024-11-29compiler: use `@Type` instead of `@TypeOf` to print enum literal typemlugg
2024-10-31compiler: remove anonymous struct types, unify all tuplesmlugg
This commit reworks how anonymous struct literals and tuples work. Previously, an untyped anonymous struct literal (e.g. `const x = .{ .a = 123 }`) was given an "anonymous struct type", which is a special kind of struct which coerces using structural equivalence. This mechanism was a holdover from before we used RLS / result types as the primary mechanism of type inference. This commit changes the language so that the type assigned here is a "normal" struct type. It uses a form of equivalence based on the AST node and the type's structure, much like a reified (`@Type`) type. Additionally, tuples have been simplified. The distinction between "simple" and "complex" tuple types is eliminated. All tuples, even those explicitly declared using `struct { ... }` syntax, use structural equivalence, and do not undergo staged type resolution. Tuples are very restricted: they cannot have non-`auto` layouts, cannot have aligned fields, and cannot have default values with the exception of `comptime` fields. Tuples currently do not have optimized layout, but this can be changed in the future. This change simplifies the language, and fixes some problematic coercions through pointers which led to unintuitive behavior. Resolves: #16865
2024-10-25Merge pull request #21710 from alexrp/function-alignmentAlex Rønne Petersen
Some improvements to the compiler's handling of function alignment
2024-10-20compiler: Remove uses of defaultFunctionAlignment() in the frontend.Alex Rønne Petersen
minFunctionAlignment() is something we can know ahead of time for any given target because it's a matter of ABI. However, defaultFunctionAlignment() is a matter of optimization and every backend can do it differently depending on any number of factors. For example, LLVM will base the choice on the CPU model in its aarch64 backend. So just don't use this value in the frontend.
2024-10-19std.Target: rename `defaultCCallingConvention` and `Cpu.Arch.fromCallconv`mlugg
2024-10-19test: update for `CallingConvention` changesmlugg
This also includes some compiler and std changes to correct error messages which weren't properly updated before.
2024-10-19std: update for new `CallingConvention`mlugg
The old `CallingConvention` type is replaced with the new `NewCallingConvention`. References to `NewCallingConvention` in the compiler are updated accordingly. In addition, a few parts of the standard library are updated to use the new type correctly.
2024-10-19compiler: introduce new `CallingConvention`mlugg
This commit begins implementing accepted proposal #21209 by making `std.builtin.CallingConvention` a tagged union. The stage1 dance here is a little convoluted. This commit introduces the new type as `NewCallingConvention`, keeping the old `CallingConvention` around. The compiler uses `std.builtin.NewCallingConvention` exclusively, but when fetching the type from `std` when running the compiler (e.g. with `getBuiltinType`), the name `CallingConvention` is used. This allows a prior build of Zig to be used to build this commit. The next commit will update `zig1.wasm`, and then the compiler and standard library can be updated to completely replace `CallingConvention` with `NewCallingConvention`. The second half of #21209 is to remove `@setAlignStack`, which will be implemented in another commit after updating `zig1.wasm`.
2024-10-12implement packed struct equality (#21679)David Rubin
2024-10-04Adds new cpu architectures propeller1 and propeller2. (#21563)Felix Queißner
* Adds new cpu architectures propeller1 and propeller2. These cpu architectures allow targeting the Parallax Propeller 1 and Propeller 2, which are both very special microcontrollers with 512 registers and 8 cpu cores. Resolves #21559 * Adds std.elf.EM.PROPELLER and std.elf.EM.PROPELLER2 * Fixes missing switch prongs in src/codegen/llvm.zig * Fixes order in std.Target.Arch --------- Co-authored-by: Felix "xq" Queißner <git@random-projects.net>
2024-09-26remove formatted panicsAndrew Kelley
implements #17969
2024-09-23std.Target: Remove Cpu.Arch.dxil and ObjectFormat.dxcontainer.Alex Rønne Petersen
See: https://devblogs.microsoft.com/directx/directx-adopting-spir-v Since we never hooked up the (experimental) DirectX LLVM backend, we've never actually supported targeting DXIL in Zig. With Microsoft moving away from DXIL, that seems very unlikely to change.
2024-09-17Sema: clean up cmpNumericmlugg
There is one minor language change here, which is that comparisons of the form `comptime_inf < runtime_f32` have their results comptime-known. This is consistent with comparisons against comptime NaN for instance, which are always comptime known. A corresponding behavior test is added. This fixes a bug with int comparison elision which my previous commit somehow triggered. `Sema.compareIntsOnlyPossibleResult` is much cleaner now!
2024-08-28std: update `std.builtin.Type` fields to follow naming conventionsmlugg
The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-26remove some stale codeDavid Rubin
- Don't create an `inner_sema` in `unionFields` - Remove assertions of the sema owner, when we literally just set it
2024-08-25fix up merge conflicts with masterDavid Rubin
2024-08-25sema: `resolve{Struct,Union}Inner` don't throw away SemasDavid Rubin
before this, calls to `resolveTypeFieldsStruct` (now renamed to the more correct `resolveStructFieldTypes`) would just throw away the sema that `resolveStructInner` created and create its own. There is no reason to do this, and we fix it to preserve the sema through it all.
2024-08-25remove `mod` aliases for ZcusDavid Rubin
2024-08-25sema: clean-up `{union,struct}FieldAlignment` and friendsDavid Rubin
My main gripes with this design were that it was incorrectly namespaced, the naming was inconsistent and a bit wrong (`fooAlign` vs `fooAlignment`). This commit moves all the logic from `PerThread.zig` to use the zcu + tid system that the previous couple commits introduce. I've organized and merged the functions to be a bit more specific to their own purpose. - `fieldAlignment` takes a struct or union type, an index, and a Zcu (or the Sema version which takes a Pt), and gives you the alignment of the field at the index. - `structFieldAlignment` takes the field type itself, and provides the logic to handle special cases, such as externs. A design goal I had in mind was to avoid using the word 'struct' in the function name, when it worked for things that aren't structs, such as unions.
2024-08-25sema: rework type resolution to use Zcu when possibleDavid Rubin
2024-08-22Type: fix inconsistency between `zig fmt` and `@typeName`Jacob Young
2024-08-18Zir: add instructions to fetch std.builtin typesmlugg
This replaces the constant `Zir.Inst.Ref` tags (and the analagous tags in `Air.Inst.Ref`, `InternPool.Index`) referring to types in `std.builtin` with a ZIR instruction `extended(builtin_type(...))` which instructs Sema to fetch such a type, effectively as if it were a shorthand for the ZIR for `@import("std").builtin.xyz`. Previously, this was achieved through constant tags in `Ref`. The analagous `InternPool` indices began as `simple_type` values, and were later rewritten to the correct type information. This system was kind of brittle, and more importantly, isn't compatible with incremental compilation of std, since incremental compilation relies on the ability to recreate types at different indices when they change. Replacing the old system with this instruction slightly increases the size of ZIR, but it simplifies logic and allows incremental compilation to work correctly on the standard library. This shouldn't have a significant impact on ZIR size or compiler performance, but I will take measurements in the PR to confirm this.
2024-08-17frontend: incremental progressmlugg
This commit makes more progress towards incremental compilation, fixing some crashes in the frontend. Notably, it fixes the regressions introduced by #20964. It also cleans up the "outdated file root" mechanism, by virtue of deleting it: we now detect outdated file roots just after updating ZIR refs, and re-scan their namespaces.