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 45b09453dbf120cc23d889435aac3ed7d2ec8eb7, reversing
changes made to f6df1f6c30b469cb9e65c5453a0efa03cbb6005e.
Revert "Rollup merge of #60437 - davidtwco:issue-60236, r=nikomatsakis"
This reverts commit 16939a50ea440e72cb6ecefdaabb988addb1ec0e, reversing
changes made to 12bf98155249783583a91863c5dccf9e346f1226.
Revert "Rollup merge of #59823 - davidtwco:issue-54716, r=cramertj"
This reverts commit 62d1574876f5531bce1b267e62dff520d7adcbbb, reversing
changes made to 4eff8526a789e0dfa8b97f7dec91b7b5c18e8544.
We are going to uniform the terminology of all associated items.
Methods that may or may not have `self` are called "associated
functions". Because `AssociatedFn` is a bit long, we rename `Associated`
to `Assoc`.
[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
save-analysis: Use serde instead of libserialize to dump JSON data
This breaks the save-analysis infrastructure (which also includes `rls-{analysis, data, span}` crates) from depending on rustc_serialize and so we can start moving them to being supported on stable without implementing `Decodable` et al. by hand for data structures defined there.
Notable benefits:
- we drop the awkward raw byte `PathBuf` [serialization](https://gist.github.com/Xanewok/f4fe8564d0dc0c3ab1dbc244279ff895) (until now (de)serialized as `&[u8]`)
- [faster](https://github.com/serde-rs/json-benchmark) (hopefully noticeable for inner crate dependencies for the RLS workloads)
- we can easily explore the binary serialization backend (which we planned to do for save-analysis anyway)
~This should be merged together with an update to RLS (https://github.com/rust-lang/rls/pull/1435), which technically could be included right now because we can use the bundled `rls-analysis` here directly, however I'd prefer to publish this to crates.io first (https://github.com/rust-lang/rls/pull/1434, cc @nrc) and use the published version, instead.~
Includes https://github.com/rust-lang/rls/pull/1436.
@matklad @nikomatsakis This is also important for the potential RLS 1.0 - 2.0 bridge we talked about on Zulip today
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 also bumps RLS version to 1.36.
The updated rls-* packages use serde but *not* serde_derive thanks to
manual proc macro expansion. This is a hack, since rustc cannot handle
crates.io proc macros (duplicated in tools) when cross-compiling, so
that's the best we can do in order to support serde_json in save-analysis.
Type dependent defs wrappers
First of all, forgive me if something would seem lame to you or I offend some rule (although I tried to read through docs), this is my first PR.
Issue: https://github.com/rust-lang/rust/issues/59094
This PR adds 3 helper methods to `TypeckTables`:
* `opt_type_dependent_def`
* `opt_type_dependent_def_id`
* `type_dependent_def_id`
I didn't add `type_dependent_def` as was proposed in the issue simply because it wasn't used anywhere in the code. Only non-option wrapped`type_dependent_defs()[]` accesses were found in clippy which always called `def_id()` on result.
Speaking of clippy, should I open separate PR in its own repo, given it's used as submodule here?
Sry it took me so long, as I said I'm new here and I had tough week :).
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.
middle: replace NodeId with HirId in AccessLevels
Pushing the limits of HirIdification (#57578).
Replaces `NodeId` with `HirId` in `middle::privacy::AccessLevels`. Actually this time I was more successful and cracked it; I probably tried to HirIdify too much at once when I attempted it last time ^^.
r? @Zoxc
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
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
Cleanup: rename node_id_to_type(_opt)
Renames `node_id_to_type(_opt)` to `hir_id_to_type(_opt)`; this makes it clear we are dealing with HIR nodes and their IDs here.
In addition, a drive-by commit removing `ty::item_path::hir_path_str` (as requested by @eddyb).
