| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add `--pass $mode` to compiletest through `./x.py`
Adds a flag `--pass $mode` to compiletest, which is exposed through `./x.py`.
When `--pass $mode` is passed, `{check,build,compile,run}-pass` tests will be forced to run under the given `$mode` unless the directive `// ignore-pass` exists in the test file.
The modes are explained in https://github.com/rust-lang/rust/pull/61778:
- `check` has the same effect as `cargo check`
- `build` or `compile` have the same effect as `cargo build`
- `run` has the same effect as `cargo run`
On my machine, `./x.py -i test src/test/run-pass --stage 1 --pass check` takes 38 seconds whereas it takes 2 min 7 seconds without `--pass check`.
cc https://github.com/rust-lang/rust/issues/61712
r? @petrochenkov
|
|
Refactor miri pointer checks
Centralize bounds, alignment and NULL checking for memory accesses in one function: `memory.check_ptr_access`. That function also takes care of converting a `Scalar` to a `Pointer`, should that be needed. Not all accesses need that though: if the access has size 0, `None` is returned. Everyone accessing memory based on a `Scalar` should use this method to get the `Pointer` they need.
All operations on the `Allocation` work on `Pointer` inputs and expect all the checks to have happened (and will ICE if the bounds are violated). The operations on `Memory` work on `Scalar` inputs and do the checks themselves.
The only other public method to check pointers is `memory.ptr_may_be_null`, which is needed in a few places. No need for `check_align` or similar methods. That makes the public API surface much easier to use and harder to mis-use.
This should be largely no-functional-change, except that ZST accesses to a "true" pointer that is dangling or out-of-bounds are now considered UB. This is to be conservative wrt. whatever LLVM might be doing.
While I am at it, this also removes the assumption that the vtable part of a `dyn Trait`-fat-pointer is a `Pointer` (as opposed to a pointer cast to an integer, stored as raw bits).
r? @oli-obk
|
|
|
|
compiletest: Introduce `// {check,build,run}-pass` pass modes
Pass UI tests now have three modes
```
// check-pass
// build-pass
// run-pass
```
mirroring equivalent well-known `cargo` commands.
`// check-pass` will compile the test skipping codegen (which is expensive and isn't supposed to fail in most cases).
`// build-pass` will compile and link the test without running it.
`// run-pass` will compile, link and run the test.
Tests without a "pass" annotation are still considered "fail" tests.
Most UI tests would probably want to switch to `check-pass`.
Tests validating codegen would probably want to run the generated code as well and use `run-pass`.
`build-pass` should probably be rare (linking tests?).
https://github.com/rust-lang/rust/pull/61755 will provide a way to run the tests with any mode, e.g. bump `check-pass` tests to `run-pass` to satisfy especially suspicious people, and be able to make sure that codegen doesn't breaks in some entirely unexpected way.
Tests marked with any mode are expected to pass with any other mode, if that's not the case for some legitimate reason, then the test should be made a "fail" test rather than a "pass" test.
Perhaps some secondary CI can verify this invariant, but that's not super urgent.
`// compile-pass` still works and is equivalent to `build-pass`.
Why is `// compile-pass` bad - 1) it gives an impression that the test is only compiled, but not linked, 2) it doesn't mirror a cargo command.
It can be removed some time in the future in a separate PR.
cc https://github.com/rust-lang/rust/issues/61712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add expected/provided byte alignments to validation error message
Fixes #58617
|
|
|
|
|
|
|
|
|
|
AFAICT, we do not have the same const-eval issues that we used to when
rust-lang/rust#23926 was filed. (Probably because of the switch to
miri for const-evaluation.)
|
|
fix validation range printing when encountering undef
|
|
|
|
|
|
|
|
|
|
r=nikomatsakis
Less conservative uninhabitedness check
Extends the uninhabitedness check to structs, non-empty enums, tuples and arrays.
Pulled out of #47291 and #50262.
Fixes https://github.com/rust-lang/rust/issues/54586.
r? @nikomatsakis
|
|
Fix various aspects around `let` bindings inside const functions
* forbid `let` bindings in const contexts that use short circuiting operators
* harden analysis code against derefs of mutable references
Initially this PR was about stabilizing `let` bindings, but too many flaws were exposed that need some more testing on nightly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow assignments in const contexts
fixes https://github.com/rust-lang/rust/issues/54098
fixes https://github.com/rust-lang/rust/issues/51251
fixes https://github.com/rust-lang/rust/issues/52613
|
|
|
|
|
|
|
|
|
|
Increase `Duration` approximate equal threshold to 1us
Previously this threshold when testing was 100ns, but the Windows
documentation states:
> which is a high resolution (<1us) time stamp
which presumably means that we could have up to 1us resolution, which
means that 100ns doesn't capture "equivalent" time intervals due to
various bits of rounding here and there.
It's hoped that this..
Closes #56034
|
