| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove global `next_disambiguator` state and handle it with a `DisambiguatorState` type
This removes `Definitions.next_disambiguator` as it doesn't guarantee deterministic def paths when `create_def` is called in parallel. Instead a new `DisambiguatorState` type is passed as a mutable reference to `create_def` to help create unique def paths. `create_def` calls with distinct `DisambiguatorState` instances must ensure that that the def paths are unique without its help.
Anon associated types did rely on this global state for uniqueness and are changed to use (method they're defined in + their position in the method return type) as the `DefPathData` to ensure uniqueness. This also means that the method they're defined in appears in error messages, which is nicer.
`DefPathData::NestedStatic` is added to use for nested data inside statics instead of reusing `DefPathData::AnonConst` to avoid conflicts with those.
cc `@oli-obk`
|
|
|
|
Simplify `LazyAttrTokenStream`
`LazyAttrTokenStream` is an unpleasant type: `Lrc<Box<dyn ToAttrTokenStream>>`. Why does it look like that?
- There are two `ToAttrTokenStream` impls, one for the lazy case, and one for the case where we already have an `AttrTokenStream`.
- The lazy case (`LazyAttrTokenStreamImpl`) is implemented in `rustc_parse`, but `LazyAttrTokenStream` is defined in `rustc_ast`, which does not depend on `rustc_parse`. The use of the trait lets `rustc_ast` implicitly depend on `rustc_parse`. This explains the `dyn`.
- `LazyAttrTokenStream` must have a `size_of` as small as possible, because it's used in many AST nodes. This explains the `Lrc<Box<_>>`, which keeps it to one word. (It's required `Lrc<dyn _>` would be a fat pointer.)
This PR moves `LazyAttrTokenStreamImpl` (and a few other token stream things) from `rustc_parse` to `rustc_ast`. This lets us replace the `ToAttrTokenStream` trait with a two-variant enum and also remove the `Box`, changing `LazyAttrTokenStream` to `Lrc<LazyAttrTokenStreamInner>`. Plus it does a few cleanups.
r? `@petrochenkov`
|
|
This commit does the following.
- Changes it from `Lrc<Box<dyn ToAttrTokenStream>>` to
`Lrc<LazyAttrTokenStreamInner>`.
- Reworks `LazyAttrTokenStreamImpl` as `LazyAttrTokenStreamInner`, which
is a two-variant enum.
- Removes the `ToAttrTokenStream` trait and the two impls of it.
The recursion limit must be increased in some crates otherwise rustdoc
aborts.
|
|
`DisambiguatorState` type
|
|
|
|
1. Fix "expected" and the note for the pattern case
2. Add suggestions
|
|
|
|
It was only temporarily used by pin!(), which no longer needs it.
|
|
hygiene: Rename semi-transparent to semi-opaque
"Semi-transparent" is just too damn long for a name, especially when used multiple times on a single line, it bothered me when working on #139083.
An optimist sees a macro as semi-opaque, a pessimist sees it as semi-transparent.
Or is it the other way round?
|
|
Reduce kw::Empty usage, part 5
Another step towards https://github.com/rust-lang/rust/issues/137978.
r? `@davidtwco`
|
|
Rollup of 17 pull requests
Successful merges:
- #138374 (Enable contracts for const functions)
- #138380 (ci: add runners for vanilla LLVM 20)
- #138393 (Allow const patterns of matches to contain pattern types)
- #139517 (std: sys: process: uefi: Use NULL stdin by default)
- #139554 (std: add Output::exit_ok)
- #139660 (compiletest: Add an experimental new executor to replace libtest)
- #139669 (Overhaul `AssocItem`)
- #139671 (Proc macro span API redesign: Replace proc_macro::SourceFile by Span::{file, local_file})
- #139750 (std/thread: Use default stack size from menuconfig for NuttX)
- #139772 (Remove `hir::Map`)
- #139785 (Let CStrings be either 1 or 2 byte aligned.)
- #139789 (do not unnecessarily leak auto traits in item bounds)
- #139791 (drop global where-bounds before merging candidates)
- #139798 (normalize: prefer `ParamEnv` over `AliasBound` candidates)
- #139822 (Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix)
- #139833 (Fix some HIR pretty-printing problems)
- #139836 (Basic tests of MPMC receiver cloning)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This is pretty weird code. As the `HACK` comment indicates, we push the
empty ident here only to make the path longer, so certain checks to
occur within `lint_if_path_starts_with_module`. `dummy` is a better
choice because it explicitly communicates that the actual value doesn't
matter.
|
|
Overhaul `AssocItem`
`AssocItem` has multiple fields that only make sense some of the time. E.g. the `name` can be empty if it's an RPITIT associated type. It's clearer and less error prone if these fields are moved to the relevant `kind` variants.
r? ``@fee1-dead``
|
|
To accurately reflect that RPITIT assoc items don't have a name. This
avoids the use of `kw::Empty` to mean "no name", which is error prone.
Helps with #137978.
|
|
Use `newtype_index!`-generated types more idiomatically
Continuation of sorts of #139674
Shouldn't affect anything, just makes some code simpler
|
|
|
|
Fix up partial res of segment in primitive resolution hack
There is a hack in the resolver:
```
// In `a(::assoc_item)*` `a` cannot be a module. If `a` does resolve to a module we
// don't report an error right away, but try to fallback to a primitive type.
```
This fixes up the resolution for primitives which would otherwise resolve to a module, but we weren't also updating the res of the path segment, leading to weird diagnostics.
We explicitly call `self.r.partial_res_map.insert` instead of `record_partial_res` b/c we have recorded a partial res already, and we specifically want to override it.
cc https://github.com/rust-lang/rust/issues/139095#issuecomment-2764371934
|
|
`hir::AssocItem` currently has a boolean `fn_has_self_parameter` field,
which is misplaced, because it's only relevant for associated fns, not
for associated consts or types. This commit moves it (and renames it) to
the `AssocKind::Fn` variant, where it belongs.
This requires introducing a new C-style enum, `AssocTag`, which is like
`AssocKind` but without the fields. This is because `AssocKind` values
are passed to various functions like `find_by_ident_and_kind` to
indicate what kind of associated item should be searched for, and having
to specify `has_self` isn't relevant there.
New methods:
- Predicates `AssocItem::is_fn` and `AssocItem::is_method`.
- `AssocItem::as_tag` which converts `AssocItem::kind` to `AssocTag`.
Removed `find_by_name_and_kinds`, which is unused.
`AssocItem::descr` can now distinguish between methods and associated
functions, which slightly improves some error messages.
|
|
Tweak `DefPathData`
Some improvements in and around `DefPathData`, following on from #137977.
r? `@spastorino`
|
|
|
|
|
|
|
|
|
|
|
|
No need to convert the `DefKind` to `DefPathData`, they're very similar
types.
|
|
Rename some `name` variables as `ident`.
It bugs me when variables of type `Ident` are called `name`. It leads to silly things like `name.name`. `Ident` variables should be called `ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of `Ident` variables. Not all of them, but a decent chunk.
r? `@fee1-dead`
|
|
It bugs me when variables of type `Ident` are called `name`. It leads to
silly things like `name.name`. `Ident` variables should be called
`ident`, and `name` should be used for variables of type `Symbol`.
This commit improves things by by doing `s/name/ident/` on a bunch of
`Ident` variables. Not all of them, but a decent chunk.
|
|
`resolve_ident_in_lexical_scope` checks for an empty name. Why is this
necessary? Because `parse_item_impl` can produce an `impl` block with an
empty trait name in some cases. This is pretty gross and very
non-obvious.
This commit avoids the use of the empty trait name. In one case the
trait name is instead pulled from `TyKind::ImplTrait`, which prevents
the output for `tests/ui/impl-trait/extra-impl-in-trait-impl.rs` from
changing. In the other case we just fail the parse and don't try to
recover. I think losing error recovery in this obscure case is worth
the code cleanup.
This change affects `tests/ui/parser/impl-parsing.rs`, which is split in
two, and the obsolete `..` syntax cases are removed (they are tested
elsewhere).
|
|
Add new `PatKind::Missing` variants
To avoid some ugly uses of `kw::Empty` when handling "missing" patterns, e.g. in bare fn tys. Helps with #137978. Details in the individual commits.
r? ``@oli-obk``
|
|
Add unstable `--print=crate-root-lint-levels`
This PR implements `--print=crate-root-lint-levels` from MCP 833 https://github.com/rust-lang/compiler-team/issues/833.
Tracking issue: https://github.com/rust-lang/rust/issues/139180
Best reviewed commit by commit.
|
|
Note potential but private items in show_candidates
Closes #138626 .
We should add potential private items to give ample hints.
And for the other seemingly false positive ` pub use crate::one::Foo;` should be kept because we don't know if the user wants to import other module's items or not, and therefore should be given the full option to do so.
r? compiler
|
|
Move `ast::Item::ident` into `ast::ItemKind`
The follow-up to #138384, which did the same thing for `hir::ItemKind`.
r? `@fmease`
|
|
|
|
`ast::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
`Trait`, `TraitAlias`, `MacroDef`, `Delegation`.
- It's always empty for these item kinds: `Use`, `ForeignMod`,
`GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`.
There is a similar story for `AssocItemKind` and `ForeignItemKind`.
Some sites that handle items check for an empty ident, some don't. This
is a very C-like way of doing things, but this is Rust, we have sum
types, we can do this properly and never forget to check for the
exceptional case and never YOLO possibly empty identifiers (or possibly
dummy spans) around and hope that things will work out.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- `ast::Item` got 8 bytes bigger. This could be avoided by boxing the
fields within some of the `ast::ItemKind` variants (specifically:
`Struct`, `Union`, `Enum`). I might do that in a follow-up; this
commit is big enough already.
- For the visitors: `FnKind` no longer needs an `ident` field because
the `Fn` within how has one.
- In the parser, the `ItemInfo` typedef is no longer needed. It was used
in various places to return an `Ident` alongside an `ItemKind`, but
now the `Ident` (if present) is within the `ItemKind`.
- In a few places I renamed identifier variables called `name` (or
`foo_name`) as `ident` (or `foo_ident`), to better match the type, and
because `name` is normally used for `Symbol`s. It's confusing to see
something like `foo_name.name`.
|
|
It makes it clearer that the symbol is unused and doesn't matter.
|
|
|
|
The former is just too long, see the examples in `hygiene.rs`
|
|
|
|
Do not treat lifetimes from parent items as influencing child items
```rust
struct A;
impl Bar<'static> for A {
const STATIC: &str = "";
// ^ no future incompat warning
}
```
has no future incompat warning, because there is no ambiguity. But
```rust
struct C;
impl Bar<'_> for C {
// ^^ this lifeimte
const STATIC: &'static str = {
struct B;
impl Bar<'static> for B {
const STATIC: &str = "";
// causes ^ to emit a future incompat warning
}
""
};
}
```
had one before this PR, because the impl for `B` (which is just a copy of `A`) thought it was influenced by a lifetime on the impl for `C`.
I double checked all other `lifetime_ribs` iterations and all of them do check for `Item` boundaries. This feels very fragile tho, and ~~I think we should do not even be able to see ribs from parent items, but that's a different refactoring that I'd rather not do at the same time as a bugfix~~. EDIT: ah nevermind, this is needed for improving diagnostics like "use of undeclared lifetime" being "can't use generic parameters from outer item" instead.
r? `@compiler-errors`
|
|
|
|
rustc_resolve: fix instability in lib.rmeta contents
rust-lang/rust@23032f31c91f2 accidentally introduced some nondeterminism in the ordering of lib.rmeta files, which we caught in our bazel-based builds only recently due to being further behind than normal. In my testing, this fixes the issue.
|
|
Thanks to the introduction of `PatKind::Missing`.
|
|
Improve suggest construct with literal syntax instead of calling
Closing #138931
When constructing a structure through a format similar to calling a constructor, we can use verbose suggestions to hint at using literal syntax for clearer advice. The case of multiple fields is also considered here, provided that the field has the same number of arguments as CallExpr.
r? compiler
|
|
This came up in review, and it should help some future author
not introduce non-deterministic output here.
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Use the correct binder scope for elided lifetimes in assoc consts
Beyond diagnostics this has no real effect, and it's also just about a future incompat lint. But it causes ICEs in some refactorings that I'm doing, so trying to get it out of the way
|
|
r=compiler-errors
Don't deaggregate InvocationParent just to reaggregate it again
Also makes it easier to add more things to it in the future (which I am doing in some local experiments, so not really a reason to do this just now, but I think this PR stands on its own).
|
|
|
