`@semarie` this should fix your problem... but I think any version of Miri actually shipped to users should have the proper git version information embedded, so I am not sure if this is the right fix. How do you do this for rustc proper? Even stable builds usually have a git version:
```
$ rustc +stable --version
rustc 1.51.0 (2fd73fabe 2021-03-23)
```
bors [Wed, 12 May 2021 14:57:42 +0000 (14:57 +0000)]
Auto merge of #1794 - cbeuw:83813, r=RalfJung
Sync with rustc_span changes
rust-lang/rust#83813 made some changes to SourceMap and RealFileName. Now to get a string from a `rustc_span::FileName`, we need to specify if we would like the local filesystem path or remapped path via `--remap-path-prefix`. There seems to be only one place in miri that requires change.
bors [Tue, 4 May 2021 08:27:00 +0000 (08:27 +0000)]
Auto merge of #1788 - hyd-dev:rustup, r=RalfJung
`encountered a NULL reference` -> `encountered a null reference`
It's changed from "NULL" to "null" (probably by rust-lang/rust#84842) in `rustc`, and causing some test failures:
https://github.com/rust-lang/miri/runs/2498333632#step:8:640
bors [Mon, 3 May 2021 17:32:50 +0000 (17:32 +0000)]
Auto merge of #1785 - Smittyvb:fast-math-ub, r=RalfJung
Throw UB if f*_fast intrinsic called with non-finite value
Calling these intrinsics with non-finite values is undefined behaviour, since they result in `f*` intrinsics in LLVM with the `fast` flag, and `fast` math on non-finite values results in `poison` values. (technically LLVM only considers it UB upon _using_ the value, but that shouldn't make much of a difference)
bors [Sat, 1 May 2021 16:07:48 +0000 (16:07 +0000)]
Auto merge of #1784 - hyd-dev:harness-false, r=RalfJung
Use `harness = false` instead of `#![feature(custom_test_frameworks)]`
Quoting from the comment in `tests/compiletest.rs`:
> Custom test runner, to avoid libtest being wrapped around compiletest which wraps libtest.
I believe `harness = false` is more suitable for that purpose.
I have verified that both `./miri test` and `LD_LIBRARY_PATH=$PWD/build/x86_64-unknown-linux-gnu/stage2/lib PATH=$PWD/build/bin:$PATH ./x.py test src/tools/miri` work well.
Auto merge of #1769 - RalfJung:remove-compat, r=oli-obk
remove compatibility code for passing miri flags via cargo arguments
With https://github.com/rust-lang/miri/pull/1540, we deprecated `cargo miri test -- -Zmiri-disable-stacked-borrows` as a style of passing flags to Miri, introducing `MIRIFLAGS="-Zmiri-disable-stacked-borrows" cargo miri test` instead. This made `cargo miri` more compatible with `cargo`; both now behave the same in terms of argument parsing.
However, to avoid breaking things, I introduced some backwards compatibility hack such that the old way would still work. Six months later, I think it is time to remove that hack.
Auto merge of #1772 - RalfJung:less-timeout-checking, r=RalfJung
only check timeouts when a thread yields
Currently, we check for expired timeouts after each step of execution. That seems excessive. This changes the scheduler to only check for timeouts when the active thread cannot continue running any more.
`@vakaras` does this sound right? `pthread_cond_timedwait` anyway already yields, of course, since it blocks on getting the signal (or the timeout).
Auto merge of #1761 - hyd-dev:build-rs-proc-macro-no-default-args, r=RalfJung
Don't use `MIRI_DEFAULT_ARGS` to compile host crates
They (specifically, `--cfg=miri`) may cause procedural macros (and probably build scripts) to depend on Miri-only symbols, such as `miri_resolve_frame`.
This PR makes `miri` detect host crates inspecting the value of the `MIRI_BE_RUSTC` environment variable (`target` -> target crate, `host` -> host crate, other -> panic) and skip the insertion of `MIRI_DEFAULT_ARGS` if it's a host crate.
Auto merge of #1757 - RalfJung:rustdoc, r=RalfJung
add rustdoc support
`@teryror` did all the work in https://github.com/rust-lang/miri/pull/1671; I just finished things up and fixed conflicts. Also thanks to `@hyd-dev` for preemptively fixing a sysroot issue that would have taken me some time to diagnose.
Minor change: I changed the quotes around `<untagged>` into backticks, so they render correctly in markdown.
~~Significant change: I documented that `-Zmiri-track-raw-pointers` is a strictly more restrictive model that "normal" Stacked Borrows. **I am not confident this change is correct, please verify it.** If this change is not correct, let me know, and I'll update this PR to document that :-)~~
EDIT: I was wrong, `-Zmiri-track-raw-pointers` may not be strictly more restrictive. I added the following sentence to prevent others from making the same assumption that I did:
> Note that it is not currently guaranteed that code that works with `-Zmiri-track-raw-pointers` also works without `-Zmiri-track-raw-pointers`.
Improvements to the README item on `-Zmiri-track-raw-pointers`.
1. The double quotes around <untagged> are changed to backspaces, so <untagged>
will render correctly in markdown.
2. Clarify that -Zmiri-track-raw-pointers will never accept code that Miri
would not have accepted without -Zmiri-track-raw-pointers.
projects / rust.git / log