about summary refs log tree commit diff
path: root/compiler/rustc_errors
AgeCommit message (Collapse)AuthorLines
2023-04-01a couple clippy::complexity fixesMatthias Krüger-1/+1
map_identity filter_next option_as_ref_deref unnecessary_find_map redundant_slicing unnecessary_unwrap bool_comparison derivable_impls manual_flatten needless_borrowed_reference
2023-03-28Create AnnotationColumn struct to fix hard tab column numbers in errorspommicket-36/+85
2023-03-21Rollup merge of #109403 - chenyukang:yukang/fix-109396, r=estebankMatthias Krüger-1/+1
Avoid ICE of attempt to add with overflow in emitter Fixes #109396 r? ```@estebank```
2023-03-21Avoid ICE of attempt to add with overflow in emitteryukang-1/+1
2023-03-20migrate compiler, bootstrap, and compiletest to windows-rsAndy Russell-47/+44
2023-03-11Simplify message pathsest31-1/+1
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
2023-03-04Properly colorize multi-part suggestions in the same lineEsteban Küber-6/+6
Fix #108547.
2023-02-26Rollup merge of #108482 - Ezrashaw:force-error-docs, r=GuillaumeGomezMatthias Krüger-12/+6
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 53044158eff0d64673a6100f701c57b484232aca? I believe you wrote that in the first place, just want to make sure you're happy with the change)
2023-02-26Rollup merge of #108379 - compiler-errors:hir-error-guaranteed, r=cjgillotMatthias Krüger-15/+1
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.
2023-02-26refactor: statically guarantee that current error codes are documentedEzra Shaw-12/+6
2023-02-26Rollup merge of #108456 - clubby789:ast-passes-diag-migrate, r=compiler-errorsMatthias Krüger-0/+1
Complete migrating `ast_passes` to derive diagnostics cc #100717 ```@rustbot``` label +A-translation
2023-02-25Add ErrorGuaranteed to HIR TyKind::ErrMichael Goulet-15/+1
2023-02-25Complete migrating `ast_passes` to derive diagnosticsclubby789-0/+1
2023-02-23Restore behavior when primary bundle is missingmejrs-4/+13
2023-02-22various: translation resources from cg backendDavid Wood-2/+2
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>
2023-02-22errors: fix translation's run-make testDavid Wood-2/+11
`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>
2023-02-22errors: generate typed identifiers in each crateDavid Wood-7/+27
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>
2023-02-18Rollup merge of #108031 - jieyouxu:issue-108019, r=estebankMatthias Krüger-0/+2
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.
2023-02-16Rollup merge of #108090 - WaffleLapkin:if_not_now_then_when…, r=oli-obkMatthias Krüger-16/+13
`if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)` Resurrection of #108079
2023-02-16`if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)`Maybe Waffle-16/+13
2023-02-14rebase and review commentsEsteban Küber-2/+1
2023-02-14More accurate spans for arg removal suggestionEsteban Küber-2/+4
2023-02-14Don't recover lifetimes/labels containing emojis as character literals许杰友 Jieyou Xu (Joe)-0/+2
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.
2023-02-13Rollup merge of #107838 - estebank:terminal_hyperlinks, r=nagisaMatthias Krüger-3/+34
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
2023-02-09Introduce `-Zterminal-urls` to use OSC8 for error codesEsteban Küber-3/+34
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
2023-02-09test: snapshot for derive suggestion in diff filesbohan-11/+11
2023-02-05Clean up and comment EmitterWriter.draw_code_lineCastilloDel-59/+32
2023-02-04Fix suggestions rendering when the span is multilineCastilloDel-17/+63
2023-02-01Make "use latest edition" subdiagnostic translatableXiretza-38/+1
2023-02-01Implement IntoDiagnosticArg for ast::VisibilityXiretza-0/+8
2023-02-01Use AddToDiagnostic for "use latest edition" helpXiretza-14/+37
2023-01-31Rollup merge of #107467 - WaffleLapkin:uneq, r=oli-obkGuillaume Gomez-24/+32
Improve enum checks Some light refactoring.
2023-01-30session: diagnostic migration lint on more fnsDavid Wood-15/+99
Apply the diagnostic migration lint to more functions on `Session`. Signed-off-by: David Wood <david.wood@huawei.com>
2023-01-30errors: implement `IntoDiagnosticArg` for `&T`David Wood-0/+6
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>
2023-01-30errors: add `emit_note`/`create_note` on `Handler`David Wood-0/+11
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>
2023-01-30Replace some `_ == _ || _ == _`s with `matches!(_, _ | _)`sMaybe Waffle-1/+1
2023-01-30Replace enum `==`s with `match`es where it makes senseMaybe Waffle-23/+31
2023-01-20add debug assertion for suggestions with overlapping partsLukas Markeffsky-27/+45
2023-01-17Remove double spaces after dots in commentsMaybe Waffle-6/+6
2023-01-11Rollup merge of #106427 - mejrs:translation_errors, r=davidtwconils-78/+401
Improve fluent error messages These have been really frustrating me while migrating diagnostics.
2023-01-11Rollup merge of #106321 - compiler-errors:delayed-bug-backtrace, r=Nilstriebnils-23/+15
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]::thread::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]::thread::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::new::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::thread::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::thread::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::thread::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::thread::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::new::thread_start at ./library/std/src/sys/unix/thread.rs:108:17 115: start_thread 116: clone ```
2023-01-10create helper function for `rustc_lint_defs::Level` and remove it's ↵ozkanonur-10/+1
duplicated code r=ozkanonur Signed-off-by: ozkanonur <work@onurozkan.dev>
2023-01-09Collect backtraces for delayed span-bugs tooMichael Goulet-23/+15
2023-01-09Fix testsmejrs-0/+5
2023-01-08Make translate_message return result and add testsmejrs-16/+221
2023-01-07Rollup merge of #104543 - ↵Matthias Krüger-1/+76
JhonnyBillM:migrate-codegen-ssa-to-diagnostics-structs-pt3, r=davidtwco 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`](https://github.com/rust-lang/rust/blob/b6097f2e1b2ca62e188ba53cf43bd66b06b36915/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](https://github.com/rust-lang/rust/commit/9a31b3cdda78a2c0891828254fe9886e0a1cfd16) 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](https://github.com/JhonnyBillM/rust/commit/64aee83e80857dcfa450f0c6e31d5f29c6d577e6) _Part 2 - https://github.com/rust-lang/rust/pull/103792_ r? ``@davidtwco`` Cc ``@compiler-errors``
2023-01-06Rollup merge of #106287 - Nilstrieb:its-bugging-me-how-we-dont-have-docs, ↵Matthias Krüger-0/+2
r=jyn514 Add some docs to `bug`, `span_bug` and `delay_span_bug` cc `@mejrs` as you wanted me to do this, does this look good and understandable?
2023-01-05Improve fluent error messagesmejrs-67/+180
2023-01-02Auto merge of #84762 - cjgillot:resolve-span-opt, r=petrochenkovbors-50/+56
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.
2023-01-01Merge multiple mutable borrows of immutable binding errorsEsteban Küber-2/+2
Fix #53466.