ICE: Span must not be empty and have no suggestion (E0308) #114255
Comments
Noratrieb
added
I-ICE
rustbot
added
the
needs-triage
Noratrieb
added
requires-debug-assertions
|
Hello @Nilstrieb |
|
The issue here is that the compiler wants to emit a suggestion in the error message, but the span (location) of the suggestion is empty/wrong. By looking at the backtrace, you can figure out where the error is emitted. Then you can look there to see why the span would be wrong. |
|
@rustbot claim |
|
This is actually (partially) fixed by #112500. (Someone review that please?) But even though that PR makes the span no longer empty and technically correct, it could still use some improvements: In particular, the "remove the extra argument" span should probably not include the previous @meysam81 if you still want to work on this, the relevant code is here: rust/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs Lines 937 to 938 in 89acdae The |
Fix argument removal suggestion around macros Fixes rust-lang#112437. Fixes rust-lang#113866. Helps with rust-lang#114255. The issue was that `span.find_ancestor_inside(outer)` could previously return a span with a different expansion context from `outer`. This happens for example for the built-in macro `panic!`, which expands to another macro call of `panic_2021!` or `panic_2015!`. Because the call site of `panic_20xx!` has not associated source code, its span currently points to the call site of `panic!` instead. Something similar also happens items that get desugared in AST->HIR lowering. For example, `for` loops get two spans: One "inner" span that has the `.desugaring_kind()` kind set to `DesugaringKind::ForLoop` and one "outer" span that does not. Similar to the macro situation, both of these spans point to the same source code, but have different expansion contexts. This causes problems, because joining two spans with different expansion contexts will usually[^1] not actually join them together to avoid creating "spaghetti" spans that go from the macro definition to the macro call. For example, in the following snippet `full_span` might not actually contain the `adjusted_start` and `adjusted_end`. This caused the broken suggestion / debug ICE in the linked issues. ```rust let adjusted_start = start.find_ancestor_inside(shared_ancestor); let adjusted_end = end.find_ancestor_inside(shared_ancestor); let full_span = adjusted_start.to(adjusted_end) ``` To fix the issue, this PR introduces a new method, `find_ancestor_inside_same_ctxt`, which combines the functionality of `find_ancestor_inside` and `find_ancestor_in_same_ctxt`: It finds an ancestor span that is contained within the parent *and* has the same syntax context, and is therefore safe to extend. This new method should probably be used everywhere, where the returned span is extended, but for now it is just used for the argument removal suggestion. Additionally, this PR fixes a second issue where the function call itself is inside a macro but the arguments come from outside the macro. The test is added in the first commit to include stderr diff, so this is best reviewed commit by commit. [^1]: If one expansion context is the root context and the other is not.
Found with tree-crasher.
looks like a different root cause than #114251, but if you fix this also test that to be sure.
Code
Meta
rustc --version --verbose:Error output
without debug assertions:
Backtrace
There's more output about "no errors encountered even though
delay_span_bugissued which doesn't really make sense as there were errors emitted, it just didn't fully complete emission.The text was updated successfully, but these errors were encountered: