-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE due to #[track_caller]
shim with -Z unleash-the-miri-inside-of-you
#68789
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
Comments
It shouldn't, reification results in a shim which should cause miri to stop walking up the stack, as it looks like a non- A real backtrace is needed (we should really try to get nightly to be built with |
Is this reproducible in Miri? I added some tests there for |
My first guess here would be that const-prop went wrong, Cc @wesleywiser |
@Centril Do I need to pass any flags other than attempt to repro
|
@wesleywiser No, just using that flag (on latest master, freshly rebased):
|
@Centril would you happen to have LLVM assertions enabled, which @wesleywiser might not? |
The following is the only modifications made to # Whether or not debug assertions are enabled for the compiler and standard
# library.
debug-assertions = true
# Debuginfo level for most of Rust code, corresponds to the `-C debuginfo=N` option of `rustc`.
# `0` - no debug info
# `1` - line tables only
# `2` - full debug info with variable and type information
# Can be overriden for specific subsets of Rust code (rustc, std or tools).
# Debuginfo for tests run with compiletest is not controlled by this option
# and needs to be enabled separately with `debuginfo-level-tests`.
#debuginfo-level = if debug { 2 } else { 0 }
debuginfo-level = 2 where Per @eddyb's advice, I'll try to nuke |
The ICE message betrays the old nightly you're still using, heh. |
Yeah oops; I was forgetting to add |
I won't tell anyone about your secret if you also let me use that time machine. :D |
Reproducer:
reduced:
with backtrace:
cc @anp @RalfJung @oli-obk
Also, from the provided description in the reference PR:
...it sounds like this is violating the runtime-compiletime-same-behavior rule. In particular, it sounds like
dbg!(bar());
anddbg!(CTFE);
would print out different things. We would get that on stable if we allowedconst fn()
pointers.Relatedly, the following:
...results in:
The text was updated successfully, but these errors were encountered: