| Age | Commit message (Collapse) | Author | Lines |
|
|
|
This was needed by an early version of dataflow-based const
qualification where `QualifCursor` needed to return a full `BitSet` with
the current state.
|
|
|
|
Const check/promotion cleanup and sanity assertion
r? @RalfJung
This is just the part of https://github.com/rust-lang/rust/pull/70042#issuecomment-614592765 that does not change behaviour
|
|
Reading from the return place is fine
Const eval thinks that reading from local `_0` is UB, but it isn't. `_0` is just a normal local like any other, and codegen handles it that way too. The only special thing is that the `Return` terminator will read from it.
I've hit these errors while working on an NRVO pass that can merge other locals with `_0` in https://github.com/rust-lang/rust/pull/71003.
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
|
|
This renaming was already done in some modules via import renaming. It's strictly used as a context, and it contains a `TyCtxt`.
|
|
[ConstProp] Use a `BitSet<Local>` instead of `IndexVec<Local, bool>`
|
|
Remove `BodyAndCache`
...returning to the original approach using interior mutability within `Body`. This simplifies the API at the cost of some uncontended mutex locks when the parallel compiler is enabled.
The current API requires you to either have a mutable reference to `Body` (`&mut BodyAndCache`), or to compute the predecessor graph ahead of time by creating a `ReadOnlyBodyAndCache`. This is not a good fit for, e.g., the dataflow framework, which
1. does not mutate the MIR
2. only sometimes needs the predecessor graph (for backward dataflow problems)
|
|
|
|
|
|
visit_place_base is just visit_local
r? @wesleywiser
|
|
Exhaustively match on `{Statement,Terminator}Kind` during const checking
This adds a pre-monomorphization error for inline assembly in a const context as well.
r? @oli-obk
|
|
Detect mistyped associated consts in `Instance::resolve`.
*Based on #71049 to prevent redundant/misleading downstream errors.*
Fixes #70942 by refusing to resolve an associated `const` if it doesn't have the same type in the `impl` that it does in the `trait` (which we assume had errored, and `delay_span_bug` guards against bugs).
|
|
|
|
|
|
r=ecstatic-morse
MIR: use HirId instead of NodeId to avoid cycles while inlining
I wanted to see if I could limit the number of uses of `NodeId` when `HirId` is available and I saw that some of the MIR `Inliner` code could use `Span` instead of `NodeId`, not unlike in https://github.com/rust-lang/rust/pull/71197.
~If I'm understanding the reason for not calling `optimized_mir` in incremental builds here correctly, this change could also allow us to do so.~
This change could affect performance, so if this approach makes sense, a perf run is probably a good idea.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make the necessary changes to support concurrency in Miri.
This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency:
1. Move stack from the interpretation context (`InterpCx`) to machine, so that the machine can switch the stacks when it changes the thread being executed.
2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique, which allows using a simpler representation of the memory.
r? @oli-obk
cc @RalfJung
|
|
|
|
|
|
|
|
|
|
|
|
Don't use the HirId to NodeId map in MIR
Another step towards not having to build a `HirId` to `NodeId` map other than for doc and RLS purposes.
We are currently sorting `unsafe` blocks by `NodeId` in `check_unsafety`; change it to sorting by `Span` instead; this passes the tests, but better ideas are welcome.
In addition, simplify the split between the used and unused `unsafe` blocks for readability and less sorting.
cc https://github.com/rust-lang/rust/issues/50928
|
|
Rollup of 5 pull requests
Successful merges:
- #70566 (Don't bail out before linting in generic contexts.)
- #71141 (Provide better compiler output when using `?` on `Option` in fn returning `Result` and vice-versa)
- #71149 (remove an impossible branch from check_consts)
- #71179 (fix more clippy warnings)
- #71191 (Clean up E0520 explanation)
Failed merges:
r? @ghost
|
|
|
|
method group.
|
|
fix more clippy warnings
|
|
remove an impossible branch from check_consts
All function calleess are either `FnPtr` or `FnDef`, so we can remove the alternative from check_consts and just make it ICE instead.
|
|
Don't bail out before linting in generic contexts.
Fixes #69021.
cc #70017
r? @RalfJung
|
|
|
|
- Remove reads of indirect `Place`s
- Add comments explaining what the algorithm does
|
|
|
|
|
|
Fixes perf regression in `optimized_mir` query
|
|
|
|
|
|
|