This makes it easier to open the messages file while developing on features.
The commit was the result of automatted changes:
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
statically guarantee that current error codes are documented
Closes#61137 (that's right!)
Pretty simple refactor (often just a change from `Result<Option<&str>>` to `Result<&str>`)
r? `@GuillaumeGomez` (could you specially look at 53044158ef? I believe you wrote that in the first place, just want to make sure you're happy with the change)
Add `ErrorGuaranteed` to `hir::{Expr,Ty}Kind::Err` variants
First step in making the `Err` variants of `ExprKind` and `TyKind` require an `ErrorGuaranteed` during parsing. Making the corresponding AST versions require `ErrorGuaranteed` is a bit harder, whereas it was pretty easy to do this for HIR, so let's do that first.
The only weird thing about this PR is that `ErrorGuaranteed` is moved to `rustc_span`. This is *certainly* not the right place to put it, but `rustc_hir` cannot depend on `rustc_error` because the latter already depends on the former. Should I just pull out some of the error machinery from `rustc_error` into an even more minimal crate that `rustc_hir` can depend on? Advice would be appreciated.
Extend `CodegenBackend` trait with a function returning the translation
resources from the codegen backend, which can be added to the complete
list of resources provided to the emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
`run-make/translation` had some targets that weren't listed in `all` and
thus weren't being tested - the behaviour that should have been being
tested was basically correct fortunately.
Signed-off-by: David Wood <david.wood@huawei.com>
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
Don't recover lifetimes/labels containing emojis as character literals
Fixes#108019.
Note that at the time of this commit, `unic-emoji-char` seems to have data tables only up to Unicode 5.0, but Unicode is already newer than this.
A newer emoji such as `🥺` will not be recognized as an emoji but older emojis such as `🐱` will.
This PR leaves a couple of FIXMEs where `unic_emoji_char::is_emoji` is used.
Note that at the time of this commit, `unic-emoji-char` seems to have
data tables only up to Unicode 5.0, but Unicode is already newer than
this.
A newer emoji such as `🥺` will not be recognized as an emoji
but older emojis such as `🐱` will.
Introduce `-Zterminal-urls` to use OSC8 for error codes
Terminals supporting the OSC8 Hyperlink Extension can support inline anchors where the text is user defineable but clicking on it opens a browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Terminals supporting the OSC8 Hyperlink Extension can support inline
anchors where the text is user defineable but clicking on it opens a
browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Implement `IntoDiagnosticArg` for `&'a T` when `T` implements
`IntoDiagnosticArg` and `Clone`. Makes it easier to write diagnostic
structs that borrow something which implements `IntoDiagnosticArg`.
Signed-off-by: David Wood <david.wood@huawei.com>
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``