introduce unescape module
A WIP PR to gauge early feedback
Currently, we deal with escape sequences twice: once when we [lex](https://github.com/rust-lang/rust/blob/112f7e9ac564e2cfcfc13d599c8376a219fde1bc/src/libsyntax/parse/lexer/mod.rs#L928-L1065) a string, and a second time when we [unescape](https://github.com/rust-lang/rust/blob/112f7e9ac564e2cfcfc13d599c8376a219fde1bc/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
Account for paths in incorrect pub qualifier help
Handle case where incorrect pub qualifier with a mod path is used and provide the same help given for all other incorrect qualifiers by making the `pub(crate)` parse check more specific.
Currently, we deal with escape sequences twice: once when we lex a
string, and a second time when we unescape literals. This PR aims to
remove this duplication, by introducing a new `unescape` mode as a
single source of truth for character escaping rules
Ensure that drop order of `async fn` matches `fn` and that users cannot refer to generated arguments.
Fixes#60236 and fixes#60438.
This PR 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 PR also stops users from referring to the generated `__argN`
identifiers.
r? @nikomatsakis
Added an explanation for the E0704 error.
# Description
Adds an explanation on the E0704 error. I tried to stick as closely to the message that the compiler generates. It's the first time I am fixing error messages here, so if there is something I did wrong or should improve, please let me know.
closes#55398
This commit gensyms the generated ident for replacement arguments so
that users cannot refer to them. It also ensures that levenshtein
distance suggestions do not suggest gensymed identifiers.
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.
In JSON output, emit a directive after metadata is generated.
To implement pipelining, Cargo needs to know when metadata generation is
finished. This is done via a new JSON "directive".
Unfortunately, metadata file writing currently occurs very late during
compilation, so pipelining won't produce a speed-up. Moving metadata
file writing earlier will be a follow-up.
r? @alexcrichton
To implement pipelining, Cargo needs to know when metadata generation is
finished. This commit adds code to do that. Unfortunately, metadata file
writing currently occurs very late during compilation, so pipelining
won't produce a speed-up. Moving metadata file writing earlier will be a
follow-up.
The change involves splitting the existing `Emitter::emit` method in
two: `Emitter::emit_diagnostic` and `Emitter::emit_directive`.
The JSON directives look like this:
```
{"directive":"metadata file written: liba.rmeta"}
```
The functionality is behind the `-Z emit-directives` option, and also
requires `--error-format=json`.
Float 'incomplete_features' out to a const for visibility
Float `let incomplete_features` out to a `const INCOMPLETE_FEATURES` and colocate near `active` features so that it is easier to find and edit.
r? @oli-obk
(use rollup)
Add a tidy check for files with over 3,000 lines
Files with a large number of lines can cause issues in GitHub (e.g. https://github.com/rust-lang/rust/issues/60015) and also tend to be indicative of opportunities to refactor into less monolithic structures.
This adds a new check to tidy to warn against files that have more than 3,000 lines, as suggested in https://github.com/rust-lang/rust/issues/60015#issuecomment-483868594. (This number was chosen fairly arbitrarily as a reasonable indicator of size.) This check can be ignored with `// ignore-tidy-filelength`.
Existing files with greater than 3,000 lines currently ignore the check, but this helps us spot when files are getting too large. (We might try to split up all files larger than this in the future, as in https://github.com/rust-lang/rust/issues/60015).
Temporarily accept [i|u][32|size] suffixes on a tuple index and warn
Fix#60138.
#59553 will need to be kept open to track the change back to rejecting this code a few versions down thee line.
[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 avoids issues with `impl_trait_in_bindings` as the type from the
argument is normally used as the let binding, but `impl Trait` is
unstable in binding position.
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.
Remove mutability from `Def::Static`
Querify `TyCtxt::is_static`.
Use `Mutability` instead of bool in foreign statics in AST/HIR.
cc https://github.com/rust-lang/rust/pull/60110
r? @eddyb
Eduard-Mihai Burtescu