about summary refs log tree commit diff
path: root/compiler/rustc_resolve/src
AgeCommit message (Collapse)AuthorLines
2023-09-12`#[diagnostic::on_unimplemented]` without filtersGeorg Semmler-2/+3
This commit adds support for a `#[diagnostic::on_unimplemented]` attribute with the following options: * `message` to customize the primary error message * `note` to add a customized note message to an error message * `label` to customize the label part of the error message Co-authored-by: León Orell Valerian Liehr <me@fmease.dev> Co-authored-by: Michael Goulet <michael@errs.io>
2023-09-12Auto merge of #115689 - Alexendoo:clippy-doc-comments, ↵bors-1/+88
r=notriddle,Manishearth,flip1995 Reuse rustdoc's doc comment handling in Clippy Moves `source_span_for_markdown_range` and `span_of_attrs` (renamed to `span_of_fragments`) to `rustc_resolve::rustdoc` so it can be used in Clippy Fixes https://github.com/rust-lang/rust-clippy/issues/10277 Fixes https://github.com/rust-lang/rust-clippy/issues/5593 Fixes https://github.com/rust-lang/rust-clippy/issues/10263 Fixes https://github.com/rust-lang/rust-clippy/issues/2581
2023-09-11Move let expression checking to parsingMatthew Jasper-1/+1
There was an incomplete version of the check in parsing and a second version in AST validation. This meant that some, but not all, invalid uses were allowed inside macros/disabled cfgs. It also means that later passes have a hard time knowing when the let expression is in a valid location, sometimes causing ICEs. - Add a field to ExprKind::Let in AST/HIR to mark whether it's in a valid location. - Suppress later errors and MIR construction for invalid let expressions.
2023-09-11Rollup merge of #115744 - fmease:fix-e0401, r=compiler-errorsMatthias Krüger-38/+63
Improve diagnostic for generic params from outer items (E0401) Generalize the wording of E0401 to talk about *outer items* instead of *outer functions* since the current phrasing is outdated. The outer item can be a function, constant, trait, ADT or impl block (see the new UI test for the more exotic examples). Further, don't suggest introducing generic parameters to constant items unless the feature `generic_const_items` is enabled. Lastly, make E0401 translatable while we're at it. Fixes #115720.
2023-09-11Auto merge of #115504 - bvanjoi:error-struct, r=cjgillotbors-8/+17
resolve: derive diag for undetermined macro resolution simply for neatness.
2023-09-10Do not suggest generic const items unless enabledLeón Orell Valerian Liehr-1/+5
2023-09-10Make E0401 translatableLeón Orell Valerian Liehr-19/+52
2023-09-10Generalize E0401León Orell Valerian Liehr-24/+12
2023-09-09Use `FreezeLock` for `CStore`John Kåre Alsaker-3/+3
2023-09-08Reuse rustdoc's doc comment handling in ClippyAlex Macleod-1/+88
2023-09-07Find lowest span out of use + attrsMichael Goulet-1/+7
2023-09-04resolve: derive diag for undetermined macro resolutionbohan-8/+17
2023-09-02Auto merge of #115429 - compiler-errors:assoc-ct-lt-fallthrough, r=cjgillotbors-34/+29
Fall through when resolving elided assoc const lifetimes `@QuineDot` makes a good point in https://github.com/rust-lang/rust/issues/115010#issuecomment-1702127634 that we probably should not accept *more* code due to #115011 even though that code will eventually become a forbid-warning in a few versions (https://github.com/rust-lang/rust/issues/115010#issuecomment-1701598067). Fall through when walking thru the `AnonymousWarnToStatic` (renamed to `AnonymousWarn`) rib so that we can resolve as a fresh lifetime like we did before.
2023-09-01Auto merge of #113126 - Bryanskiy:delete_old, r=petrochenkovbors-6/+0
Replace old private-in-public diagnostic with type privacy lints Next part of RFC https://github.com/rust-lang/rust/issues/48054. r? `@petrochenkov`
2023-09-01Fall through when resolving elided assoc const lifetimesMichael Goulet-34/+29
2023-08-31Auto merge of #115366 - ↵bors-0/+1
compiler-errors:associated-type-bound-implicit-lifetimes, r=jackh726 Capture lifetimes for associated type bounds destined to be lowered to opaques Some associated type bounds get lowered to opaques, but they're not represented in the AST as opaques. That means that we never collect lifetimes for them (`record_lifetime_params_for_impl_trait`) which are used currently for RPITITs, which capture all of their in-scope lifetimes[^1]. This means that the nested RPITITs that arise from some type like `impl Foo<Type: Bar>` (~> `impl Foo<Type = impl Bar>`) don't capture any lifetimes, leading to ICEs. This PR makes sure we collect the lifetimes for associated type bounds as well, and make sure that they are set up correctly for opaque type lowering later. Fixes #115360 [^1]: #114489
2023-08-31fix(resolve): update def if binding is warning ambiguitybohan-3/+6
2023-08-30Capture lifetimes for associated type bounds destined to be lowered to opaquesMichael Goulet-0/+1
2023-08-28RPITITs capture all their lifetimesMichael Goulet-12/+9
2023-08-24Auto merge of #113408 - petrochenkov:bindintern2, r=cjgillotbors-79/+133
resolve: Stop creating `NameBinding`s on every use, create them once per definition instead `NameBinding` values are supposed to be unique, use referential equality, and be created once for every name declaration. Before this PR many `NameBinding`s were created on name use, rather than on name declaration, because it's sufficiently cheap, and comparisons are not actually used in practice for some binding kinds. This PR makes `NameBinding`s consistently unique and created on name declaration. There are two special cases - for extern prelude names creating `NameBinding` requires loading the corresponding crate, which is expensive, so such bindings are created lazily on first use, but they still keep the uniqueness by being reused on further uses. - for legacy derive helpers (helper attributes written before derives that introduce them) the declaration and the use is basically the same thing (that's one of the reasons why they are deprecated), so they are still created on use, but we can still maybe do a bit better in a way that I described in FIXME in the last commit.
2023-08-24Auto merge of #115094 - Mark-Simulacrum:bootstrap-update, r=ozkanonurbors-1/+1
Update bootstrap compiler to 1.73.0 beta
2023-08-24resolve: Leave a comment about name bindings for legacy derive helpersVadim Petrochenkov-0/+5
2023-08-24resolve: Make bindings for derive helper attributes uniqueVadim Petrochenkov-28/+25
instead of creating them every time such attribute is used
2023-08-24resolve: Make bindings for crate roots uniqueVadim Petrochenkov-5/+23
instead of creating a new every time `crate` or `$crate` is used
2023-08-24resolve: Pre-intern tool module bindingsVadim Petrochenkov-2/+11
2023-08-24resolve: Make bindings from extern prelude uniqueVadim Petrochenkov-19/+38
instead of creating a new every time a name from extern prelude is accessed
2023-08-24resolve: Pre-intern builtin name bindingsVadim Petrochenkov-25/+31
2023-08-23Bump cfg(bootstrap)Mark Rousskov-1/+1
2023-08-22Rollup merge of #115011 - compiler-errors:warn-on-elided-assoc-ct-lt, r=cjgillotMichael Goulet-24/+55
Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`) Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831). I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: https://github.com/rust-lang/rust/pull/114716#issuecomment-1682091952 This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
2023-08-20Warn on elided lifetimes in associated constantsMichael Goulet-24/+55
2023-08-18narrow down the lint trigger constraintKyle Lin-6/+13
2023-08-18fomar filesKyle Lin-1/+8
2023-08-18Still resolving rustdoc resolution panickingKyle Lin-2/+4
2023-08-18Fix resolution cachingKyle Lin-8/+49
2023-08-11rustc: Move `features` from `Session` to `GlobalCtxt`Vadim Petrochenkov-3/+4
Removes two pieces of mutable state. Follow up to #114622.
2023-08-10Rollup merge of #114622 - petrochenkov:noplugin, r=oli-obkMichael Goulet-3/+3
rustc: Move `crate_types` and `stable_crate_id` from `Session` to `GlobalCtxt` Removes two pieces of mutable state. Follow up to https://github.com/rust-lang/rust/pull/114578.
2023-08-09rustc: Move `crate_types` from `Session` to `GlobalCtxt`Vadim Petrochenkov-3/+3
Removes a piece of mutable state. Follow up to #114578.
2023-08-08fix: not insert missing lifetime for `ConstParamTy`bohan-2/+4
2023-08-08Rollup merge of #114566 - fmease:type-alias-laziness-is-crate-specific, ↵Matthias Krüger-7/+10
r=oli-obk Store the laziness of type aliases in their `DefKind` Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not. With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*: Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates. As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions. --- This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold. `@rustbot` label F-lazy_type_alias r? `@oli-obk`
2023-08-07Store the laziness of type aliases in the DefKindLeón Orell Valerian Liehr-7/+10
2023-08-07Rollup merge of #114549 - chenyukang:yukang-review-resolve-part, r=petrochenkovMatthias Krüger-38/+35
Style fix and refactor on resolve diagnostics - coding style - refactor api of `span_look_ahead`
2023-08-06refactor on span_look_aheadyukang-10/+10
2023-08-06Auto merge of #114487 - compiler-errors:opaques-refactoring-idk, r=cjgillotbors-30/+29
Consolidate opaque ty and async fn lowering code The codepaths for lowering "regular" opaques and async fn were almost identical, modulo some bookkeeping that seemed pretty easy to consolidate. r? `@cjgillot`
2023-08-06Rollup merge of #114503 - ↵Matthias Krüger-1/+2
chenyukang:yukang-fix-114433-unused-qualifications, r=compiler-errors Remove invalid lint when there is a generic argument in prefix path Fixes #114433
2023-08-05a function is just another AnonymousCreateParameter ribMichael Goulet-30/+28
2023-08-05Consolidate opaque ty and async fn lowering codeMichael Goulet-0/+1
2023-08-05Auto merge of #109348 - cjgillot:issue-109146, r=petrochenkovbors-1/+1
Resolve visibility paths as modules not as types. Asking for a resolution with `opt_ns = Some(TypeNS)` allows path resolution to look for type-relative paths, leaving unresolved segments behind. However, for visibility paths we really need to look for a module, so we need to pass `opt_ns = None`. Fixes https://github.com/rust-lang/rust/issues/109146 r? `@petrochenkov`
2023-08-05Remove invalid lint when there is a generic argument in prefix pathyukang-1/+2
2023-08-04Rollup merge of #114434 - Nilstrieb:indexing-spans, r=est31Matthias Krüger-1/+1
Improve spans for indexing expressions fixes #114388 Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR. r? compiler-errors
2023-08-04Improve spans for indexing expressionsNilstrieb-1/+1
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 06:03:34 +0000