6ffa285fc3
This safety check was completely broken; it triggered unchecked illegal behavior *in order to implement the safety check*. You definitely can't do that! Instead, we must explicitly check the boundaries. This is a tiny bit fiddly, because we need to make sure we do floating-point rounding in the correct direction, and also handle the fact that the operation truncates so the boundary works differently for min vs max. Instead of implementing this safety check in Sema, there are now dedicated AIR instructions for safety-checked intfromfloat (two instructions; which one is used depends on the float mode). Currently, no backend directly implements them; instead, a `Legalize.Feature` is added which expands the safety check, and this feature is enabled for all backends we currently test, including the LLVM backend. The `u0` case is still handled in Sema, because Sema needs to check for that anyway due to the comptime-known result. The old safety check here was also completely broken and has therefore been rewritten. In that case, we just check for 'abs(input) < 1.0'. I've added a bunch of test coverage for the boundary cases of `@intFromFloat`, both for successes (in `test/behavior/cast.zig`) and failures (in `test/cases/safety/`). Resolves: #24161
Test Case Quick Reference
Use comments at the end of the file to indicate metadata about the test case. Here are examples of different kinds of tests:
Compile Error Test
If you want it to be run with zig test and match expected error messages:
// error
// is_test=true
//
// :4:13: error: 'try' outside function scope
Execution
This will do zig run on the code and expect exit code 0.
// run
Translate-c
If you want to test translating C code to Zig use translate-c:
// translate-c
// c_frontend=aro,clang
// target=x86_64-linux
//
// pub const foo = 1;
// pub const immediately_after_foo = 2;
//
// pub const somewhere_else_in_the_file = 3:
Run Translated C
If you want to test translating C code to Zig and then executing it use run-translated-c:
// run-translated-c
// c_frontend=aro,clang
// target=x86_64-linux
//
// Hello world!
Incremental Compilation
Make multiple files that have ".", and then an integer, before the ".zig" extension, like this:
hello.0.zig
hello.1.zig
hello.2.zig
Each file can be a different kind of test, such as expecting compile errors, or expecting to be run and exit(0). The test harness will use these to simulate incremental compilation.
At the time of writing there is no way to specify multiple files being changed as part of an update.
Subdirectories
Subdirectories do not have any semantic meaning but they can be used for organization since the test harness will recurse into them. The full directory path will be prepended as a prefix on the test case name.
Limiting which Backends and Targets are Tested
// run
// backend=stage2,llvm
// target=x86_64-linux,x86_64-macos
Possible backends are:
stage1: equivalent to-fstage1.stage2: equivalent to passing-fno-stage1 -fno-LLVM.llvm: equivalent to-fLLVM -fno-stage1.