summary refs log tree commit diff
path: root/compiler/rustc_resolve/src/late
AgeCommit message (Collapse)AuthorLines
2024-01-29Stop using `String` for error codes.Nicholas Nethercote-7/+7
Error codes are integers, but `String` is used everywhere to represent them. Gross! This commit introduces `ErrCode`, an integral newtype for error codes, replacing `String`. It also introduces a constant for every error code, e.g. `E0123`, and removes the `error_code!` macro. The constants are imported wherever used with `use rustc_errors::codes::*`. With the old code, we have three different ways to specify an error code at a use point: ``` error_code!(E0123) // macro call struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call \#[diag(name, code = "E0123")] // string struct Diag; ``` With the new code, they all use the `E0123` constant. ``` E0123 // constant struct_span_code_err!(dcx, span, E0123, "msg"); // constant \#[diag(name, code = E0123)] // constant struct Diag; ``` The commit also changes the structure of the error code definitions: - `rustc_error_codes` now just defines a higher-order macro listing the used error codes and nothing else. - Because that's now the only thing in the `rustc_error_codes` crate, I moved it into the `lib.rs` file and removed the `error_codes.rs` file. - `rustc_errors` uses that macro to define everything, e.g. the error code constants and the `DIAGNOSTIC_TABLES`. This is in its new `codes.rs` file.
2024-01-20Don't delete any lifetimes with boundstrevyn-1/+2
2024-01-17Make crate_inherent_impls fallible and stop using `track_errors` for itOli Scherer-4/+2
2024-01-12Delegation implementation: step 1Bryanskiy-1/+11
2024-01-10Rename consuming chaining methods on `DiagnosticBuilder`.Nicholas Nethercote-7/+7
In #119606 I added them and used a `_mv` suffix, but that wasn't great. A `with_` prefix has three different existing uses. - Constructors, e.g. `Vec::with_capacity`. - Wrappers that provide an environment to execute some code, e.g. `with_session_globals`. - Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`. The third case is exactly what we want, so this commit changes `DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`. Thanks to @compiler-errors for the suggestion.
2024-01-10Rename `struct_span_err!` as `struct_span_code_err!`.Nicholas Nethercote-5/+5
Because it takes an error code after the span. This avoids the confusing overlap with the `DiagCtxt::struct_span_err` method, which doesn't take an error code.
2024-01-08Remove all eight `DiagnosticBuilder::*_with_code` methods.Nicholas Nethercote-2/+2
These all have relatively low use, and can be perfectly emulated with a simpler construction method combined with `code` or `code_mv`.
2024-01-08Use chaining for `DiagnosticBuilder` construction and `emit`.Nicholas Nethercote-12/+13
To avoid the use of a mutable local variable, and because it reads more nicely.
2024-01-08Use chaining in `DiagnosticBuilder` construction.Nicholas Nethercote-9/+7
To avoid the use of a mutable local variable, and because it reads more nicely.
2024-01-05Rollup merge of #119638 - lukas-code:suggest-constructor-cycle-error, r=cjgillotMichael Goulet-5/+2
fix cyle error when suggesting to use associated function instead of constructor Fixes https://github.com/rust-lang/rust/issues/119625. The first commit fixes the infinite recursion and makes the cycle error actually show up. We do this by making the `Display` for `ty::Instance` impl respect `with_no_queries` so that it can be used in query descriptions. The second commit fixes the cycle error `resolver_for_lowering` -> `normalize` -> `resolve_instance` (for evaluating const) -> `lang_items` (for `drop_in_place`) -> `resolver_for_lowering` (for collecting lang items). We do this by simply skipping the suggestion when encountering an unnormalized type.
2024-01-05fix cycle error for "use constructor" suggestionLukas Markeffsky-5/+2
2024-01-05Rollup merge of #119151 - Jules-Bertholet:no-foreign-doc-hidden-suggest, ↵Matthias Krüger-5/+13
r=davidtwco Hide foreign `#[doc(hidden)]` paths in import suggestions Stops the compiler from suggesting to import foreign `#[doc(hidden)]` paths. ```@rustbot``` label A-suggestion-diagnostics
2024-01-03Rename some `Diagnostic` setters.Nicholas Nethercote-3/+3
`Diagnostic` has 40 methods that return `&mut Self` and could be considered setters. Four of them have a `set_` prefix. This doesn't seem necessary for a type that implements the builder pattern. This commit removes the `set_` prefixes on those four methods.
2023-12-24Remove `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-16/+10
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier access.
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-1/+1
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the most common diagnostic level. It makes sense to do likewise for the closely-related (and much more widely used) `DiagnosticBuilder` type, letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just `DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many multi-line things becoming single line things.
2023-12-22Auto merge of #118847 - eholk:for-await, r=compiler-errorsbors-1/+1
Add support for `for await` loops This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library. Given a loop like: ```rust for await i in iter { ... } ``` this is desugared to something like: ```rust let mut iter = iter.into_async_iter(); while let Some(i) = loop { match core::pin::Pin::new(&mut iter).poll_next(cx) { Poll::Ready(i) => break i, Poll::Pending => yield, } } { ... } ``` This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this. I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue. r? `@compiler-errors`
2023-12-20Refactor AST trait bound modifiersLeón Orell Valerian Liehr-3/+3
2023-12-20Hide foreign `#[doc(hidden)]` paths in import suggestionsJules Bertholet-5/+13
2023-12-19Plumb awaitness of for loopsEric Holk-1/+1
2023-12-12Rollup merge of #118889 - matthiaskrgr:compl_2023_2, r=WaffleLapkinJubilee-8/+3
more clippy::complexity fixes redundant_guards redundant_slicing filter_next needless_borrowed_reference useless_format
2023-12-12Rollup merge of #118884 - matthiaskrgr:auszweimacheins, r=NadrierilJubilee-1/+1
NFC: simplify merging of two vecs
2023-12-12more clippy::complexity fixesMatthias Krüger-8/+3
redundant_guards redundant_slicing filter_next needless_borrowed_reference useless_format
2023-12-12simplify merging of two vecsMatthias Krüger-1/+1
2023-12-12Rollup merge of #117914 - estebank:issue-85843, r=wesleywiserMatthias Krüger-12/+259
On borrow return type, suggest borrowing from arg or owned return type When we encounter a function with a return type that has an anonymous lifetime with no argument to borrow from, besides suggesting the `'static` lifetime we now also suggest changing the arguments to be borrows or changing the return type to be an owned type. ``` error[E0106]: missing lifetime specifier --> $DIR/variadic-ffi-6.rs:7:6 | LL | ) -> &usize { | ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static` | LL | ) -> &'static usize { | +++++++ help: instead, you are more likely to want to change one of the arguments to be borrowed... | LL | x: &usize, | + help: ...or alternatively, to want to return an owned value | LL - ) -> &usize { LL + ) -> usize { | ``` Fix #85843.
2023-11-27Dont suggest `!` for path in function call if it has generic argsMichael Goulet-6/+16
2023-11-25is_{some,ok}_andMichael Goulet-1/+1
2023-11-24Auto merge of #117934 - Young-Flash:dev, r=petrochenkovbors-3/+12
feat: make `let_binding_suggestion` more reasonable This is my first PR for rustc, which trying to fix https://github.com/rust-lang/rust/issues/117894, I am not familiar with some internal api so maybe some modification here isn't the way to go, appreciated for any review suggestion.
2023-11-23feat: make let_binding_suggestion more reasonableYoung-Flash-3/+12
2023-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-3/+3
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`. Then I had to remove a few unnecessary parens and muts that were exposed now.
2023-11-20let-chain fmtEsteban Küber-31/+24
2023-11-20Rely in resolve and not on path name for `&str` -> `String` suggestionEsteban Küber-49/+54
2023-11-20Do not consider traits as ownable in suggestionEsteban Küber-7/+55
2023-11-20Account for '_ in lifetime suggestionEsteban Küber-4/+15
2023-11-20Suggest 'a when trait object assoc type has '_Esteban Küber-12/+21
2023-11-20Fix incorrect lifetime suggestionEsteban Küber-2/+2
2023-11-20Tweak wordingEsteban Küber-4/+4
2023-11-20Account for impl Trait in lifetime suggestionEsteban Küber-5/+72
When encountering ```rust fn g(mut x: impl Iterator<Item = &()>) -> Option<&()> { /* */ } ``` Suggest ```rust fn g<'a>(mut x: impl Iterator<Item = &'a ()>) -> Option<&'a ()> { /* */ } ```
2023-11-20On borrow return type, suggest borrowing from arg or owned return typeEsteban Küber-12/+126
When we encounter a function with a return type that has an anonymous lifetime with no argument to borrow from, besides suggesting the `'static` lifetime we now also suggest changing the arguments to be borrows or changing the return type to be an owned type. ``` error[E0106]: missing lifetime specifier --> $DIR/variadic-ffi-6.rs:7:6 | LL | ) -> &usize { | ^ expected named lifetime parameter | = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static` | LL | ) -> &'static usize { | +++++++ help: instead, you are more likely to want to change one of the arguments to be borrowed... | LL | x: &usize, | + help: ...or alternatively, to want to return an owned value | LL - ) -> &usize { LL + ) -> usize { | ``` Fix #85843.
2023-11-19fix rebaseEsteban Küber-1/+4
2023-11-19review commentsEsteban Küber-22/+13
2023-11-19Account for number of arguments in suggestionEsteban Küber-5/+24
2023-11-19fix tidyEsteban Küber-1/+1
2023-11-19Suggest using builder on curly brace struct called as fnEsteban Küber-165/+178
2023-11-19Do not suggest struct literal when fields are privateEsteban Küber-35/+64
2023-11-19On private tuple struct, suggest `Default::default` when possibleEsteban Küber-1/+56
2023-11-19Don't sort `span_suggestions`, leave that to callerEsteban Küber-5/+9
2023-11-19When encountering struct fn call literal with private fields, suggest all ↵Esteban Küber-16/+74
builders When encountering code like `Box(42)`, suggest `Box::new(42)` and *all* other associated functions that return `-> Box<T>`.
2023-11-17On resolve error of `[rest..]`, suggest `[rest @ ..]`Esteban Küber-0/+27
When writing a pattern to collect multiple entries of a slice in a single binding, it is easy to misremember or typo the appropriate syntax to do so, instead writing the experimental `X..` pattern syntax. When we encounter a resolve error because `X` isn't available, we suggest `X @ ..` as an alternative. ``` error[E0425]: cannot find value `rest` in this scope --> $DIR/range-pattern-meant-to-be-slice-rest-pattern.rs:3:13 | LL | [1, rest..] => println!("{rest:?}"), | ^^^^ not found in this scope | help: if you meant to collect the rest of the slice in `rest`, use the at operator | LL | [1, rest @ ..] => println!("{rest:?}"), | + ``` Fix #88404.
2023-10-26Suggest assoc fn `new` when trying to build tuple struct with private fieldsEsteban Küber-1/+20
Fix #22488.
2023-10-13Format all the let chains in compilerMichael Goulet-75/+91