Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the "monomorphization backtrace" for const-eval errors #122486

Open
RalfJung opened this issue Mar 14, 2024 · 0 comments
Open

Improve the "monomorphization backtrace" for const-eval errors #122486

RalfJung opened this issue Mar 14, 2024 · 0 comments
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@RalfJung
Copy link
Member

When a const fails to evaluate, if there are generics involved it can be crucial to know where and how the const got instantiated to understand the error. For this purpose interpret::ErrorHandled has the emit_note function that marks the point in the code where an erroneous constant is encountered.

However, this could be done better:

  • For promoteds and inline consts, the const is defined right where it is used, so the extra note makes little sense and should probably be suppressed.
  • The monomorphization collector prints similar errors related to instantiation of generic functions as "the above error was encountered while instantiating this function". It plays some tricks with the error count to ensure this is only emitted right after an actual error. We could do something similar. That would lead to less duplication of "erroneous constant used here" messages, but it means if the first evaluation of a constant is without a decent span, we'll never get the note. That may be an okay trade-off? Currently GVN evaluates constants without a decent span, but maybe that should just be fixed. (It's not trivial since GVN has its own representation for consts that doesn't hold the span -- and probably it shouldn't hold a span, probably the error should be emitted before turning a const operand into that representation.)

Fixing this will require refactoring a bit how this note is emitted; currently emit_note has no idea which constant it is that failed and it can't compare old and new error counts to determine if the error would be right "above".

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Mar 14, 2024
@jieyouxu jieyouxu added A-diagnostics Area: Messages for errors, warnings, and lints A-const-eval Area: Constant evaluation (MIR interpretation) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants