compile-time evaluation: detect writes through immutable pointers - #118324
Conversation
|
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_gcc cc @antoyo |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…<try> compile-time evaluation: detect writes through immutable pointers This has two motivations: - it unblocks rust-lang#116745 (and therefore takes a big step towards `const_mut_refs` stabilization), because we can now detect if the memory that we find in `const` can be interned as "immutable" - it would detect the UB that was uncovered in rust-lang#117905, which was caused by accidental stabilization of `copy` functions in `const` that can only be called with UB When UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with [the const-UB RFC](https://rust-lang.github.io/rfcs/3016-const-ub.html), meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without `const_mut_refs` -- the accidentally stabilized `copy` functions are the only way this can happen, so the crates that popped up in rust-lang#117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that uncovered have all been fixed in their respective crates already. I just hope perf works out.
| /// Returns the `AllocId` of this provenance. | ||
| #[inline(always)] | ||
| pub fn alloc_id(self) -> AllocId { | ||
| AllocId(NonZeroU64::new(self.0.get() & !IMMUTABLE_MASK).unwrap()) |
There was a problem hiding this comment.
We could use new_unchecked here, we have an invariant that the AllocId part of the provenance is always non-null. But let's first see if perf is fine without unsafe code.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
f25c190 to
7a4d651
Compare
7a4d651 to
37a50ac
Compare
| use rustc_span::edition::Edition; | ||
| use rustc_span::symbol::sym; | ||
|
|
||
| declare_lint_pass! { |
There was a problem hiding this comment.
I moved this to the top, it was in a random spot in the middle of the file which surely doesn't make a ton of sense.
|
Finished benchmarking commit (b5c17f8): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 674.277s -> 673.76s (-0.08%) |
7197e21 to
be1e481
Compare
commented
Nov 27, 2023
|
Right, so there is a regression in ctfe-stress. I was worried this might happen. I guess now comes the usual phase of doing random changes and seeing how they affect perf... |
be1e481 to
303872f
Compare
commented
Nov 27, 2023
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
commented
Dec 7, 2023
|
Finished benchmarking commit (0e7f91b): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 674.821s -> 675.63s (0.12%) |
commented
Dec 12, 2023
Agreed. |
This has two motivations:
const_mut_refsstabilization), because we can now detect if the memory that we find inconstcan be interned as "immutable"copyfunctions inconstthat can only be called with UBWhen UB is detected, we emit a future-compat warn-by-default lint. This is not a breaking change, so completely in line with the const-UB RFC, meaning we don't need t-lang FCP here. I made the lint immediately show up for dependencies since it is nearly impossible to even trigger this lint without
const_mut_refs-- the accidentally stabilizedcopyfunctions are the only way this can happen, so the crates that popped up in #117905 are the only causes of such UB (in the code that crater covers), and the three cases of UB that we know about have all been fixed in their respective crates already.The way this is implemented is by making use of the fact that our interpreter is already generic over the notion of provenance. For CTFE we now use the new
CtfeProvenancetype which is conceptually anAllocIdplus a booleanimmutableflag (but packed for a more efficient representation). This means we can mark a pointer as immutable when it is created as a shared reference. The flag will be propagated to all pointers derived from this one. We can then check the immutable flag on each write to reject writes through immutable pointers.I just hope perf works out.