Here follows the main reverts applied in order to make this commit:
Revert "Rollup merge of #60676 - davidtwco:issue-60674, r=cramertj"
This reverts commit 45b09453db, reversing
changes made to f6df1f6c30.
Revert "Rollup merge of #60437 - davidtwco:issue-60236, r=nikomatsakis"
This reverts commit 16939a50ea, reversing
changes made to 12bf981552.
Revert "Rollup merge of #59823 - davidtwco:issue-54716, r=cramertj"
This reverts commit 62d1574876, reversing
changes made to 4eff8526a7.
Add match arm scopes and other scope fixes
* Add drop and lint scopes for match arms.
* Lint attributes are now respected on match arms.
* Make sure we emit a StorageDead if we diverge when initializing a temporary.
* Adjust MIR pretty printing of scopes for locals.
* Don't generate duplicate lint scopes for `let statements`.
* Add some previously missing fake borrows for matches.
closes#46525
cc @rust-lang/compiler
Ban multi-trait objects via trait aliases
Obviously, multi-trait objects are not normally supported, so they should not be supported via trait aliases.
This has been factored out from the previous PR https://github.com/rust-lang/rust/pull/55994 (see point 1).
r? @Centril
CC @nikomatsakis
------------------
### RELNOTES:
We now allow `dyn Send + fmt::Debug` with equivalent semantics to `dyn fmt::Debug + Send`.
That is, the order of the mentioned traits does not matter wrt. principal/not-principal traits.
This is a small change that might deserve a mention in the blog post because it is a language change but most likely not.
See ce2ee305f9/src/test/ui/traits/wf-trait-object-reverse-order.rs.
// @Centril
Move gensym operations from `Symbol` to `Ident`
Gensyms are always at the `Ident` level, and long-term we probably want to record gensym-ness in hygiene data.
r? @petrochenkov
Note that the `is_gensymed` call on `primitive_types` is unnecessary
because that table only contains the name of primitive types (e.g.
`i32`) and never contains gensyms.
Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.
This commit modifies the lowering of `async fn` arguments so that the
drop order matches the equivalent `fn`.
Previously, async function arguments were lowered as shown below:
async fn foo(<pattern>: <ty>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>) {
async move {
let <pattern> = __arg0;
} // <-- dropped as you "exit" the async block
}
After this PR, async function arguments will be lowered as:
async fn foo(<pattern>: <ty>, <pattern>: <ty>, <pattern>: <ty>) {
async move {
}
} // <-- dropped as you "exit" the fn
// ...becomes...
fn foo(__arg0: <ty>, __arg1: <ty>, __arg2: <ty>) {
async move {
let __arg2 = __arg2;
let <pattern> = __arg2;
let __arg1 = __arg1;
let <pattern> = __arg1;
let __arg0 = __arg0;
let <pattern> = __arg0;
} // <-- dropped as you "exit" the async block
}
If `<pattern>` is a simple ident, then it is lowered to a single
`let <pattern> = <pattern>;` statement as an optimization.
[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 introduces an `ArgSource` enum that is lowered into the HIR
so that diagnostics can correctly refer to the argument pattern's
original name rather than the generated pattern.
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.
This will be used to keep track of the origin of a local in the AST. In
particular, it will be used by `async fn` lowering for the locals in
`let <pat>: <ty> = __arg0;` statements.
This increases the size of some important types, such as `ast::Expr` and
`mir::Statement`. However, it drastically reduces how much the interner
is used, and the fields are more natural sizes that don't require bit
operations to extract.
As a result, instruction counts drop across a range of workloads, by as
much as 12% for incremental "check" builds of `script-servo`.
Peak memory usage goes up a little for some cases, but down by more for
some other cases -- as much as 18% for non-incremental builds of
`packed-simd`.
The commit also:
- removes the `repr(packed)`, because it has negligible effect, but can
cause undefined behaviour;
- replaces explicit impls of common traits (`Copy`, `PartialEq`, etc.)
with derived ones.
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.
When failing to parse struct-like enum variants, the ADT gets recorded
as having no fields. Record that we have actually recovered during
parsing of this variant to avoid complaing about non-existing fields
when actually using it.
Support defining C compatible variadic functions
## Summary
Add support for defining C compatible variadic functions in unsafe rust with
`extern "C"` according to [RFC 2137].
## Details
### Parsing
When parsing a user defined function that is `unsafe` and `extern "C"` allow
variadic signatures and inject a "spoofed" `VaList` in the new functions
signature. This allows the user to interact with the variadic arguments via a
`VaList` instead of manually using `va_start` and `va_end` (See [RFC 2137] for
details).
### Codegen
When running codegen for a variadic function, remove the "spoofed" `VaList`
from the function signature and inject `va_start` when the arg local
references are created for the function and `va_end` on return.
## TODO
- [x] Get feedback on injecting `va_start/va_end` in MIR vs codegen
- [x] Properly inject `va_end` - It seems like it should be possible to inject
`va_end` on the `TerminatorKind::Return`. I just need to figure out how
to get the `LocalRef` here.
- [x] Properly call Rust defined C variadic functions in Rust - The spoofed
`VaList` causes problems here.
Related to: #44930
r? @ghost
[RFC 2137]: https://github.com/rust-lang/rfcs/blob/master/text/2137-variadic.md
Function signatures with the `variadic` member set are actually
C-variadic functions. Make this a little more explicit by renaming the
`variadic` boolean value, `c_variadic`.
