| Age | Commit message (Collapse) | Author | Lines |
|
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 removes the assumption that the start of a use statement
will always be on one line with a single space - which was silly in the
first place.
|
|
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 extends the suggestion to handle imports that are aliased to
another name.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Stephan Schauerte <stephan.schauerte@gmail.com>
|
|
r=petrochenkov,QuietMisdreavus
RFC 2008: Enum Variants
Part of #44109. See [Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/rfc-2008/near/132663140) for previous discussion.
r? @petrochenkov
cc @nikomatsakis
|
|
|
|
This commit removes the check that disallows the `#[non_exhaustive]`
attribute from being placed on enum variants and removes the associated
tests.
Further, this commit lowers the visibility of enum variant constructors
when the variant is marked as non-exhaustive.
|
|
Provide suggestion when using field access instead of path
When trying to access an associated constant as if it were a field of
an instance, provide a suggestion for the correct syntax.
Fix #57316.
|
|
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.
|
|
|
|
When trying to access an associated constant as if it were a field of
an instance, provide a suggestion for the correct syntax.
|
|
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.
|
|
This commit removes `CtorOf` from `Node::Ctor` as the parent of the
constructor can be determined by looking at the node's parent in the few
places where knowing this is necessary.
|
|
|
|
|
|
Fix ICE with const generic param in struct
Fixes https://github.com/rust-lang/rust/issues/59340.
r? @petrochenkov
|
|
Do not encode gensymed imports in metadata
(Unless they are underscore `_` imports which are re-gensymed on crate loading, see https://github.com/rust-lang/rust/pull/56392.)
We cannot encode gensymed imports properly in metadata and if we encode them improperly, we can get erroneous name conflicts downstream.
Gensymed imports are produced by the compiler, so we control their set, and can be sure that none of them needs being encoded for use from other crates.
A workaround that fixes https://github.com/rust-lang/rust/issues/59243.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
use suggestions for "enum instead of variant" error
|
|
|
|
|
|
|
|
|
|
resolve: Account for new importable entities
Fixes the ICE encountered in https://github.com/rust-lang/rust/pull/58837
r? @Centril
|
|
Remove methods `Attribute::span` and `MetaItem::span` duplicating public fields
|