| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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?
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
Suggest importing macros from the crate root
Fixes #59764.
r? @estebank
cc @varkor
|
|
This commit changes the suggestion so that it is split into multiple
parts in an effort to reduce the impact the applied suggestion could
have on formatting.
|
|
This commit introduces more dirty span manipulation into the compiler
in order to handle the various edge cases in moving/renaming the macro
import so it is at the root of the import.
|
|
This commit suggests importing a macro from the root of a crate as the
intent may have been to import a macro from the definition location that
was annotated with `#[macro_export]`.
|
|
|
|
Only suggest label names in the same hygiene context, and use a
structured suggestion.
|
|
- libarena
- librustc_allocator
- librustc_borrowck
- librustc_codegen_ssa
- librustc_codegen_utils
- librustc_driver
- librustc_errors
- librustc_incremental
- librustc_metadata
- librustc_passes
- librustc_privacy
- librustc_resolve
- librustc_save_analysis
- librustc_target
- librustc_traits
- libsyntax
- libsyntax_ext
- libsyntax_pos
|
|
resolve: collect trait aliases along with traits
It seems trait aliases weren't being collected as `TraitCandidates` in resolve, this should change that. (I can't compile the full compiler locally, so relying on CI...)
Fixes https://github.com/rust-lang/rust/issues/56485
r? @alexreg
|
|
|
|
|
|
|
|
Expand suggestions for type ascription parse errors
Fix #51222. CC #48016, #47666, #54516, #34255.
|
|
filter suggestions from extern prelude
Fixes #59027.
Modifies the candidate gathering code to call `filter_fn` on extern crates, which causes them to be filtered out when looking for a type.
|
|
Separate `DefId`s for variants and their constructors
Part of #44109. Split off from #59376. See [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rfc-2008/near/132663140) for previous discussion.
r? @petrochenkov
|
|
This commit moves the `DefId` field of `Def::Ctor` to be the first
field.
|
|
This commit moves the definition of `CtorOf` from `rustc::hir` to
`rustc::hir::def` and adds imports wherever it is used.
|
|
Fix ICE with const generic param in struct
Fixes https://github.com/rust-lang/rust/issues/59340.
r? @petrochenkov
|
|
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.
|
|
|
|
|
