| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
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.
|
|
|
|
A lot of these static symbols are pre-interned.
|
|
And also the equality between `Path` and strings, because `Path` is made
up of `Symbol`s.
|
|
|
|
|
|
|
|
Rename `PathResolution` to `PartialRes`
Don't use `PartialRes` when `Res` is enough.
Rename `Res::kind_name` to `Res::descr` for consistency.
Remove `Res::Label`, paths can never resolve to labels.
Some further cleanup after https://github.com/rust-lang/rust/pull/60462
r? @eddyb
|
|
|
|
|
|
|
|
|
|
Paths can never resolve to labels
|
|
|
|
Don't use `PartialRes` when `Res` is enough
|
|
|
|
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
|
|
|
|
tweak unresolved label suggestion
Only suggest label names in the same hygiene context, and use a
structured suggestion.
Question for reviewer: Is this the right way to check for label hygiene?
|
|
[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.
|
|
|
|
|
|
|
|
Change suggestion of field when not in self context
Fix #60057.
|
|
When looking at the documentation for `std::f32` or `std::str`, for
example, it is easy to get confused and assume `std::f32` and `f32`
are the same thing. Because of this, it is not uncommon to attempt
writing `f32::consts::PI` instead of the correct
`std::f32::consts::PI`. When encountering the former, which results
in an access error due to it being an inexistent path, try to access
the same path under `std`. If this succeeds, this information is
stored for later tweaking of the final E0599 to provide an
appropriate suggestion.
This suggestion applies to both E0233 and E0599 and is only checked
when the first ident of a path corresponds to a primitive type.
|
|
|
|
|
|
Rename files about error codes
fixes #60017
This PR will be failed in tidy.
<details>
<summary>The log is here:</summary>
```
tidy check
tidy error: duplicate error code: 411
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:83: __diagnostic_used!(E0411);
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:84: err.code(DiagnosticId::Error("E0411".to_owned()));
tidy error: duplicate error code: 424
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:90: debug!("smart_resolve_path_fragment: E0424, source={:?}", source);
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:92: __diagnostic_used!(E0424);
tidy error: Documents\GitHub\rust\src\librustc_resolve\diagnostics.rs:93: err.code(DiagnosticId::Error("E0424".to_owned()));
some tidy checks failed
```
</details>
I'd like to fix this but I don't know what to do.
I will work on later. Please let me know if you have any solutions.
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove duplicated redundant spans
Fix #59895.
|
|
|
|
Suggest importing macros from the crate root
Fixes #59764.
r? @estebank
cc @varkor
|
|
|