introduce unescape module
A WIP PR to gauge early feedback
Currently, we deal with escape sequences twice: once when we [lex](112f7e9ac5/src/libsyntax/parse/lexer/mod.rs (L928-L1065)) a string, and a second time when we [unescape](112f7e9ac5/src/libsyntax/parse/mod.rs (L313-L366)) literals. Note that we also produce different sets of diagnostics in these two cases.
This PR aims to remove this duplication, by introducing a new `unescape` module as a single source of truth for character escaping rules.
I think this would be a useful cleanup by itself, but I also need this for https://github.com/rust-lang/rust/pull/59706.
In the current state, the PR has `unescape` module which fully (modulo bugs) deals with string and char literals. I am quite happy about the state of this module
What this PR doesn't have yet are:
* [x] handling of byte and byte string literals (should be simple to add)
* [x] good diagnostics
* [x] actual removal of code from lexer (giant `scan_char_or_byte` should go away completely)
* [x] performance check
* [x] general cleanup of the new code
Diagnostics will be the most labor-consuming bit here, but they are mostly a question of just correctly adjusting spans to sub-tokens. The current setup for diagnostics is that `unescape` produces a plain old `enum` with various problems, and they are rendered into `Handler` separately. This bit is not actually required (it is possible to just pass the `Handler` in), but I like the separation between diagnostics and logic this approach imposes, and such separation should again be useful for #59706
cc @eddyb , @petrochenkov
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.
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 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.
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`.
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 for issue #58050
Hi,
a quick PR to mention in the compiler error message that `?` is a macro operator, as according to issue #58050
It passed `python x.py test src/tools/tidy` locally, as well as the recommendation to run `/x.py test src/test/ui --stage 1 --bless`.
Let me know if anything else is needed.
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
The current code (expensively) clones the value within an `Rc`. This
commit changes things so that the `Rc` itself is (cheaply) cloned
instead, avoid some allocations.
This requires converting a few `Rc` instances to `Lrc`.
It's present within `Token::Interpolated` as an optimization, so that if
a nonterminal is converted to a `TokenStream` multiple times, the
first-computed value is saved and reused.
But in practice it's not needed. `interpolated_to_tokenstream()` is a
cold function: it's only called a few dozen times while compiling rustc
itself, and a few hundred times across the entire `rustc-perf` suite.
Furthermore, when it is called, it is almost always the first
conversion, so no benefit is gained from it.
So this commit removes `LazyTokenStream`, along with the now-unnecessary
`Token::interpolated()`.
As well as a significant simplification, the removal speeds things up
slightly, mostly due to not having to `drop` the `LazyTokenStream`
instances.
Rename rustc_errors dependency in rust 2018 crates
I think this is a better solution than `use rustc_errors as errors` in `lib.rs` and `use crate::errors` in modules.
Related: rust-lang/cargo#5653
cc #58099
r? @Centril
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
while we could make this change (it's all unstable after all), there are crates.io crates that use the feature and that the compiler depends upon. We can instead roll out this feature while still supporting the old way.
Error on duplicate matcher bindings
fix #57593
This should not be merged without a crater run and maybe an FCP. Discussion is ongoing at #57593.
TODO:
- [x] write tests
- [x] crater run
- [x] ~maybe need edition gating?~ not for 1 regression /centril
r? @petrochenkov
