With miri errors are not highlighted

[Ddystopia]

Hello, which that conf added:

[jobs.miri]
command = ["cargo", "miri", "run", "--color", "always"]
need_stdout = true

bacon looks like this:

This is output if command is run directly:

[Canop]

I don't reproduce this. What version of bacon are you using ? Can you provide a minimal project for reproduction ?

I mean: warnings and errors aren't recognized as such, because there's no miri analyzer yet, but there's color.

[Ddystopia]

Steps to reproduce:

$ cargo new bacon_miri
    Creating binary (application) `bacon_miri` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
$ cd bacon_miri/
$ echo 'fn main() {
      unsafe {
          *(0xdeadbeef as *mut i32) = 42;
      }
  }
  ' > src/main.rs
$ echo '[jobs.miri]
  command = ["cargo", "miri", "run", "--color", "always"]
  need_stdout = true
  allow_warnings = true
  ' > bacon.toml
$ bacon --version
bacon 3.2.0

Terminal: alacritty

Note: those need_stdout = true and allow_warnings = true do not affect the situation

[Ddystopia]

I cloned upstream (f552bc2), everything is the same:

[Canop]

This is weird, it looks like miri doesn't always (but sometimes do) respect the --color parameter.

You can try cargo +nightly miri run --color always 2> out.txt then check with a cat out.txt

[Ddystopia]

Yeah, it is exactly like that

�[1m�[32m    Finished�[0m �]8;;https://doc.rust-lang.org/cargo/reference/profiles.html#default-profiles�\`dev` profile [unoptimized + debuginfo]�]8;;�\ target(s) in 0.00s
�[1m�[32m     Running�[0m `/home/ddystopia/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/bacon_miri`
warning: integer-to-pointer cast
 --> src/main.rs:3:10
  |
3 |         *(0xdeadbeef as *mut i32) = 42;
  |          ^^^^^^^^^^^^^^^^^^^^^^^^ integer-to-pointer cast
  |
  = help: this program is using integer-to-pointer casts or (equivalently) `ptr::with_exposed_provenance`, which means that Miri might miss pointer bugs in this program
  = help: see https://doc.rust-lang.org/nightly/std/ptr/fn.with_exposed_provenance.html for more details on that operation
  = help: to ensure that Miri does not miss bugs in your program, use Strict Provenance APIs (https://doc.rust-lang.org/nightly/std/ptr/index.html#strict-provenance, https://crates.io/crates/sptr) instead
  = help: you can then set `MIRIFLAGS=-Zmiri-strict-provenance` to ensure you are not relying on `with_exposed_provenance` semantics
  = help: alternatively, `MIRIFLAGS=-Zmiri-permissive-provenance` disables this warning
  = note: BACKTRACE:
  = note: inside `main` at src/main.rs:3:10: 3:34

error: Undefined Behavior: memory access failed: expected a pointer to 4 bytes of memory, but got 0xdeadbeef[noalloc] which is a dangling pointer (it has no provenance)
 --> src/main.rs:3:9
  |
3 |         *(0xdeadbeef as *mut i32) = 42;
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ memory access failed: expected a pointer to 4 bytes of memory, but got 0xdeadbeef[noalloc] which is a dangling pointer (it has no provenance)
  |
  = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
  = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
  = note: BACKTRACE:
  = note: inside `main` at src/main.rs:3:9: 3:39

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error; 1 warning emitted

[Canop]

rust-lang/miri#2284

[Ddystopia]

Should this issue be closed?

[Canop]

no

[Canop]

I don't really see a way for bacon to restore the missing colors, but there could be a toggle (or a "miri" analyzer) a little more lenient in its parsing an recognizing errors and warnings without styling. This would allow bacon to recognize items, make the locations export work, etc.

[Canop]

It's not really hard to detect, and it gives me this:

but without styling the tests for errors and warnings aren't really discriminant and there will be false positives :(

    } else if regex_is_match!("^error: ", content) && !regex_is_match!("^error: aborting due to", content) {
        LineType::Title(Kind::Error)
    } else if regex_is_match!("^warning: ", content) {
        LineType::Title(Kind::Warning)