miri no longer builds after rust-lang/rust#75048 #75274

Activity

1. rust-highfive

   added

   A-miriArea: The miri toolArea: The miri tool

   C-bugCategory: This is a bug.Category: This is a bug.

   on Aug 8, 2020
2. rust-highfive

   assigned

   oli-obk

   ,

   eddyb

   and

   RalfJung

   on Aug 8, 2020
3. eggyal commented on Aug 8, 2020

   

   eggyal

   on Aug 8, 2020

   Contributor

   More actions

   Is https://github.com/rust-lang-ci/rust/runs/960369368#step:23:34066 the failure at issue?
4. Mark-Simulacrum commented on Aug 8, 2020

   

   Mark-Simulacrum

   on Aug 8, 2020

   Member

   More actions

   No, that builder is in the auto-fallible section. The problem is here:

   020-08-08T00:40:34.2071170Z ## Running run-pass tests in tests/run-pass against miri for target x86_64-unknown-linux-gnu
   2020-08-08T00:40:34.2072957Z    Compiler flags: --edition 2018 -Astable-features --sysroot /home/user/.cache/miri/HOST
   2020-08-08T00:40:34.2254641Z 
   2020-08-08T00:40:34.2255563Z running 194 tests
   2020-08-08T00:40:34.3864259Z normalized stderr:
   2020-08-08T00:40:34.3864893Z error: unsupported operation: inline assembly is not supported
   2020-08-08T00:40:34.3866373Z    --> /checkout/library/core/src/hint.rs:124:9
   2020-08-08T00:40:34.3866623Z     |
   2020-08-08T00:40:34.3866801Z 124 |         llvm_asm!("" : : "r"(&dummy));
   2020-08-08T00:40:34.3866987Z     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ inline assembly is not supported
   2020-08-08T00:40:34.3867160Z     |
   2020-08-08T00:40:34.3867358Z     = help: this is likely not a bug in the program; it indicates that the program performed an operation that the interpreter does not support
   2020-08-08T00:40:34.3977300Z             
   2020-08-08T00:40:34.3978122Z     = note: inside `std::hint::black_box::<()>` at /checkout/library/core/src/hint.rs:124:9
   2020-08-08T00:40:34.3978923Z     = note: inside `std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>` at /checkout/library/std/src/sys_common/backtrace.rs:140:5
   2020-08-08T00:40:34.3979344Z     = note: inside closure at /checkout/library/std/src/rt.rs:66:18
   2020-08-08T00:40:34.3980919Z     = note: inside `std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once` at /checkout/library/core/src/ops/function.rs:265:13
   2020-08-08T00:40:34.3981920Z     = note: inside `std::panicking::r#try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /checkout/library/std/src/panicking.rs:348:40
   2020-08-08T00:40:34.3982833Z     = note: inside `std::panicking::r#try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>` at /checkout/library/std/src/panicking.rs:325:15
   2020-08-08T00:40:34.3983777Z     = note: inside `std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /checkout/library/std/src/panic.rs:394:14
   2020-08-08T00:40:34.3984193Z     = note: inside `std::rt::lang_start_internal` at /checkout/library/std/src/rt.rs:51:25
   2020-08-08T00:40:34.3984554Z     = note: inside `std::rt::lang_start::<()>` at /checkout/library/std/src/rt.rs:65:5
   2020-08-08T00:40:34.3985180Z     = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
   2020-08-08T00:40:34.3985466Z 
   2020-08-08T00:40:34.3985733Z error: aborting due to previous error
   

   We probably want to put a #[cfg(not(miri))] on the llvm_asm in black_box. @RalfJung, I presume that's fine for miri? We don't want some sort of "black box intrinsic" I think since there's nothing for miri to really do
5. eggyal commented on Aug 8, 2020

   

   eggyal

   on Aug 8, 2020

   Last edited by eggyal

   Contributor

   More actions

   Okay, thanks. (For future reference, where did you see that log? All the other CI tests that I can see passed.)
6. Mark-Simulacrum commented on Aug 8, 2020

   

   Mark-Simulacrum

   on Aug 8, 2020

   Member

   More actions

   Issues like this one are "toolstate" issues; they're autofiled when tools break in the tools builders. That breakage, however, does not actually fail the builder, instead it just files this issue. This is because miri (and the other tools using this system) are out-of-tree, managed via submodules, and we don't want to be updating the submodules in more than one PR at a time generally speaking (that just causes pain for everyone involved).
7. eggyal commented on Aug 8, 2020

   

   eggyal

   on Aug 8, 2020

   Contributor

   More actions

   Got it, thanks.
8. RalfJung commented on Aug 8, 2020

   

   RalfJung

   on Aug 8, 2020

   Member

   More actions

   There is no way Miri can support inline assembly, so yeah, a cfg(miri) sounds about right. I will submit a PR.

   I hope that black_box was not added for soundness reasons; see rust-lang/rfcs#2360 for a discussion on why that does not work.
9. eggyal commented on Aug 8, 2020

   

   eggyal

   on Aug 8, 2020

   Contributor

   More actions

   I hope that black_box was not added for soundness reasons

   If by that you mean "to avoid UB", then no it certainly wasn't. TCO of the __rush_begin_short_backtrace frame is sound, one just gets a full rather than short backtrace.
10. RalfJung commented on Aug 8, 2020

    

    RalfJung

    on Aug 8, 2020

    Member

    More actions

    Yes that looks like a valid use of black_box, good. :)
11. bors

    added 2 commits that reference this issue on Aug 8, 2020

    Auto merge of rust-lang#75282 - RalfJung:miri-black-box, r=oli-obk

    ...

    c92fc8d

    Auto merge of rust-lang#75357 - RalfJung:miri, r=RalfJung

    ...

    4c336d4
12. bors

    closed this as completedin 4c336d4on Aug 10, 2020