| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Use a single enum for the kind of a const context
This adds a `ConstContext` enum to the `rustc_hir` crate and method that can be called via `tcx.hir()` to get the `ConstContext` for a given body owner. This arose from discussion in #71824.
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
|
|
The liveness dataflow analysis now lives in
`librustc_mir/dataflow/impls/liveness.rs`. The borrow-checker has an
abstraction around of "defs" and "uses" that I've made module private. I
would have moved it to `util/def_use.rs`, but there's a slightly
different abstraction used for copy propagation with that name.
|
|
|
|
1. InvalidUndefBytes -> InvalidUninitBytes
2. ScalarMaybeUndef -> ScalarMaybeUninit
3. UndefMask -> InitMask
Related issue #71193
|
|
|
|
Prevent compiler stack overflow for deeply recursive code
I was unable to write a test that
1. runs in under 1s
2. overflows on my machine without this patch
The following reproduces the issue, but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`.
```rust
// compile-pass
#![recursion_limit="1000000"]
macro_rules! chain {
(EE $e:expr) => {$e.sin()};
(RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))};
(Z $e:expr) => {chain!(RECURSE EE $e)};
(Y $e:expr) => {chain!(RECURSE Z $e)};
(X $e:expr) => {chain!(RECURSE Y $e)};
(A $e:expr) => {chain!(RECURSE X $e)};
(B $e:expr) => {chain!(RECURSE A $e)};
(C $e:expr) => {chain!(RECURSE B $e)};
// causes overflow on x86_64 linux
// less than 1 second until overflow on test machine
// after overflow has been fixed, takes 30s to compile :/
(D $e:expr) => {chain!(RECURSE C $e)};
(E $e:expr) => {chain!(RECURSE D $e)};
(F $e:expr) => {chain!(RECURSE E $e)};
// more than 10 seconds
(G $e:expr) => {chain!(RECURSE F $e)};
(H $e:expr) => {chain!(RECURSE G $e)};
(I $e:expr) => {chain!(RECURSE H $e)};
(J $e:expr) => {chain!(RECURSE I $e)};
(K $e:expr) => {chain!(RECURSE J $e)};
(L $e:expr) => {chain!(RECURSE L $e)};
}
fn main() {
let x = chain!(D 42.0_f32);
}
```
fixes #55471
fixes #41884
fixes #40161
fixes #34844
fixes #32594
cc @alexcrichton @rust-lang/compiler
I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.
|
|
Miri validation error handling cleanup
Slightly expand @jumbatm's pattern macro and use it throughout validation. This ensures we never incorrectly swallow `InvalidProgram` errors or ICE when they occur.
Fixes https://github.com/rust-lang/rust/issues/71353
r? @oli-obk
|
|
Provide suggestions for type parameters missing bounds for associated types
When implementing the binary operator traits it is easy to forget to restrict the `Output` associated type. `rustc` now accounts for different cases to lead users in the right direction to add the necessary restrictions. The structured suggestions in the following output are new:
```
error: equality constraints are not yet supported in `where` clauses
--> $DIR/missing-bounds.rs:37:33
|
LL | impl<B: Add> Add for E<B> where <B as Add>::Output = B {
| ^^^^^^^^^^^^^^^^^^^^^^ not supported
|
= note: see issue #20041 <https://github.com/rust-lang/rust/issues/20041> for more information
help: if `Output` is an associated type you're trying to set, use the associated type binding syntax
|
LL | impl<B: Add> Add for E<B> where B: Add<Output = B> {
| ^^^^^^^^^^^^^^^^^
error[E0308]: mismatched types
--> $DIR/missing-bounds.rs:11:11
|
7 | impl<B> Add for A<B> where B: Add {
| - this type parameter
...
11 | A(self.0 + rhs.0)
| ^^^^^^^^^^^^^^ expected type parameter `B`, found associated type
|
= note: expected type parameter `B`
found associated type `<B as std::ops::Add>::Output`
help: consider further restricting this bound
|
7 | impl<B> Add for A<B> where B: Add + std::ops::Add<Output = B> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
error[E0369]: cannot add `B` to `B`
--> $DIR/missing-bounds.rs:31:21
|
31 | Self(self.0 + rhs.0)
| ------ ^ ----- B
| |
| B
|
help: consider restricting type parameter `B`
|
27 | impl<B: std::ops::Add<Output = B>> Add for D<B> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
That output is given for the following cases:
```rust
struct A<B>(B);
impl<B> Add for A<B> where B: Add {
type Output = Self;
fn add(self, rhs: Self) -> Self {
A(self.0 + rhs.0) //~ ERROR mismatched types
}
}
struct D<B>(B);
impl<B> Add for D<B> {
type Output = Self;
fn add(self, rhs: Self) -> Self {
Self(self.0 + rhs.0) //~ ERROR cannot add `B` to `B`
}
}
struct E<B>(B);
impl<B: Add> Add for E<B> where <B as Add>::Output = B {
type Output = Self;
fn add(self, rhs: Self) -> Self {
Self(self.0 + rhs.0)
}
}
```
|
|
|
|
Use the `impls` module to import pre-existing dataflow analyses
Currently, existing analyses live in the same module as the traits and types used to define new dataflow analyses. This muddles the [documentation for the `dataflow` module](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/index.html). After this PR, `dataflow::impls` will refer to concrete dataflow analyses, and `dataflow` to the generic interface.
|
|
|
|
manual throw_validation_failure sites
|
|
|
|
|
|
|
|
By boxing `user_ty`.
|
|
By boxing `local_info`.
|
|
This commit adds some new `LocalDecl` methods:
- `with_source_info`, a most general constructor.
- `new`, a variant of `with_source_info` which represents the most
common use case.
- `internal` a modifying method (like the already present `immutable`).
It removes some old `LocalDecl` methods:
- `new_internal` and `new_local`, because they're subsumed by the new
methods.
- `new_return_place`, because it was identical to `new_temp`.
Finally, it cleans up all the use sites.
|
|
|
|
shorter name)
|
|
Suggest to add missing feature when using gated const features
Fixes #71797
|
|
Report cannot move errors in promoted MIR
Closes #70934
|
|
|
|
|
|
|
|
When encountering a projection that isn't satisfied by a type parameter,
suggest constraining the type parameter.
|
|
Added MIR constant propagation of Scalars into function call arguments
Now for the function call arguments!
Caveats:
1. It's only being enabled at `mir-opt-2` or higher, because currently codegen gives performance regressions with this optimization.
2. Only propagates Scalars. Tuples and references (references are `Indirect`, right??) are not being propagated into as of this PR.
3. Maybe more tests would be nice?
4. I need (shamefully) to ask @wesleywiser to write in his words (or explain to me, and then I can write it down) why we want to ignore propagation into `ScalarPairs` and `Indirect` arguments.
r? @wesleywiser
|
|
Move recursion check for zsts back to read site instead of access check site
Reverts https://github.com/rust-lang/rust/pull/71140#discussion_r413709446
Fix #71612
Fix #71709
r? @RalfJung
|
|
Rollup of 4 pull requests
Successful merges:
- #71645 (Direct contributors to try stage 0 rustdoc first)
- #71801 (Correctly check comparison operator in MIR typeck)
- #71844 (List Clippy as a subtree, instead of a submodule)
- #71864 (Update link in contributing.md)
Failed merges:
r? @ghost
|
|
Correctly check comparison operator in MIR typeck
The subtyping for comparisons between pointers was reversed in MIR typeck.
There also wasn't a check that comparisons between numeric types had matching types.
|
|
Miri: unleash all feature gates
IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is).
Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing.
r? @oli-obk @ecstatic-morse
Fixes https://github.com/rust-lang/rust/issues/71630
|
|
Use existing framework for backward dataflow analyses
This PR adds support for backward analyses to the dataflow framework and adds a new live variable analysis (based on the existing one in `librustc_mir/util/liveness.rs`). By adding these to the framework instead of having a separate API, all newly implemented backward dataflow analyses get cursors/visitors, `rustc_peek` tests, and graphviz visualizations for free. In the near-term, this makes it much easier to implement global dead-store elimination, and I believe that this will enable even more MIR optimizations in the future.
This PR makes many changes to the dataflow API, since some concepts and terminology only make sense in forward dataflow. Below is a list of the important changes.
- ~~`entry_set` -> `fixpoint` (the fixpoint for backward dataflow problems is after the block's terminator)~~
- `seek_{before,after}` -> `seek_{before,after}_primary_effect` (the unprefixed dataflow effect is now referred to as the "primary" effect instead of the "after" effect. The "before" effect remains the same, although I considered changing it to the "antecedent" effect. In both backward and forward dataflow, the "before" effect is applied prior to the "primary" effect. I feel very strongly that this is the correct choice, as it means consumers don't have to switch between `seek_before` and `seek_after` based on the direction of their analysis.
- `seek_after_assume_call_returns` is now gone. Users can use `ResultsCursor::apply_custom_effect` to emulate it.
- `visit_{statement,terminator}_exit` -> `visit_{statement,terminator}_after_primary_effect`
- `visit_{statement,terminator}` -> `visit_{statement,terminator}_before_primary_effect`
Implementing this also required refactoring the dataflow cursor implementation so it could work in both directions. This is a large percentage of the diff, since the cursor code is rather complex. The fact that the cursor is exhaustively tested in both directions should reassure whomever is unlucky enough to review this :rofl:.
In order to avoid computing the reverse CFG for forward dataflow analyses, I've added some hacks to the existing `mir::BodyAndCache` interface. I've requested changes to this interface that would let me implement this more efficiently.
r? @eddyb (feel free to reassign)
cc @rust-lang/wg-mir-opt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...emulating `MutatingUseContext::Call`
|
|
Fix exceeding bitshifts not emitting for assoc. consts (properly this time, I swear!)
Fixes #69021 and fixes #71353.
As described in https://github.com/rust-lang/rust/issues/71353#issuecomment-617901923, this PR:
- adds a variant of `try_validation!` called `try_validation_pat!` that allows specific failures to be turned into validation failures (but returns the rest, unchanged), and
- allows `InvalidProgram` to be returned out of validation
r? @RalfJung
|
|
|
|
|
|
fix rustdoc warnings
|
