Skip to content

MIRI_NO_STD can lead to very confusing errors #3529

Closed
rust-lang/rust
#124582
@RalfJung

Description

@RalfJung
Member

To reproduce, consider the following crate:

[package]
name = "embeddedMiri"
version = "0.1.0"
edition = "2021"

[profile.dev]
panic ='abort'

[profile.release]
panic ='abort'

[dependencies]
panic-semihosting = "0.6.0"

with main.rs being

#![no_std]
#![feature(start)]

use panic_semihosting as _;

#[start]
fn main(_argc: isize, _argv: *const *const u8) ->isize{
    panic!("hello")
}

It turns out panic_semihosting actually needs std on targets that do not satisfy all(target_arch = "arm", target_os = "none").

When running this with a truly no-std target such as x86_64-unknown-none, this is very clear from the error:

error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-unknown-none` target may not support the standard library
  = note: `std` is required by `panic_semihosting` because it does not declare `#![no_std]`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

However, when one does MIRI_NO_STD=1 cargo miri run to run this without std on a target that has std, the error is pretty bad:

error[E0463]: can't find crate for `panic_semihosting`
 --> src/main.rs:4:5
  |
4 | use panic_semihosting as _;
  |     ^^^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `panic_semihosting`
 --> src/main.rs:4:5
  |
4 | use panic_semihosting as _;
  |     ^^^^^^^^^^^^^^^^^ can't find crate
  |
  = note: duplicate diagnostic emitted due to `-Z deduplicate-diagnostics=no`

error: `#[panic_handler]` function required, but not found

error: aborting due to 3 previous errors

I don't know exactly why that is. But my current inclination is to just remove the MIRI_NO_STD env var; it shouldn't be needd as -none targets get built without std automatically...

Activity

RalfJung

RalfJung commented on May 1, 2024

@RalfJung
MemberAuthor

Amusingly, MIRI_NO_STD=1 cargo miri run --target i686-unknown-linux-gnu actually gives a nice error. It is only MIRI_NO_STD=1 with the host target that produces a bad error.

added a commit that references this issue on May 2, 2024

Rollup merge of rust-lang#124582 - RalfJung:std-not-found, r=Nilstrieb

871f047
added a commit that references this issue on May 2, 2024
RalfJung

RalfJung commented on May 3, 2024

@RalfJung
MemberAuthor

Somehow rust-lang/rust#124582 did not help, this still prints the same bad error. I don't know why things behave different for the host target vs anther target.

RalfJung

RalfJung commented on May 3, 2024

@RalfJung
MemberAuthor

Ah, the issue arises when first doing cargo miri run and then later MIRI_NO_STD=1 cargo miri run. There's stuff cached in the target dir that seems to confuse rustc. cargo miri clean fixes this.

I think that's good enough for now; though if MIRI_NO_STD keeps confusing people maybe we should entirely remove it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @RalfJung

      Issue actions

        MIRI_NO_STD can lead to very confusing errors · Issue #3529 · rust-lang/miri