| Age | Commit message (Collapse) | Author | Lines |
|---|
|
HirIdification: rework Map
The next iteration of HirIdification (#57578).
- remove `NodeId` from `Entry`
- change `Map::map` to an `FxHashMap<HirId, Entry>`
- base the `NodeId` `Map` methods on `HirId` ones (reverses the current state)
- HirIdify `librustdoc` a little bit (some `NodeId` `Map` methods were converted to work on `HirId`s)
The second change might have performance implications, so I'd do a perf run to be sure it's fine; it simplifies the codebase and shouldn't have an impact as long as the `Map` searches are cached (which is now possible thanks to using `HirId`s).
r? @Zoxc
|
|
|
|
|
|
[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;
}
}
|
|
This commit adds an `AsyncArgument` struct to the AST that contains the
generated argument and statement that will be used in HIR lowering, name
resolution and def collection.
|
|
|
|
|
|
|
|
Combine input and eval_always query types
Hardcoding `Krate` as a dependency of `eval_always` queries doesn't really make sense if we want to use the query system before HIR lowering / hashing. Without that hardcoding they become pretty much identical to `input` queries, so I combined them to a single type. This will regress the `clean` incremental scenario, but that isn't terribly common.
r? @michaelwoerister
|
|
HirIdify hir::ItemId
Version of https://github.com/rust-lang/rust/pull/59092.
r? @oli-obk
|
|
|
|
|
|
|
|
|
|
This commit moves the `DefId` field of `Def::Ctor` to be the first
field.
|
|
This commit moves the definition of `CtorOf` from `rustc::hir` to
`rustc::hir::def` and adds imports wherever it is used.
|
|
This commit removes `CtorOf` from `Node::Ctor` as the parent of the
constructor can be determined by looking at the node's parent in the few
places where knowing this is necessary.
|
|
|
|
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.
|
|
HirIdification: kill off NodeId stragglers
The final stages of HirIdification (#57578).
This PR, along with https://github.com/rust-lang/rust/pull/59042, should finalize the HirIdification process (at least the more straightforward bits).
- replace `NodeId` with `HirId` in `trait_impls`
- remove all `NodeId`s from `borrowck`
- remove all `NodeId`s from `typeck`
- remove all `NodeId`s from `mir`
- remove `trait_auto_impl` (unused)
I would be cool to also remove `NodeId` from `hir::def::Def`, `middle::privacy::AccessLevel` and `hir::ItemId`, but I don't know if this is feasible.
I'll be happy to do more if I've missed anything.
|
|
rustc: fix ICE when trait alias has bare Self
Fixes https://github.com/rust-lang/rust/issues/59029
|
|
|
|
|
|
Only insert nodes which changes lint levels in the LintLevelMap
r? @eddyb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Deny `async fn` in 2015 edition
This commit prevents code using `async fn` from being compiled in Rust 2015 edition.
Compiling code of the form:
```rust
async fn foo() {}
```
Will now result in the error:
```
error[E0670]: `async fn` is not permitted in the 2015 edition
--> async.rs:1:1
|
1 | async fn foo() {}
| ^^^^^
error: aborting due to error
For more information about an error, try `rustc --explain E0670`.
```
This resolves #58652 and also resolves #53714.
r? @varkor
|
|
Fix style issues and update diagnostic messages
Update src/librustc_passes/diagnostics.rs
Co-Authored-By: doctorn <me@nathancorbyn.com>
Deny nested `async fn` in Rust 2015 edition
Deny nested `async fn` in Rust 2015 edition
Deny nested `async fn` in Rust 2015 edition
|
|
|
|
|
|
|
|
HirId-ify intravisit
A big step towards https://github.com/rust-lang/rust/pull/57578.
This affects mostly `hir::{collector, intravisit}` and `rustc::lint`.
|
|
Remove `LazyTokenStream`.
`LazyTokenStream` was added in #40939. Perhaps it was an effective optimization then, but no longer. This PR removes it, making the code both simpler and faster.
r? @alexcrichton
|
|
|
|
|
|
|
|
|
