Support for emission of notes was added in f8ebc72 but `emit_note` and
`create_note` functions weren't added to `Handler`.
Signed-off-by: David Wood <david.wood@huawei.com>
Collect and emit proper backtraces for `delay_span_bug`s
This is a follow-up to #106317, which addresses this comment (https://github.com/rust-lang/rust/issues/106267#issuecomment-1367507507) which notes that `delay_span_bug`s' backtraces are nonsense.
Captures and emits the backtrace of the delayed span bug when it's *created*, rather than using the backtrace of the place where delayed bugs are flushed.
---
To test, I delayed a span bug during HIR typeck, specifically in `typeck_with_fallback`...
Before, note `flush_delayed` on frame 18. This is at the end of the compilation session, far from where the bug is being delayed.
```
error: internal compiler error: test
--> /home/ubuntu/test.rs:1:1
|
1 | fn main() {}
| ^^^^^^^^^
|
= note: delayed at compiler/rustc_hir_typeck/src/lib.rs:196:14
thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1634:13
stack backtrace:
0: 0x7f9c3ec69dd1 - std::backtrace_rs::backtrace::libunwind::trace::h26056f81198c6594
at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7f9c3ec69dd1 - std::backtrace_rs::backtrace::trace_unsynchronized::hacfb345a0c6d5bb1
at /home/ubuntu/rust2/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7f9c3ec69dd1 - std::sys_common::backtrace::_print_fmt::h18ea6016ac8030f3
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:65:5
3: 0x7f9c3ec69dd1 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he35dde201d0c2d09
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:44:22
4: 0x7f9c3ecee308 - core::fmt::write::h094ad263467a053c
at /home/ubuntu/rust2/library/core/src/fmt/mod.rs:1208:17
5: 0x7f9c3ec8aaf1 - std::io::Write::write_fmt::hd47b4e2324b4d9b7
at /home/ubuntu/rust2/library/std/src/io/mod.rs:1682:15
6: 0x7f9c3ec69bfa - std::sys_common::backtrace::_print::h43044162653a17fc
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:47:5
7: 0x7f9c3ec69bfa - std::sys_common::backtrace::print::hc8605da258fa5aeb
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:34:9
8: 0x7f9c3ec4db87 - std::panicking::default_hook::{{closure}}::h9e37f23f75122a15
9: 0x7f9c3ec4d97b - std::panicking::default_hook::h602873a063f84da2
at /home/ubuntu/rust2/library/std/src/panicking.rs:286:9
10: 0x7f9c3f6672b2 - <alloc[48d7b30605060536]::boxed::Box<dyn for<'a, 'b> core[672e3947e150d6c6]::ops::function::Fn<(&'a core[672e3947e150d6c6]::panic::panic_info::PanicInfo<'b>,), Output = ()> + core[672e3947e150d6c6]::marker::Send + core[672e3947e150d6c6]::marker::Sync> as core[672e3947e150d6c6]::ops::function::Fn<(&core[672e3947e150d6c6]::panic::panic_info::PanicInfo,)>>::call
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9
11: 0x7f9c3f6672b2 - rustc_driver[f5b6d32d8905ecdd]::DEFAULT_HOOK::{closure#0}::{closure#0}
at /home/ubuntu/rust2/compiler/rustc_driver/src/lib.rs:1204:17
12: 0x7f9c3ec4e0d3 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hfd13333ca953ae8e
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:2002:9
13: 0x7f9c3ec4e0d3 - std::panicking::rust_panic_with_hook::h45753e10264ebe7e
at /home/ubuntu/rust2/library/std/src/panicking.rs:692:13
14: 0x7f9c422a1aa3 - std[3330b4673efabfce]::panicking::begin_panic::<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>::{closure#0}
at /home/ubuntu/rust2/library/std/src/panicking.rs:608:9
15: 0x7f9c422a1a46 - std[3330b4673efabfce]::sys_common::backtrace::__rust_end_short_backtrace::<std[3330b4673efabfce]::panicking::begin_panic<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>::{closure#0}, !>
at /home/ubuntu/rust2/library/std/src/sys_common/backtrace.rs:137:18
16: 0x7f9c3f63a996 - std[3330b4673efabfce]::panicking::begin_panic::<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>
at /home/ubuntu/rust2/library/std/src/panicking.rs:607:12
17: 0x7f9c4227a496 - std[3330b4673efabfce]::panic::panic_any::<rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>
at /home/ubuntu/rust2/library/std/src/panic.rs:61:5
18: 0x7f9c4227cdf7 - <rustc_errors[1b15f4e7e49d1fd5]::HandlerInner>::flush_delayed::<alloc[48d7b30605060536]::vec::Vec<rustc_errors[1b15f4e7e49d1fd5]::diagnostic::Diagnostic>, &str, rustc_errors[1b15f4e7e49d1fd5]::ExplicitBug>
at /home/ubuntu/rust2/compiler/rustc_errors/src/lib.rs:1634:13
19: 0x7f9c422498cf - <rustc_errors[1b15f4e7e49d1fd5]::Handler>::flush_delayed
at /home/ubuntu/rust2/compiler/rustc_errors/src/lib.rs:1225:9
[ FRAMES INTENTIONALLY OMITTED ]
44: 0x7f9c3f6f3584 - <std[3330b4673efabfce]:🧵:Builder>::spawn_unchecked_::<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1}
at /home/ubuntu/rust2/library/std/src/thread/mod.rs:549:30
45: 0x7f9c3f6f3584 - <<std[3330b4673efabfce]:🧵:Builder>::spawn_unchecked_<rustc_interface[947706ead88047d0]::util::run_in_thread_pool_with_globals<rustc_interface[947706ead88047d0]::interface::run_compiler<core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>, rustc_driver[f5b6d32d8905ecdd]::run_compiler::{closure#1}>::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[672e3947e150d6c6]::result::Result<(), rustc_errors[1b15f4e7e49d1fd5]::ErrorGuaranteed>>::{closure#1} as core[672e3947e150d6c6]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
at /home/ubuntu/rust2/library/core/src/ops/function.rs:250:5
46: 0x7f9c3ec81968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::he8b26fc22c6f51ec
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9
47: 0x7f9c3ec81968 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h5cf9cbe75a8c3ddc
at /home/ubuntu/rust2/library/alloc/src/boxed.rs:1988:9
48: 0x7f9c3ec5f99c - std::sys::unix:🧵:Thread:🆕:thread_start::h2d6dd4455e97d031
at /home/ubuntu/rust2/library/std/src/sys/unix/thread.rs:108:17
49: 0x7f9c37c69609 - start_thread
50: 0x7f9c3ead0133 - clone
51: 0x0 - <unknown>
```
After, note `typeck_with_fallback` on the 5th frame, that's where we *actually* need to be pointed to:
```
error: internal compiler error: no errors encountered even though `delay_span_bug` issued
error: internal compiler error: test
--> /home/ubuntu/test.rs:1:1
|
1 | fn main() {}
| ^^^^^^^^^
|
= note: delayed at 0: <rustc_errors::HandlerInner>::emit_diagnostic
at ./compiler/rustc_errors/src/lib.rs:1279:29
1: <rustc_errors::HandlerInner>::delay_span_bug::<rustc_span::span_encoding::Span, &str>
at ./compiler/rustc_errors/src/lib.rs:1553:9
2: <rustc_errors::Handler>::delay_span_bug::<rustc_span::span_encoding::Span, &str>
at ./compiler/rustc_errors/src/lib.rs:995:9
3: <rustc_session::session::Session>::delay_span_bug::<rustc_span::span_encoding::Span, &str>
at ./compiler/rustc_session/src/session.rs:600:9
4: rustc_hir_typeck::typeck_with_fallback::<rustc_hir_typeck::typeck::{closure#0}>::{closure#0}
at ./compiler/rustc_hir_typeck/src/lib.rs:196:5
5: rustc_hir_typeck::typeck_with_fallback::<rustc_hir_typeck::typeck::{closure#0}>
at ./compiler/rustc_hir_typeck/src/lib.rs:185:36
6: rustc_hir_typeck::typeck
at ./compiler/rustc_hir_typeck/src/lib.rs:166:9
[ FRAMES INTENTIONALLY OMITTED ]
108: std::panicking::try::<core::result::Result<(), rustc_errors::ErrorGuaranteed>, core::panic::unwind_safe::AssertUnwindSafe<<std:🧵:Builder>::spawn_unchecked_<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#1}::{closure#0}>>
at ./library/std/src/panicking.rs:447:19
109: std::panic::catch_unwind::<core::panic::unwind_safe::AssertUnwindSafe<<std:🧵:Builder>::spawn_unchecked_<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#1}::{closure#0}>, core::result::Result<(), rustc_errors::ErrorGuaranteed>>
at ./library/std/src/panic.rs:140:14
110: <std:🧵:Builder>::spawn_unchecked_::<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#1}
at ./library/std/src/thread/mod.rs:549:30
111: <<std:🧵:Builder>::spawn_unchecked_<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#0}::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
at ./library/core/src/ops/function.rs:250:5
112: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at ./library/alloc/src/boxed.rs:1988:9
113: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
at ./library/alloc/src/boxed.rs:1988:9
114: std::sys::unix:🧵:Thread:🆕:thread_start
at ./library/std/src/sys/unix/thread.rs:108:17
115: start_thread
116: clone
```
Migrate `codegen_ssa` to diagnostics structs - [Part 3]
Completes migrating `codegen_ssa` module except 2 outstanding errors that depend on other crates:
1. [`rustc_middle::mir::interpret::InterpError`](b6097f2e1b/compiler/rustc_middle/src/mir/interpret/error.rs (L475)): I saw `rustc_middle` is unassigned, I am open to take this work.
2. `codegen_llvm`'s use of `fn span_invalid_monomorphization_error`, which I started to replace in the [last commit](9a31b3cdda) of this PR, but would like to know the team's preference on how we should keep replacing the other macros:
2.1. Update macros to expect a `Diagnostic`
2.2. Remove macros and expand the code on each use.
See [some examples of the different options in this experimental commit](64aee83e80)
_Part 2 - https://github.com/rust-lang/rust/pull/103792_
r? ``@davidtwco``
Cc ``@compiler-errors``
Encode spans relative to the enclosing item -- enable on nightly
Follow-up to #84373 with the flag `-Zincremental-relative-spans` set by default.
This PR seeks to remove one of the main shortcomings of incremental: the handling of spans.
Changing the contents of a function may require redoing part of the compilation process for another function in another file because of span information is changed.
Within one file: all the spans in HIR change, so typechecking had to be re-done.
Between files: spans of associated types/consts/functions change, so type-based resolution needs to be re-done (hygiene information is stored in the span).
The flag `-Zincremental-relative-spans` encodes local spans relative to the span of an item, stored inside the `source_span` query.
Trap: stashed diagnostics are referenced by the "raw" span, so stealing them requires to remove the span's parent.
In order to avoid too much traffic in the span interner, span encoding uses the `ctxt_or_tag` field to encode:
- the parent when the `SyntaxContext` is 0;
- the `SyntaxContext` when the parent is `None`.
Even with this, the PR creates a lot of traffic to the Span interner, when a Span has both a LocalDefId parent and a non-root SyntaxContext. They appear in lowering, when we add a parent to all spans, including those which come from macros, and during inlining when we mark inlined spans.
The last commit changes how queries of `LocalDefId` manage their cache. I can put this in a separate PR if required.
Possible future directions:
- validate that all spans are marked in HIR validation;
- mark macro-expanded spans relative to the def-site and not the use-site.
compiler: remove unnecessary imports and qualified paths
Some of these imports were necessary before Edition 2021, others were already in the prelude.
I hope it's fine that this PR is so spread-out across files :/
This migrates everything but the `mbe` and `proc_macro` modules. It also
contains a few cleanups and drive-by/accidental diagnostic improvements
which can be seen in the diff for the UI tests.
make `error_reported` check for delayed bugs
Fixes#104768
`error_reported()` was only checking if there were errors emitted, not for `delay_bug`s which can also be a source of `ErrorGuaranteed`. I assume the same is true of `lint_err_count` but i dont know
Use `as_deref` in compiler (but only where it makes sense)
This simplifies some code :3
(there are some changes that are not exacly `as_deref`, but more like "clever `Option`/`Result` method use")
Add a detailed note for missing comma typo w/ FRU syntax
Thanks to `@pierwill` for working on this with me!
Fixes#104373, perhaps `@alice-i-cecile` can comment on the new error for the example provided on that issue -- feedback is welcome.
```
error[E0063]: missing field `defaulted` in initializer of `Outer`
--> $DIR/multi-line-fru-suggestion.rs:14:5
|
LL | Outer {
| ^^^^^ missing `defaulted`
|
note: this expression may have been misinterpreted as a `..` range expression
--> $DIR/multi-line-fru-suggestion.rs:16:16
|
LL | inner: Inner {
| ________________^
LL | | a: 1,
LL | | b: 2,
LL | | }
| |_________^ this expression does not end in a comma...
LL | ..Default::default()
| ^^^^^^^^^^^^^^^^^^^^ ... so this is interpreted as a `..` range expression, instead of functional record update syntax
help: to set the remaining fields from `Default::default()`, separate the last named field with a comma
|
LL | },
| +
error: aborting due to previous error
For more information about this error, try `rustc --explain E0063`.
```
Use `IsTerminal` in place of `atty`
In any crate that can use nightly features, use `IsTerminal` rather than
`atty`:
- Use `IsTerminal` in `rustc_errors`
- Use `IsTerminal` in `rustc_driver`
- Use `IsTerminal` in `rustc_log`
- Use `IsTerminal` in `librustdoc`
Rollup of 8 pull requests
Successful merges:
- #102977 (remove HRTB from `[T]::is_sorted_by{,_key}`)
- #103378 (Fix mod_inv termination for the last iteration)
- #103456 (`unchecked_{shl|shr}` should use `u32` as the RHS)
- #103701 (Simplify some pointer method implementations)
- #104047 (Diagnostics `icu4x` based list formatting.)
- #104338 (Enforce that `dyn*` coercions are actually pointer-sized)
- #104498 (Edit docs for `rustc_errors::Handler::stash_diagnostic`)
- #104556 (rustdoc: use `code-header` class to format enum variants)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Edit docs for `rustc_errors::Handler::stash_diagnostic`
Clarify that the diagnostic can be retrieved with `steal_diagnostic`.
r? ```@compiler-errors```
Don't print full paths in overlap errors
We don't print the full path in other diagnostics -- I don't think it particularly helps with the error message. I also delayed the printing until actually needing to render the error message.
r? diagnostics
implement binding_shadows
migrate till self-in-generic-param-default
use braces in fluent message as suggested by @compiler-errors.
to fix lock file issue reported by CI
migrate 'unreachable label' error
run formatter
name the variables correctly in fluent file
SessionDiagnostic -> Diagnostic
test "pattern/pat-tuple-field-count-cross.rs" passed
test "resolve/bad-env-capture2.rs" passed
test "enum/enum-in-scope.rs" and other depended on "resolve_binding_shadows_something_unacceptable" should be passed now.
fix crash errors while running test-suite. there might be more.
then_some(..) suits better here.
all tests passed
convert TraitImpl and InvalidAsm. TraitImpl is buggy yet. will fix after receiving help from Zulip
migrate "Ralative-2018"
migrate "ancestor only"
migrate "expected found"
migrate "Indeterminate"
migrate "module only"
revert to the older implementation for now. since this is failing at the moment.
follow the convension for fluent variable
order the diag attribute as suggested in review comment
fix merge error. migrate trait-impl-duplicate
make the changes compatible with "Flatten diagnostic slug modules #103345"
fix merge
remove commented code
merge issues
fix review comments
fix tests
Display help message when fluent arg was referenced incorrectly
The fluent argument syntax is a little special and easy to get wrong, so we emit a small help message when someone gets it wrong.
Example:
```
parser_mismatched_closing_delimiter = mismatched closing delimiter: `${delimiter}`
```
panics with
```
thread 'rustc' panicked at 'Encountered errors while formatting message for `parser_mismatched_closing_delimiter`
help: Argument `delimiter` exists but was not referenced correctly. Try using `{$delimiter}` instead
attr: `None`
args: `FluentArgs([("delimiter", String("}"))])`
errors: `[ResolverError(Reference(Message { id: "delimiter", attribute: None }))]`', compiler/rustc_errors/src/translation.rs:123:21
```
fixes#103539
Some diagnostic-related nits
1. Use `&mut Diagnostic` instead of `&mut DiagnosticBuilder<'_, T>`
2. Make `diag.span_suggestions` take an `IntoIterator` instead of `Iterator`, just to remove some `.into_iter` calls on the caller.
idk if I should add a lint to make sure people use `&mut Diagnostic` instead of `&mut DiagnosticBuilder<'_, T>` in cases where we're just, e.g., adding subdiagnostics to the diagnostic... maybe a followup.
The fluent argument syntax is a little special and easy to get wrong, so
we emit a small help message when someone gets it wrong.
Example:
```
parser_mismatched_closing_delimiter = mismatched closing delimiter: `${delimiter}`
```
panics with
```
thread 'rustc' panicked at 'Encountered errors while formatting message for `parser_mismatched_closing_delimiter`
help: Argument `delimiter` exists but was not referenced correctly. Try using `{$delimiter}` instead
attr: `None`
args: `FluentArgs([("delimiter", String("}"))])`
errors: `[ResolverError(Reference(Message { id: "delimiter", attribute: None }))]`', compiler/rustc_errors/src/translation.rs:123:21
```
Port `dead_code` lints to be translatable.
This adds an additional comma to lists with three or more items, to be consistent with list formatters like `icu4x`.
r? `@davidtwco`
Track where diagnostics were created.
This implements the `-Ztrack-diagnostics` flag, which uses `#[track_caller]` to track where diagnostics are created. It is meant as a debugging tool much like `-Ztreat-err-as-bug`.
For example, the following code...
```rust
struct A;
struct B;
fn main(){
let _: A = B;
}
```
...now emits the following error message:
```
error[E0308]: mismatched types
--> src\main.rs:5:16
|
5 | let _: A = B;
| - ^ expected struct `A`, found struct `B`
| |
| expected due to this
-Ztrack-diagnostics: created at compiler\rustc_infer\src\infer\error_reporting\mod.rs:2275:31
```
This allows porting uses of span_suggestions() to diagnostic structs.
Doesn't work for multipart_suggestions() because the rank would be
reversed - the struct would specify multiple spans, each of which has
multiple possible replacements, while multipart_suggestions() creates
multiple possible replacements, each with multiple spans.
Rollup of 6 pull requests
Successful merges:
- #101293 (Recover when unclosed char literal is parsed as a lifetime in some positions)
- #101908 (Suggest let for assignment, and some code refactor)
- #103192 (rustdoc: Eliminate uses of `EarlyDocLinkResolver::all_traits`)
- #103226 (Check `needs_infer` before `needs_drop` during HIR generator analysis)
- #103249 (resolve: Revert "Set effective visibilities for imports more precisely")
- #103305 (Move some tests to more reasonable places)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
translation: doc comments with derives, subdiagnostic-less enum variants, more derive use
- Adds support for `doc` attributes in the diagnostic derives so that documentation comments don't result in the derive failing.
- Adds support for enum variants in the subdiagnostic derive to not actually correspond to an addition to a diagnostic.
- Made use of the derive in more places in the `rustc_ast_lowering`, `rustc_ast_passes`, `rustc_lint`, `rustc_session`, `rustc_infer` - taking advantage of recent additions like eager subdiagnostics, multispan suggestions, etc.
cc #100717
translation: eager translation
Part of #100717. See [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/.23100717.20lists!/near/295010720) for additional context.
- **Store diagnostic arguments in a `HashMap`**: Eager translation will enable subdiagnostics to be translated multiple times with different arguments - this requires the ability to replace the value of one argument with a new value, which is better suited to a `HashMap` than the previous storage, a `Vec`.
- **Add `AddToDiagnostic::add_to_diagnostic_with`**: `AddToDiagnostic::add_to_diagnostic_with` is similar to the previous `AddToDiagnostic::add_to_diagnostic` but takes a function that can be used by the caller to modify diagnostic messages originating from the subdiagnostic (such as performing translation eagerly). `add_to_diagnostic` now just calls `add_to_diagnostic_with` with an empty closure.
- **Add `DiagnosticMessage::Eager`**: Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the emitter during emission). Also adds `eager_subdiagnostic` function which is intended to be invoked by the diagnostic derive for subdiagnostic fields which are marked as needing eager translation.
- **Support `#[subdiagnostic(eager)]`**: Add support for `eager` argument to the `subdiagnostic` attribute which generates a call to `eager_subdiagnostic`.
- **Finish migrating `rustc_query_system`**: Using eager translation, migrate the remaining repeated cycle stack diagnostic.
- **Split formatting initialization and use in diagnostic derives**: Diagnostic derives have previously had to take special care when ordering the generated code so that fields were not used after a move.
This is unlikely for most fields because a field is either annotated with a subdiagnostic attribute and is thus likely a `Span` and copiable, or is a argument, in which case it is only used once by `set_arg`
anyway.
However, format strings for code in suggestions can result in fields being used after being moved if not ordered carefully. As a result, the derive currently puts `set_arg` calls last (just before emission), such as:
let diag = { /* create diagnostic */ };
diag.span_suggestion_with_style(
span,
fluent::crate::slug,
format!("{}", __binding_0),
Applicability::Unknown,
SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */
diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */
diag.emit();
For eager translation, this doesn't work, as the message being translated eagerly can assume that all arguments are available - so arguments _must_ be set first.
Format strings for suggestion code are now separated into two parts - an initialization line that performs the formatting into a variable, and a usage in the subdiagnostic addition.
By separating these parts, the initialization can happen before arguments are set, preserving the desired order so that code compiles, while still enabling arguments to be set before subdiagnostics are added.
let diag = { /* create diagnostic */ };
let __code_0 = format!("{}", __binding_0);
/* + other formatting */
diag.set_arg("foo", __binding_0);
/* + other `set_arg` calls */
diag.span_suggestion_with_style(
span,
fluent::crate::slug,
__code_0,
Applicability::Unknown,
SuggestionStyle::ShowAlways
);
/* + other subdiagnostic additions */
diag.emit();
- **Remove field ordering logic in diagnostic derive:** Following the approach taken in earlier commits to separate formatting initialization from use in the subdiagnostic derive, simplify the diagnostic derive by removing the field-ordering logic that previously solved this problem.
r? ```@compiler-errors```
Migrate rustc_passes diagnostics
Picks up abandoned work from https://github.com/rust-lang/rust/pull/100870
I would like to do this collaboratively, as there is a lot of work! Here's the process:
- Comment below that you are willing to help and I will add you as a collaborator to my `rust` fork (that gives you write access)
- Indicate which file/task you would like to work on (so we don't duplicate work) from the list below
- Do the work, push up a commit, comment that you're done with that file/task
- Repeat until done 😄
### Files to Migrate (in `compiler/rustc_passes/src/`)
- [x] check_attr.rs ``@CleanCut``
- [x] check_const.rs ``@CleanCut``
- [x] dead.rs ``@CleanCut``
- [x] debugger_visualizer.rs ``@CleanCut``
- [x] diagnostic_items.rs ``@CleanCut``
- [x] entry.rs ``@CleanCut``
- [x] lang_items.rs ``@CleanCut``
- [x] layout_test.rs ``@CleanCut``
- [x] lib_features.rs ``@CleanCut``
- [x] ~liveness.rs~ ``@CleanCut`` Nothing to do
- [x] loops.rs ``@CleanCut``
- [x] naked_functions.rs ``@CleanCut``
- [x] stability.rs ``@CleanCut``
- [x] weak_lang_items.rs ``@CleanCut``
### Tasks
- [x] Rebase on current `master` ``@CleanCut``
- [x] Review work from [the earlier PR](https://github.com/rust-lang/rust/pull/100870) and make sure it all looks good
- [x] compiler/rustc_error_messages/locales/en-US/passes.ftl ``@CleanCut``
- [x] compiler/rustc_passes/src/check_attr.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/errors.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/lang_items.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/lib.rs ``@CleanCut``
- [x] compiler/rustc_passes/src/weak_lang_items.rs ``@CleanCut``
Add variant of `DiagnosticMessage` for eagerly translated messages
(messages in the target language which don't need translated by the
emitter during emission). Also adds `eager_subdiagnostic` function which
is intended to be invoked by the diagnostic derive for subdiagnostic
fields which are marked as needing eager translation.
Signed-off-by: David Wood <david.wood@huawei.com>
`AddToDiagnostic::add_to_diagnostic_with` is similar to the previous
`AddToDiagnostic::add_to_diagnostic` but takes a function that can be
used by the caller to modify diagnostic messages originating from the
subdiagnostic (such as performing translation eagerly).
`add_to_diagnostic` now just calls `add_to_diagnostic_with` with an
empty closure.
Signed-off-by: David Wood <david.wood@huawei.com>
Eager translation will enable subdiagnostics to be translated multiple
times with different arguments - this requires the ability to replace
the value of one argument with a new value, which is better suited to a
`HashMap` than the previous storage, a `Vec`.
Signed-off-by: David Wood <david.wood@huawei.com>
Add `Noted` marker struct that implements `EmissionGuarantee` so that
`emit_note` and `create_note` can be implemented for struct diagnostics.
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 5 pull requests
Successful merges:
- #102672 (rustdoc: remove unused CSS class `in-band`)
- #102693 (Revert "Use getentropy when possible on all Apple platforms")
- #102694 (Suggest calling method if fn does not exist)
- #102708 (Suggest `==` to wrong assign expr)
- #102710 (Add test for issue 82633)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Move lint level source explanation to the bottom
So, uhhhhh
r? `@estebank`
## User-facing change
"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
- = note: `#[warn(unsupported_calling_conventions)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+ = note: `#[warn(unsupported_calling_conventions)]` on by default
```
Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.
## Developer-facing change
`struct_span_lint` and similar methods have a different signature.
Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)`
After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>`
The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.
Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.
## Subtle problem
By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...
I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.
## P.S.
I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
Group together more size assertions.
Also add a few more assertions for some relevant token-related types.
And fix an erroneous comment in `rustc_errors`.
r? `@lqd`
Flush delayed bugs before codegen
Sometimes it can happen that invalid code like a TyKind::Error makes its way through the compiler without triggering any errors (this is always a bug in rustc but bugs do happen sometimes :)). These ICEs will manifest in the backend like as cg_llvm not being able to get the layout of `[type error]`, which makes it hard to debug. By flushing before codegen, we display all the delayed bugs, making it easier to trace it to the root of the problem.
I tried this on #102366 and it showed tons of of delayed bugs and no error in cg_llvm, so it seems to be working.
Migrate rustc_codegen_gcc to SessionDiagnostics
As part of #100717 this pr migrates diagnostics to `SessionDiagnostics` for the `rustc_codegen_gcc` crate.
``@rustbot`` label +A-translation
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
Sometimes it can happen that invalid code like a TyKind::Error makes
its way through the compiler without triggering any errors (this is
always a bug in rustc but bugs do happen sometimes :)). These ICEs
will manifest in the backend like as cg_llvm not being able to get
the layout of `[type error]`, which makes it hard to debug. By flushing
before codegen, we display all the delayed bugs, making it easier to
trace it to the root of the problem.
`parse_token_tree` is basically a match with four arms: `Eof`,
`OpenDelim`, `CloseDelim`, and "other". It has two call sites, and at
each call site one of the arms is unreachable. It's also not inlined.
This commit removes `parse_token_tree` by splitting it into four
functions and inlining them. This avoids some repeated conditional
tests and also some non-inlined function calls on the hot path.
FIX - ambiguous Diagnostic link in docs
UPDATE - rename diagnostic_items to IntoDiagnostic and AddToDiagnostic
[Gardening] FIX - formatting via `x fmt`
FIX - rebase conflicts. NOTE: Confirm wheather or not we want to handle TargetDataLayoutErrorsWrapper this way
DELETE - unneeded allow attributes in Handler method
FIX - broken test
FIX - Rebase conflict
UPDATE - rename residual _SessionDiagnostic and fix LintDiag link
On later stages, the feature is already stable.
Result of running:
rg -l "feature.let_else" compiler/ src/librustdoc/ library/ | xargs sed -s -i "s#\\[feature.let_else#\\[cfg_attr\\(bootstrap, feature\\(let_else\\)#"
- ... when creating diagnostics in rustc_metadata
- use the error_code! macro
- pass macro output to diag.code()
- use fluent from within manual implementation of SessionDiagnostic
- emit the untested errors in case they occur in the wild
- stop panicking in the probably-not-dead code, add fixme to write test
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.
Allow deriving multipart suggestions
This turned into a bit more of a rewrite than I was initially hoping for... Still, I think the `SessionSubdiagnostic` derive is a little cleaner overall now, and closer to the `SessionDiagnostic` derive to make future code sharing easier.
r? ``@davidtwco``
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)
never consider unsafe blocks unused if they would be required with deny(unsafe_op_in_unsafe_fn)
Judging from https://github.com/rust-lang/rust/issues/71668#issuecomment-1200317370 the consensus nowadays seems to be that we should never consider an unsafe block unused if it was required with `deny(unsafe_op_in_unsafe_fn)`, no matter whether that lint is actually enabled or not. So let's adjust rustc accordingly.
The first commit does the change, the 2nd does some cleanup.
Migrations for rustc_expand transcribe.rs
This PR includes some migrations to the new diagnostics API for the `rustc_expand` module.
r? ```@davidtwco```
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`
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>
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>
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`
Remove the unused StableSet and StableMap types from rustc_data_structures.
The current implementation is not "stable" in the same sense that `HashStable` and `StableHasher` are stable, i.e. across compilation sessions. So, in my opinion, it's better to remove those types (which are basically unused anyway) than to give the wrong impression that these are safe for incr. comp.
I plan to provide new "stable" collection types soon that can be used to replace `FxHashMap` and `FxHashSet` in query results (see [draft](69d03ac7a7)). It's unsound that `HashMap` and `HashSet` implement `HashStable` (see https://github.com/rust-lang/rust/issues/98890 for a recent P-critical bug caused by this) -- so we should make some progress there.
Apply the `#[rustc_lint_diagnostics]` attribute to
`LintDiagnosticBuilder::build` so that diagnostic migration lints will
trigger for it.
Signed-off-by: David Wood <david.wood@huawei.com>
Implements `IntoDiagnosticArg` for `char` using its `Debug`
implementation and introduces a macro for those types which just
delegate the implementation to `ToString`.
Signed-off-by: David Wood <david.wood@huawei.com>
Fix duplicated type annotation suggestion
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes#93506 .
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
This fixes#93506 .
Migrate some diagnostics from `rustc_const_eval` to `SessionDiagnostic`
I'm still trying to get the hang of this, so it doesn't migrate _all_ of `rustc_const_eval`. Working on that later.
r? `@davidtwco`
sess: stabilize `--terminal-width` as `--diagnostic-width`
Formerly `-Zterminal-width`, `--terminal-width` allows the user or build
tool to inform rustc of the width of the terminal so that diagnostics
can be truncated.
Pending agreement to stabilize, see tracking issue at #84673.
r? ```@oli-obk```
Rename the `--output-width` flag to `--diagnostic-width` as this appears
to be the preferred name within the compiler team.
Signed-off-by: David Wood <david.wood@huawei.com>
Rename the `--terminal-width` flag to `--output-width` as the behaviour
doesn't just apply to terminals (and so is slightly less accurate).
Signed-off-by: David Wood <david.wood@huawei.com>
lints: mostly translatable diagnostics
As lints are created slightly differently than other diagnostics, intended to try make them translatable first and then look into the applicability of diagnostic structs but ended up just making most of the diagnostics in the crate translatable (which will still be useful if I do make a lot of them structs later anyway).
r? ``@compiler-errors``
Accept `DiagnosticMessage` in `LintDiagnosticBuilder::build` so that
lints can be built with translatable diagnostic messages.
Signed-off-by: David Wood <david.wood@huawei.com>
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
Previously we only show at most 6 lines of suggestions and, if the
suggestions are more than 6 lines apart, we've just showed ... at the
end. This is probably fine, but quite confusing in my opinion.
This commit is an attempt to show ... in places where there is nothing
to suggest instead, for example:
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~ } };
|
```
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. 🙃
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.
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`````
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>
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
Remove migrate borrowck mode
Closes#58781Closes#43234
# Stabilization proposal
This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors, then MIR borrowck (NLL) never occurs. If there *aren't* any errors, then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program, this should not break any programs. It does, however, change diagnostics significantly and allows a slightly larger set of programs to compile.
Tracking issue: #43234
RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md
Version: 1.63 (2022-06-30 => beta, 2022-08-11 => stable).
## Motivation
Over time, the Rust borrow checker has become "smarter" and thus allowed more programs to compile. There have been three different implementations: AST borrowck, MIR borrowck, and polonius (well, in progress). Additionally, there is the "lexical region resolver", which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker, but does emit some errors.
The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017, work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017, for the most part. During 2018, efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into "migrate" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition.
In early 2019, migrate mode was turned on by default in the 2015 edition as well, but with MIR borrowck errors emitted as warnings. By late 2019, these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker.
In the period since, various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver.
While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics), those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff.
## What is stabilized
As said previously, this does not fundamentally change the landscape of accepted programs. However, there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)`, but not otherwise.
There are two notable patterns that are "fixed" by this stabilization. First, the `scoped_threads` feature, which is a continutation of a pre-1.0 API, can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second, actually seen in the standard library. In the `Extend` impl for `HashMap`, there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl.
As mentioned before, there are a large number of diagnostic differences. Most of them are better, but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general "lifetime may not live long enough" error. While this may *seem* bad, the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however, on paper, they end up being roughly the same with roughly the same kinds of solutions.
## What isn't stabilized
This PR does not completely remove the lexical region resolver. In the future, it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck.
## Tests
Many test outputs get updated by this PR. However, there are number of tests specifically geared towards NLL under `src/test/ui/nll`
## History
* On 2017-07-14, [tracking issue opened](https://github.com/rust-lang/rust/issues/43234)
* On 2017-07-20, [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271)
* On 2017-08-29, [RFC opened](https://github.com/rust-lang/rfcs/pull/2094)
* On 2017-11-16, [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825)
* On 2017-12-20, [NLL feature complete](https://github.com/rust-lang/rust/pull/46862)
* On 2018-07-07, [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083)
* On 2018-07-27, [Add migrate mode](https://github.com/rust-lang/rust/pull/52681)
* On 2019-04-22, [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114)
* On 2019-08-26, [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221)
* On 2019-08-27, [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)
Replace `&Vec<_>`s with `&[_]`s
It's generally preferable to use `&[_]` since it's one less indirection and it can be created from types other that `Vec`.
I've left `&Vec` in some locals where it doesn't really matter, in cases where `TypeFoldable` is expected (`TypeFoldable: Clone` so slice can't implement it) and in cases where it's `&TypeAliasThatIsActiallyVec`. Nothing important, really, I was just a little annoyed by `visit_generic_param_vec` :D
r? `@compiler-errors`
errors: simplify referring to fluent attributes
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.
r? `@oli-obk`
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>
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>
Manual implementors of translatable diagnostics will need to call
`set_arg`, not just the derive, so make this function a bit more
ergonomic by taking `IntoDiagnosticArg` rather than
`DiagnosticArgValue`.
Signed-off-by: David Wood <david.wood@huawei.com>
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>
Change `span_suggestion` (and variants) to take `impl ToString` rather
than `String` for the suggested code, as this simplifies the
requirements on the diagnostic derive.
Signed-off-by: David Wood <david.wood@huawei.com>
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.
