summary refs log tree commit diff
path: root/compiler/rustc_borrowck/src/diagnostics
AgeCommit message (Collapse)AuthorLines
2024-01-30Remove the lifetime from `DiagnosticArgValue`.Nicholas Nethercote-1/+1
Because it's almost always static. This makes `impl IntoDiagnosticArg for DiagnosticArgValue` trivial, which is nice. There are a few diagnostics constructed in `compiler/rustc_mir_build/src/check_unsafety.rs` and `compiler/rustc_mir_transform/src/errors.rs` that now need symbols converted to `String` with `to_string` instead of `&str` with `as_str`, but that' no big deal, and worth it for the simplifications elsewhere.
2024-01-29Stop using `String` for error codes.Nicholas Nethercote-1/+3
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-19Rollup merge of #120126 - sjwang05:issue-102269, r=compiler-errorsMatthias Krüger-7/+90
Suggest `.swap()` when encountering conflicting borrows from `mem::swap` on a slice This PR modifies the existing suggestion by matching on `[ProjectionElem::Deref, ProjectionElem::Index(_)]` instead of just `[ProjectionElem::Index(_)]`, which caused us to miss many cases. Additionally, it adds a more specific, machine-applicable suggestion in the case we determine `mem::swap` was used to swap elements in a slice. Closes #102269
2024-01-19Suggest .swap() instead of mem::swap() in more casessjwang05-7/+92
2024-01-16Auto merge of #116520 - Enselic:large-copy-into-fn, r=oli-obkbors-6/+11
large_assignments: Lint on specific large args passed to functions Requires lowering function call arg spans down to MIR, which is done in the second commit. Part of #83518 Also see * https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/arg.20Spans.20for.20TerminatorKind.3A.3ACall.3F * https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/move_size_limit.20lint r? `@oli-obk` (E-mentor)
2024-01-15compiler: Lower fn call arg spans down to MIRMartin Nordholts-6/+11
To enable improved accuracy of diagnostics in upcoming commits.
2024-01-15Rollup merge of #119897 - compiler-errors:fulfillment-errors, r=lcnrMatthias Krüger-2/+2
`OutputTypeParameterMismatch` -> `SignatureMismatch` I'm probably missing something that made this rename more complicated. What did you end up getting stuck on when renaming this selection error, `@lcnr?` **also** I renamed the `FulfillmentErrorCode` variants. This is just churn but I wanted to do it forever. I can move it out of this PR if desired. r? lcnr
2024-01-13Make InferCtxtExt::could_impl_trait less messed upMichael Goulet-13/+18
2024-01-12Remove redundant Code from FulfillmentErrorCode variantsMichael Goulet-2/+2
2024-01-11Rollup merge of #118915 - compiler-errors:alias-nits, r=lcnrMatthias Krüger-2/+2
Add some comments, add `can_define_opaque_ty` check to `try_normalize_ty_recur` Follow-up from #117278, since I was recently re-reviewing this code.
2024-01-10Simplify some redundant namesMichael Goulet-2/+2
2024-01-10Rename consuming chaining methods on `DiagnosticBuilder`.Nicholas Nethercote-6/+6
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-10Add `DiagCtxt::delayed_bug`.Nicholas Nethercote-2/+2
We have `span_delayed_bug` and often pass it a `DUMMY_SP`. This commit adds `delayed_bug`, which matches pairs like `err`/`span_err` and `warn`/`span_warn`.
2024-01-10Rename `struct_span_err!` as `struct_span_code_err!`.Nicholas Nethercote-3/+9
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-08Use chaining in `DiagnosticBuilder` construction.Nicholas Nethercote-26/+20
To avoid the use of a mutable local variable, and because it reads more nicely.
2024-01-08Make `DiagnosticBuilder::emit` consuming.Nicholas Nethercote-1/+1
This works for most of its call sites. This is nice, because `emit` very much makes sense as a consuming operation -- indeed, `DiagnosticBuilderState` exists to ensure no diagnostic is emitted twice, but it uses runtime checks. For the small number of call sites where a consuming emit doesn't work, the commit adds `DiagnosticBuilder::emit_without_consuming`. (This will be removed in subsequent commits.) Likewise, `emit_unless` becomes consuming. And `delay_as_bug` becomes consuming, while `delay_as_bug_without_consuming` is added (which will also be removed in subsequent commits.) All this requires significant changes to `DiagnosticBuilder`'s chaining methods. Currently `DiagnosticBuilder` method chaining uses a non-consuming `&mut self -> &mut Self` style, which allows chaining to be used when the chain ends in `emit()`, like so: ``` struct_err(msg).span(span).emit(); ``` But it doesn't work when producing a `DiagnosticBuilder` value, requiring this: ``` let mut err = self.struct_err(msg); err.span(span); err ``` This style of chaining won't work with consuming `emit` though. For that, we need to use to a `self -> Self` style. That also would allow `DiagnosticBuilder` production to be chained, e.g.: ``` self.struct_err(msg).span(span) ``` However, removing the `&mut self -> &mut Self` style would require that individual modifications of a `DiagnosticBuilder` go from this: ``` err.span(span); ``` to this: ``` err = err.span(span); ``` There are *many* such places. I have a high tolerance for tedious refactorings, but even I gave up after a long time trying to convert them all. Instead, this commit has it both ways: the existing `&mut self -> Self` chaining methods are kept, and new `self -> Self` chaining methods are added, all of which have a `_mv` suffix (short for "move"). Changes to the existing `forward!` macro lets this happen with very little additional boilerplate code. I chose to add the suffix to the new chaining methods rather than the existing ones, because the number of changes required is much smaller that way. This doubled chainging is a bit clumsy, but I think it is worthwhile because it allows a *lot* of good things to subsequently happen. In this commit, there are many `mut` qualifiers removed in places where diagnostics are emitted without being modified. In subsequent commits: - chaining can be used more, making the code more concise; - more use of chaining also permits the removal of redundant diagnostic APIs like `struct_err_with_code`, which can be replaced easily with `struct_err` + `code_mv`; - `emit_without_diagnostic` can be removed, which simplifies a lot of machinery, removing the need for `DiagnosticBuilderState`.
2024-01-05Remove `hir::Guard`Matthew Jasper-1/+1
Use Expr instead. Use `ExprKind::Let` to represent if let guards.
2023-12-30is_coroutine -> is_coroutine_or_closureMichael Goulet-2/+2
2023-12-28Remove movability from TyKind::CoroutineMichael Goulet-4/+3
2023-12-28Fix some commentscuishuang-1/+1
Signed-off-by: cuishuang <imcusg@gmail.com>
2023-12-26Auto merge of #119258 - compiler-errors:closure-kind, r=eholkbors-102/+149
Make closures carry their own ClosureKind Right now, we use the "`movability`" field of `hir::Closure` to distinguish a closure and a coroutine. This is paired together with the `CoroutineKind`, which is located not in the `hir::Closure`, but the `hir::Body`. This is strange and redundant. This PR introduces `ClosureKind` with two variants -- `Closure` and `Coroutine`, which is put into `hir::Closure`. The `CoroutineKind` is thus removed from `hir::Body`, and `Option<Movability>` no longer needs to be a stand-in for "is this a closure or a coroutine". r? eholk
2023-12-25Flatten matchMichael Goulet-47/+67
2023-12-25Only regular coroutines have movabilityMichael Goulet-28/+28
2023-12-25Make closures carry their own ClosureKind, rather than deducing what it is ↵Michael Goulet-89/+116
from movability
2023-12-24Remove `MirBorrowckCtxt` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-1/+1
2023-12-24Remove `Session` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-21/+19
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier access.
2023-12-22Rollup merge of #119198 - compiler-errors:desugaring, r=eholkMichael Goulet-40/+55
Split coroutine desugaring kind from source What a coroutine is desugared from (gen/async gen/async) should be separate from where it comes (fn/block/closure).
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-66/+36
`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-22Split coroutine desugaring kind from sourceMichael Goulet-40/+55
2023-12-22Auto merge of #118824 - aliemjay:perf-region-cons, r=compiler-errorsbors-7/+12
use Vec for region constraints instead of BTreeMap ~1% perf gain Diagnostic regressions need more investigation. r? `@ghost`
2023-12-18Rename many `DiagCtxt` arguments.Nicholas Nethercote-2/+2
2023-12-18Rename `Session::span_diagnostic` as `Session::dcx`.Nicholas Nethercote-7/+7
2023-12-18Rename `Handler` as `DiagCtxt`.Nicholas Nethercote-1/+1
2023-12-17fix diagnostic regresssionAli MJ Al-Nasrawy-7/+12
2023-12-15banish hir::GenericBound::LangItemTraitMichael Goulet-20/+10
2023-12-12Move some methods from `tcx.hir()` to `tcx`zetanumbers-47/+48
Renamings: - find -> opt_hir_node - get -> hir_node - find_by_def_id -> opt_hir_node_by_def_id - get_by_def_id -> hir_node_by_def_id Fix rebase changes using removed methods Use `tcx.hir_node_by_def_id()` whenever possible in compiler Fix clippy errors Fix compiler Apply suggestions from code review Co-authored-by: Vadim Petrochenkov <vadim.petrochenkov@gmail.com> Add FIXME for `tcx.hir()` returned type about its removal Simplify with with `tcx.hir_node_by_def_id`
2023-12-11remove some redundant clonesMatthias Krüger-1/+1
2023-12-08Implement `async gen` blocksMichael Goulet-4/+30
2023-12-04Provide more suggestions for cloning immutable bindingsEsteban Küber-1/+101
When encountering multiple mutable borrows, suggest cloning and adding derive annotations as needed. ``` error[E0596]: cannot borrow `sm.x` as mutable, as it is behind a `&` reference --> $DIR/accidentally-cloning-ref-borrow-error.rs:32:9 | LL | foo(&mut sm.x); | ^^^^^^^^^ `sm` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: `Str` doesn't implement `Clone`, so this call clones the reference `&Str` --> $DIR/accidentally-cloning-ref-borrow-error.rs:31:21 | LL | let mut sm = sr.clone(); | ^^^^^^^ help: consider annotating `Str` with `#[derive(Clone)]` | LL + #[derive(Clone)] LL | struct Str { | help: consider specifying this binding's type | LL | let mut sm: &mut Str = sr.clone(); | ++++++++++ ``` ``` error[E0596]: cannot borrow `*inner` as mutable, as it is behind a `&` reference --> $DIR/issue-91206.rs:14:5 | LL | inner.clear(); | ^^^^^ `inner` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: you can `clone` the `Vec<usize>` value and consume it, but this might not be your desired behavior --> $DIR/issue-91206.rs:11:17 | LL | let inner = client.get_inner_ref(); | ^^^^^^^^^^^^^^^^^^^^^^ help: consider specifying this binding's type | LL | let inner: &mut Vec<usize> = client.get_inner_ref(); | +++++++++++++++++ ```
2023-12-04Deduplicate some logicEsteban Küber-110/+51
2023-12-04Tweak output on specific caseEsteban Küber-1/+21
2023-12-04Suggest cloning and point out obligation errors on move errorEsteban Küber-48/+124
When encountering a move error, look for implementations of `Clone` for the moved type. If there is one, check if all its obligations are met. If they are, we suggest cloning without caveats. If they aren't, we suggest cloning while mentioning the unmet obligations, potentially suggesting `#[derive(Clone)]` when appropriate. ``` error[E0507]: cannot move out of a shared reference --> $DIR/suggest-clone-when-some-obligation-is-unmet.rs:20:28 | LL | let mut copy: Vec<U> = map.clone().into_values().collect(); | ^^^^^^^^^^^ ------------- value moved due to this method call | | | move occurs because value has type `HashMap<T, U, Hash128_1>`, which does not implement the `Copy` trait | note: `HashMap::<K, V, S>::into_values` takes ownership of the receiver `self`, which moves value --> $SRC_DIR/std/src/collections/hash/map.rs:LL:COL help: you could `clone` the value and consume it, if the `Hash128_1: Clone` trait bound could be satisfied | LL | let mut copy: Vec<U> = <HashMap<T, U, Hash128_1> as Clone>::clone(&map.clone()).into_values().collect(); | ++++++++++++++++++++++++++++++++++++++++++++ + help: consider annotating `Hash128_1` with `#[derive(Clone)]` | LL + #[derive(Clone)] LL | pub struct Hash128_1; | ``` Fix #109429.
2023-12-04Tweak `.clone()` suggestion to work in more casesEsteban Küber-3/+17
When going through auto-deref, the `<T as Clone>` impl sometimes needs to be specified for rustc to actually clone the value and not the reference. ``` error[E0507]: cannot move out of dereference of `S` --> $DIR/needs-clone-through-deref.rs:15:18 | LL | for _ in self.clone().into_iter() {} | ^^^^^^^^^^^^ ----------- value moved due to this method call | | | move occurs because value has type `Vec<usize>`, which does not implement the `Copy` trait | note: `into_iter` takes ownership of the receiver `self`, which moves value --> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL help: you can `clone` the value and consume it, but this might not be your desired behavior | LL | for _ in <Vec<usize> as Clone>::clone(&self.clone()).into_iter() {} | ++++++++++++++++++++++++++++++ + ``` CC #109429.
2023-12-02Use `Session::diagnostic` in more places.Nicholas Nethercote-5/+5
2023-12-02Rename `HandlerInner::delay_span_bug` as `HandlerInner::span_delayed_bug`.Nicholas Nethercote-4/+4
Because the corresponding `Level` is `DelayedBug` and `span_delayed_bug` follows the pattern used everywhere else: `span_err`, `span_warning`, etc.
2023-11-28Fix a typo in a `format_args!` noteJosh Stone-1/+1
2023-11-26Auto merge of #118316 - Mark-Simulacrum:delete-copy-to-upvars, r=cjgillotbors-14/+12
Remove borrowck Upvar duplication This cuts out an extra allocation and copying over from the already cached closure capture information.
2023-11-26Remove Upvar duplicationMark Rousskov-14/+12
This cuts out an extra allocation and copying over from the already cached closure capture information.
2023-11-26Rollup merge of #118311 - bvanjoi:merge_coroutinue_into_closure, r=petrochenkovGuillaume Gomez-1/+8
merge `DefKind::Coroutine` into `Defkind::Closure` Related to #118188 We no longer need to be concerned about the precise type whether it's `DefKind::Closure` or `DefKind::Coroutine`. Furthermore, thanks for the great work done by `@petrochenkov` on investigating https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Why.20does.20it.20hang.20when.20querying.20.EF.BB.BF.60opt_def_kind.60.3F r? `@petrochenkov`
2023-11-26merge `DefKind::Coroutine` into `DefKind::Closure`bohan-1/+8
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-25 06:56:20 +0000