| Age | Commit message (Collapse) | Author | Lines |
|
This avoids some unnecessary moves
|
|
Future-proof MIR for dedicated debuginfo.
This is #56231 without the last commit (the one that actually moves to `VarDebuginfo`).
Nothing should be broken, but it should no longer depend on debuginfo for anything else.
r? @nikomatsakis
|
|
|
|
|
|
Warn when ignore-tidy-linelength is present, but no lines are too long
It's easy for a `// ignore-tidy-linelength` to be added when there is a genuine need to ignore a file's line length, but then after refactoring the need is gone, but the tidy directive is not removed. This means that in the future, further editing may accidentally add unnecessarily long lines. This change forces `// ignore-tidy-linelength` to be used exactly when necessary, to make sure such changes are intentional.
|
|
[wg-async-await] Drop `async fn` arguments in async block
Fixes #54716.
This PR modifies the HIR lowering (and some other places to make this work) so that unused arguments to a async function are always dropped inside the async move block and not at the end of the function body.
```
async fn foo(<pattern>: <type>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>) {
async move {
let <pattern>: <ty> = __arg0;
} // <-- dropped as you "exit" the async block
}
```
However, the exact ordering of drops is not the same as a regular function, [as visible in this playground example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=be39af1a58e5d430be1eb3c722cb1ec3) - I believe this to be an unrelated issue. There is a [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/187312-t-compiler.2Fwg-async-await/topic/.2354716.20drop.20order) for this.
r? @cramertj
cc @nikomatsakis
|
|
|
|
|
|
This commit takes advantage of `AsyncArgument` type that was added in a
previous commit to replace the arguments of the `async fn` in the HIR
and add statements to move the bindings from the new arguments to the
pattern from the old argument.
For example, the async function `foo` below:
async fn foo((x, _y): (T, V)) {
async move {
}
}
becomes:
async fn foo(__arg0: (T, V)) {
async move {
let (x, _y) = __arg0;
}
}
|
|
Refactor Adjust and CastKind
fixes rust-lang#59588
|
|
|
|
|
|
* Don't promote these borrows if we're going to remove them before
codegen
* Correctly mark unreachable code
|
|
Separate `DefId`s for variants and their constructors
Part of #44109. Split off from #59376. See [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rfc-2008/near/132663140) for previous discussion.
r? @petrochenkov
|
|
|
|
Use a valid name for graphviz graphs
Hiridification has broken graphviz output because `HirId` has a more complex display implemetation than `NodeId`. Since the id was just used to generate a distinct identifier, we just pull out the various constituent indexed.
|
|
This commit makes two changes - separating the `NodeId` that identifies
an enum variant from the `NodeId` that identifies the variant's
constructor; and no longer creating a `NodeId` for `Struct`-style enum
variants and structs.
Separation of the variant id and variant constructor id will allow the
rest of RFC 2008 to be implemented by lowering the visibility of the
variant's constructor without lowering the visbility of the variant
itself.
No longer creating a `NodeId` for `Struct`-style enum variants and
structs mostly simplifies logic as previously this `NodeId` wasn't used.
There were various cases where the `NodeId` wouldn't be used unless
there was an unit or tuple struct or enum variant but not all uses of
this `NodeId` had that condition, by removing this `NodeId`, this must
be explicitly dealt with. This change mostly applied cleanly, but there
were one or two cases in name resolution and one case in type check
where the existing logic required a id for `Struct`-style enum variants
and structs.
|
|
Fixes for the generator transform
* Moves cleanup annotations in pretty printed MIR so that they can be tested
* Correctly determines which drops are in cleanup blocks when elaborating generator drops
* Use the correct state for poisoning a generator
Closes #58892
|
|
|
|
|
|
Fix ICE in MIR pretty printing
A `Def::Variant` should be considered as a function in mir pretty
printing. Each variant has a constructor that we must print.
Given the following enum definition:
```rust
pub enum TestMe {
X(usize),
}
```
We will need to generate a constructor for the variant `X` with a
signature that looks something like the following:
```
fn TestMe::X(_1: usize) -> TestMe;
```
Fixes: #59021
|
|
|
|
|
|
|
|
A `Def::Variant` should be considered as a function in mir pretty
printing. Each variant has a constructor that we must print.
Given the following enum definition:
```
pub enum TestMe {
X(usize),
}
```
We will need to generate a constructor for the variant `X` with a
signature that looks something like the following:
```
fn TestMe::X(_1: usize) -> TestMe;
```
|
|
|
|
This also ensure that dropping a generator won't leak upvars if dropping
one of them panics
|
|
|
|
|
|
|
|
|
|
* Adjust fake borrows to only be live over guards.
* Remove unused `slice_len_checked` field.
* Split the methods on builder into those for matches and those for all
kinds of pattern bindings.
|
|
|
|
|
|
|
|
|
|
This commit refactors the `UserTypeAnnotation` type to be referred to by
an index within `UserTypeProjection`. `UserTypeAnnotation` is instead
kept in an `IndexVec` within the `Mir` struct.
Further, instead of `UserTypeAnnotation` containing canonicalized types,
it now contains normal types and the entire `UserTypeAnnotation` is
canonicalized. To support this, the type was moved from the `rustc::mir`
module to `rustc::ty` module.
|
|
|
|
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
|
|
|
|
Improve MIR match generation for ranges
Improves MIR match generation to rule out ranges/values distinct from the range that has been tested. e.g., for this code:
```rust
match x {
0..=5 if b => 0,
6..=10 => 1,
_ => 2,
}
```
MIR (before):
```rust
bb0: { ...; _4 = Le(const 0i32, _1); switchInt(move _4) -> [false: bb6, otherwise: bb5]; }
bb1: { _3 = const 0i32; goto -> bb8; }
bb2: { _6 = _2; switchInt(move _6) -> [false: bb6, otherwise: bb1]; } // If `!b`, jumps to test if `6 <= x <= 10`.
bb3: { _3 = const 1i32; goto -> bb8; }
bb4: { _3 = const 2i32; goto -> bb8; }
bb5: { _5 = Le(_1, const 5i32); switchInt(move _5) -> [false: bb6, otherwise: bb2]; }
bb6: { _7 = Le(const 6i32, _1); switchInt(move _7) -> [false: bb4, otherwise: bb7]; }
bb7: { _8 = Le(_1, const 10i32); switchInt(move _8) -> [false: bb4, otherwise: bb3]; }
```
MIR (after):
```rust
bb0: { ...; _4 = Le(const 0i32, _1); switchInt(move _4) -> [false: bb5, otherwise: bb6]; }
bb1: { _3 = const 0i32; goto -> bb8; }
bb2: { _6 = _2; switchInt(move _6) -> [false: bb4, otherwise: bb1]; } // If `!b`, jumps to `_ =>` arm.
bb3: { _3 = const 1i32; goto -> bb8; }
bb4: { _3 = const 2i32; goto -> bb8; }
bb5: { _7 = Le(const 6i32, _1); switchInt(move _7) -> [false: bb4, otherwise: bb7]; }
bb6: { _5 = Le(_1, const 5i32); switchInt(move _5) -> [false: bb5, otherwise: bb2]; }
bb7: { _8 = Le(_1, const 10i32); switchInt(move _8) -> [false: bb4, otherwise: bb3]; }
```
cc #29623
|
|
|
|
|
|
|
|
|
|
Now that EndRegion is gone, we don't need to create as many gotos.
|
|
Since lexical MIR borrow check is gone, and validation no longer uses
these, they can be removed.
|
|
Add escape-to-raw MIR statement
Add a new MIR "ghost state statement": Escaping a ptr to permit raw accesses.
~~This includes #55549, [click here](https://github.com/RalfJung/rust/compare/miri-visitor...RalfJung:escape-to-raw) for just the new commits.~~
|
|
When I fixed the previous mis-optimizations, I didn't realize there were
actually two different places where we mutate `callsites` and both of
them should have the same behavior.
As a result, if a function was inlined and that function contained
virtual function calls, they were incorrectly being inlined. I also
added a test case which covers this.
|
|
|