Detect `std` by checking if the crate defines `#[lang = "start"]` rather than string comparison
I also considered to compare the crate name with `sym::std`, but it's easy to name any crate `std` by using `--crate-name std`, so I don't think that is robust enough.
Note that this only checks the crate, it does not check whether the call is in `sys::unix` or `sys::windows`, unlike the previous implementation, but I think it's already robust enough.
Fixes#1821.
added a strings.rs regression test case for potential future UB
This PR adds a regression test for the aliasing rules of a `Unique<T>` pointer.
At the time of writing this test case, Miri does not treat `Unique<T>`
pointers as a special case, these are treated like any other raw pointer.
However, there are existing Github issues which may lead to `Unique<T>`
becoming a special case through asserting unique ownership over the pointee:
- https://github.com/rust-lang/unsafe-code-guidelines/issues/258
- https://github.com/rust-lang/unsafe-code-guidelines/issues/262
In the new test case, the calls to `String::remove` and `String::insert[_str]` follow
code paths that would trigger undefined behavior in case `Unique<T>`
would ever assert semantic ownership over the pointee. Internally,
these methods call `self.vec.as_ptr()` and `self.vec.as_mut_ptr()` on
the vector of bytes that are backing the `String`. That `Vec<u8>` holds a
`Unique<u8>` internally. The second call to `Vec::as_mut_ptr(&mut self)`
would then invalidate the pointers derived from `Vec::as_ptr(&self)`.
Note that as long as `Unique<T>` is treated like any other raw pointer,
this test case should pass. It is merely here as a canary test for
potential future undefined behavior.
regression tests for pointer invalidation in core library slice methods
A fix for a pointer invalidation bug in `<[T]>::copy_within` has [landed](https://github.com/rust-lang/rust/pull/85610) on the Rust master branch. This PR updates the `rust-version` file to the latest master commit hash and adds extra tests to the Miri test suite to ensure that regressions of this type of bug can be detected for various slice methods with the `-Zmiri-track-raw-pointers` flag.
I took the liberty of adding 2 extra `#![feature]` attributes at the top of `slices.rs`, since there already was one unstable feature. I hope this is okay 😄
One thing I noticed when running the entire Miri test suite with `MIRIFLAGS="-Zmiri-track-raw-pointers" ./miri test` is that there are currently failing tests on the master branch:
```
failures:
[ui] run-pass/align.rs
[ui] run-pass/box.rs
[ui] run-pass/concurrency/simple.rs
[ui] run-pass/libc.rs
[ui] run-pass/ptr_int_casts.rs
[ui] run-pass/stacked-borrows/int-to-ptr.rs
test result: FAILED. 199 passed; 6 failed; 1 ignored; 0 measured; 0 filtered out; finished in 12.95s
```
These failures were not fixed in this PR and already existed prior to this PR. I haven't investigated these yet, but am interested in helping out if possible!
Thanks!
`original_crate_name` -> `crate_name`
`original_crate_name` was removed in rust-lang/rust#85904, and according to that PR, it "had the exact same implementation" as `crate_name`.
cc rust-lang/rust#85946
Add `measureme` integration for profiling the interpreted program
This PR uses the `measureme` crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The `measureme` tooling can be used to produce a
call stack from the generated profile data.
Limitations:
* We currently record every single entry/exit. This might generate very
large profile outputs for programs with a large number of function
calls. In follow-up work, we might want to explore sampling (e.g. only
recording every N function calls).
* This does not integrate very well with Miri's concurrency support.
Each event we record starts when we push a frame, and ends when we pop
a frame. As a result, the timing recorded for a particular frame will include all of the work Miri does before that frame completes, including executing another thread.
The `measureme` integration is off by default, and must be enabled via
`-Zmiri-measureme=<output_name>`
This PR uses the `measureme` crate to profile the call stack of the
program being interpreted by Miri. This is accomplished by starting a
measureme 'event' when we enter a function call, and ending the event
when we exit the call. The `measureme` tooling can be used to produce a
call stack from the generated profile data.
Limitations:
* We currently record every single entry/exit. This might generate very
large profile outputs for programs with a large number of function
calls. In follow-up work, we might want to explore sampling (e.g. only
recording every N function calls).
* This does not integrate very well with Miri's concurrency support.
Each event we record starts when we push a frame, and ends when we pop
a frame. As a result, switching between virtual threads will cause
events from different threads to be interleaved. Additionally, the
recorded for a particular frame will include all of the work Miri does
before that frame completes, including executing another thread.
The `measureme` integration is off by default, and must be enabled via
`-Zmiri-measureme=<output_name>`
Skip doctests of `proc-macro` crates
Fixes#1813.
Verified that the newly added tests failed without the `cargo-miri` change and pass with normal `cargo test`.
bors