about summary refs log tree commit diff
path: root/compiler/rustc_errors/src/lib.rs
AgeCommit message (Collapse)AuthorLines
2022-09-14Compute `lint_levels` by definitionDeadbeef-1/+1
2022-09-12A SubstitutionPart is not a deletion if it replaces nothing with nothingMichael Goulet-10/+9
2022-09-10rustc_error, rustc_private, rustc_ast: Switch to stable hash containersNiklas Jonsson-3/+2
2022-09-08Rollup merge of #101545 - TaKO8Ki:remove-unnecessary-partialord-ord, r=oli-obkDylan DPC-1/+1
Remove unnecessary `PartialOrd` and `Ord`
2022-09-08remove unnecessary `PartialOrd` and `Ord`Takayuki Maeda-1/+1
2022-09-07Use niche-filling optimization even when multiple variants have data.Michael Benfield-2/+2
Fixes #46213
2022-09-06Report number of delayed bugs properly with -Ztreat-err-as-bugMichael Goulet-17/+22
2022-08-31Rollup merge of #101100 - compiler-errors:generalize-call-suggestions, ↵Matthias Krüger-4/+15
r=petrochenkov Make call suggestions more general and more accurate Cleans up some suggestions that have to do with adding `()` to make typeck happy. 1. Drive-by rename of `expr_t` to `base_ty` since it's the type of the `base_expr` 1. Autoderef until we get to a callable type in `suggest_fn_call`. 1. Don't erroneously suggest calling constructor when a method/field does not exist on it. 1. Suggest calling a method receiver if its function output has a method (e.g. `fn.method()` => `fn().method()`) 1. Extend call suggestions to type parameters, fn pointers, trait objects where possible 1. Suggest calling in operators too (fixes #101054) 1. Use `/* {ty} */` as argument placeholder instead of just `_`, which is confusing and makes suggestions look less like `if let` syntax.
2022-08-29Revert let_chains stabilizationNilstrieb-0/+1
This reverts commit 326646074940222d602f3683d0559088690830f4. This is the revert against master, the beta revert was already done in #100538.
2022-08-28Suggest calling when operator types mismatchMichael Goulet-4/+15
2022-08-21Add Handler::struct_diagnostic()Xiretza-0/+9
This unifies the struct_{warn,error,fatal}() methods in one generic method.
2022-08-20Rollup merge of #99935 - CAD97:unstable-syntax-lints, r=petrochenkovMatthias Krüger-12/+63
Reenable disabled early syntax gates as future-incompatibility lints - MCP: https://github.com/rust-lang/compiler-team/issues/535 The approach taken by this PR is - Introduce a new lint, `unstable_syntax_pre_expansion`, and reenable the early syntax gates to emit it - Use the diagnostic stashing mechanism to stash warnings the early warnings - When the hard error occurs post expansion, steal and cancel the early warning - Don't display any stashed warnings if errors are present to avoid the same noise problem that hiding type ascription errors is avoiding Commits are working commits, but in a coherent steps-to-implement manner. Can be squashed if desired. The preexisting `soft_unstable` lint seems like it would've been a good fit, but it is deny-by-default (appropriate for `#[bench]`) and these gates should be introduced as warn-by-default. It may be desirable to change the stash mechanism's behavior to not flush lint errors in the presence of other errors either (like is done for warnings here), but upgrading a stash-using lint from warn to error perhaps is enough of a request to see the lint that they shouldn't be hidden; additionally, fixing the last error to get new errors thrown at you always feels bad, so if we know the lint errors are present, we should show them. Using a new flag/mechanism for a "weak diagnostic" which is suppressed by other errors may also be desirable over assuming any stashed warnings are "weak," but this is the first user of stashing warnings and seems an appropriate use of stashing (it follows the "know more later to refine the diagnostic" pattern; here we learn that it's in a compiled position) so we get to define what it means to stash a non-hard-error diagnostic. cc `````@petrochenkov````` (seconded MCP)
2022-08-17Reenable early feature-gates as future-compat warningsChristopher Durham-0/+1
2022-08-17Don't treat stashed warnings as errorsChristopher Durham-12/+62
2022-08-17Rollup merge of #100379 - davidtwco:triagebot-diag, r=Mark-SimulacrumMatthias Krüger-0/+1
triagebot: add translation-related mention groups - Move some code around so that triagebot can ping relevant parties when translation logic is modified. - Add mention groups to triagebot for translation-related files/folders. - Auto-label pull requests with changes to translation-related files/folders with `A-translation`. r? `@Mark-Simulacrum`
2022-08-16Rollup merge of #100590 - TaKO8Ki:suggest-adding-array-length, r=compiler-errorsMatthias Krüger-0/+1
Suggest adding an array length if possible fixes #100448
2022-08-16suggest adding an array length if possibleTakayuki Maeda-0/+1
2022-08-15errors: move translation logic into moduleDavid Wood-0/+1
Just moving code around so that triagebot can ping relevant parties when translation logic is modified. Signed-off-by: David Wood <david.wood@huawei.com>
2022-08-12Adjust cfgsMark Rousskov-1/+0
2022-08-10errors: don't fail on broken primary translationsDavid Wood-1/+2
If a primary bundle doesn't contain a message then the fallback bundle is used. However, if the primary bundle's message is broken (e.g. it refers to a interpolated variable that the compiler isn't providing) then this would just result in a compiler panic. While there aren't any primary bundles right now, this is the type of issue that could come up once translation is further along. Signed-off-by: David Wood <david.wood@huawei.com>
2022-08-10Rollup merge of #99573 - tbodt:stabilize-backtrace, r=yaahcMatthias Krüger-1/+0
Stabilize backtrace This PR stabilizes the std::backtrace module. As of #99431, the std::Error::backtrace item has been removed, and so the rest of the backtrace feature is set to be stabilized. Previous discussion can be found in #72981, #3156. Stabilized API summary: ```rust pub mod std { pub mod backtrace { pub struct Backtrace { } pub enum BacktraceStatus { Unsupported, Disabled, Captured, } impl fmt::Debug for Backtrace {} impl Backtrace { pub fn capture() -> Backtrace; pub fn force_capture() -> Backtrace; pub const fn disabled() -> Backtrace; pub fn status(&self) -> BacktraceStatus; } impl fmt::Display for Backtrace {} } } ``` `@yaahc`
2022-08-05move DiagnosticArgFromDisplay into rustc_errorsMichael Goulet-2/+2
2022-08-02Stabilize backtraceTheodore Dubois-1/+0
2022-07-19Mention first and last macro in backtraceMichael Goulet-0/+1
2022-07-11rename a methodTakayuki Maeda-1/+1
2022-07-11implement `is_accessible_span`Takayuki Maeda-1/+1
2022-07-05errors: introduce `DecorateLint`David Wood-1/+1
Add a new trait to be generated by diagnostic derives which uses a `LintDiagnosticBuilder`. Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-05lint: `LintDiagnosticBuilder` into `rustc_errors`David Wood-1/+1
Signed-off-by: David Wood <david.wood@huawei.com>
2022-07-03Auto merge of #98673 - pietroalbini:pa-bootstrap-update, r=Mark-Simulacrumbors-22/+22
Bump bootstrap compiler r? `@Mark-Simulacrum`
2022-07-01update cfg(bootstrap)sPietro Albini-22/+22
2022-06-30use "or pattern"Tshepang Mbambo-1/+1
2022-06-17Rollup merge of #97798 - ↵Dylan DPC-1/+1
WaffleLapkin:allow_for_suggestions_that_are_quite_far_away_from_each_other, r=estebank Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed "the problem" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230. I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so), but I want to at least discuss the result. Here is an example of how this changes the output: Before: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l, 4 | 5 | 6 | 7 | 8 | ... ``` After: ```text help: consider enclosing expression in a block | 3 ~ 'l: { match () { () => break 'l, 4 | ... 31| 32~ } }; | ``` r? `@estebank` `@rustbot` label +A-diagnostics +A-suggestion-diagnostics
2022-06-16Fix a typoMaybe Waffle-1/+1
!(a & b) = !a | !b
2022-06-16Rollup merge of #97757 - xFrednet:rfc-2383-expect-with-force-warn, ↵Matthias Krüger-32/+64
r=wesleywiser,flip1995 Support lint expectations for `--force-warn` lints (RFC 2383) Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope. This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust. This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix. --- r? `@wesleywiser` cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. :upside_down_face: Follow-up of: https://github.com/rust-lang/rust/pull/87835 Issue: https://github.com/rust-lang/rust/issues/85549 Yeah, and that's it.
2022-06-16Support lint expectations for `--force-warn` lints (RFC 2383)xFrednet-32/+64
2022-06-14Rollup merge of #97948 - davidtwco:diagnostic-translation-lints, r=oli-obkDylan DPC-0/+23
lint: add diagnostic translation migration lints Introduce allow-by-default lints for checking whether diagnostics are written in `SessionDiagnostic` or `AddSubdiagnostic` impls and whether diagnostics are translatable. These lints can be denied for modules once they are fully migrated to impls and translation. These lints are intended to be temporary - once all diagnostics have been changed then we can just change the APIs we have and that will enforce these constraints thereafter. r? `````@oli-obk`````
2022-06-10lint: add diagnostic translation migration lintsDavid Wood-0/+23
Introduce allow-by-default lints for checking whether diagnostics are written in `SessionDiagnostic`/`AddSubdiagnostic` impls and whether diagnostics are translatable. These lints can be denied for modules once they are fully migrated to impls and translation. Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-10Rollup merge of #97718 - xFrednet:95540-delayed-good-path-ice-for-expect, ↵Yuki Okushi-12/+17
r=wesleywiser Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383) Fixes a small ICE with the `delayed_good_path_bug` check. --- r? ``@wesleywiser`` cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this closes: https://github.com/rust-lang/rust/issues/95540 cc: https://github.com/rust-lang/rust/issues/85549
2022-06-04Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)xFrednet-12/+17
2022-06-03Fully stabilize NLLJack Huey-1/+0
2022-05-30errors: simplify referring to fluent attributesDavid Wood-1/+2
To render the message of a Fluent attribute, the identifier of the Fluent message must be known. `DiagnosticMessage::FluentIdentifier` contains both the message's identifier and optionally the identifier of an attribute. Generated constants for each attribute would therefore need to be named uniquely (amongst all error messages) or be able to refer to only the attribute identifier which will be combined with a message identifier later. In this commit, the latter strategy is implemented as part of the `Diagnostic` type's functions for adding subdiagnostics of various kinds. Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-24macros: introduce `fluent_messages` macroDavid Wood-2/+2
Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic. For example, given the following invocation of the macro.. ```ignore (rust) fluent_messages! { typeck => "./typeck.ftl", } ``` ..where `typeck.ftl` has the following contents.. ```fluent typeck-field-multiply-specified-in-initializer = field `{$ident}` specified more than once .label = used more than once .label-previous-use = first use of `{$ident}` ``` ...then the macro parse the Fluent resource, emitting a diagnostic if it fails to do so, and will generate the following code: ```ignore (rust) pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[ include_str!("./typeck.ftl"), ]; mod fluent_generated { mod typeck { pub const field_multiply_specified_in_initializer: DiagnosticMessage = DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer"); pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage = DiagnosticMessage::fluent_attr( "typeck-field-multiply-specified-in-initializer", "previous-use-label" ); } } ``` When emitting a diagnostic, the generated constants can be used as follows: ```ignore (rust) let mut err = sess.struct_span_err( span, fluent::typeck::field_multiply_specified_in_initializer ); err.span_default_label(span); err.span_label( previous_use_span, fluent::typeck::field_multiply_specified_in_initializer_label_previous_use ); err.emit(); ``` Signed-off-by: David Wood <david.wood@huawei.com>
2022-05-20Remove `crate` visibility usage in compilerJacob Pratt-1/+0
2022-05-08Fixed typo in docs and correct doc linksFridtjof Stoldt-2/+2
Co-authored-by: Philipp Krones <hello@philkrones.com>
2022-05-08Only assert for unstable expectation ids after conversion (RFC 2383)xFrednet-6/+17
This ICE was reported by `@matthiaskrgr`. A big THANK YOU to him. See `rust#94953`
2022-05-02fix most compiler/ doctestsElliot Roberts-2/+2
2022-04-29macros: subdiagnostic deriveDavid Wood-2/+2
Add a new derive, `#[derive(SessionSubdiagnostic)]`, which enables deriving structs for labels, notes, helps and suggestions. Signed-off-by: David Wood <david.wood@huawei.com>
2022-04-27Add --json unused-externs-silent with original behaviourJeremy Fitzhardinge-2/+7
Since Cargo wants to do its own fatal error handling for unused dependencies, add the option `--json unused-externs-silent` which has the original behaviour of not indicating non-zero exit status for `deny`/`forbid`-level unused dependencies.
2022-04-27Plumb through rustc_lint_defs::Level as enum rather than string.Jeremy Fitzhardinge-3/+3
2022-04-27Make --json unused-extern deny/forbid level messages cause exit with error ↵Jeremy Fitzhardinge-1/+7
status Closes: https://github.com/rust-lang/rust/issues/96068