| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Rustup
|
|
|
|
|
|
|
|
TB: more fail tests (mostly shared with SB)
Although it was not in the tests, `mem::transmute` works for `UnsafeCell -> &` as well.
Draft: will also introduce more test cases for cases that fail.
Draft: depends on the new error messages from #2888
|
|
|
|
- reorganize tests/ structure: {stacked,tree,both}_borrows
- UnsafeCell transmutation (the one that should fail, i.e. transmute &
-> UnsafeCell then try to write)
- select TB pass tests from existing SB fail tests (and a version that
fails TB)
- many fail tests now shared
* extra test for TB that parent write invalidates child reads
* buggy_* tests now shared
* tests for deep retagging (pass_invalid_shr_*) now shared
* extra TB test that shared references are read-only
* aliasing_mut{1,2,3,4} adapted to fail both
* extra TB test that write to raw parent invalidates shared children
* mut_exclusive_violation2 now shared
* issue-miri-1050-2 revisions fix
- deduplications
|
|
|
|
|
|
|
|
|
|
Rustup
|
|
|
|
TB diagnostics: avoid printing irrelevant events
History contains some events that are relevant to the location but not useful to understand the error.
We can make the selection of events more precise, from only "does it affect the location" to also "is it relevant for this kind of error"
This is also the occasion to fix https://github.com/rust-lang/miri/pull/2867#issuecomment-1530065511
[Solved] Draft: find a way for blanks in the history to not be confusing, as with the current version the history can show the creation as `Reserved` then show where it transitioned from `Frozen` to `Disabled`, but it will say nothing of the `Reserved -> Frozen` leading up to it.
|
|
|
|
|
|
impl of is_relevant on transitions makes for much less noise in error messages
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
Remove ExpnKind::Inlined.
Suggested in https://github.com/rust-lang/rust/pull/111815#issuecomment-1561903339
r? ``@oli-obk``
|
|
Support #[global_allocator] without the allocator shim
This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim.
Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist.
To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors.
(Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
|
|
|
|
Hide full miri command line in `./miri run-dep`
fixes #2443
|
|
|
|
|
|
Rename `{drop,forget}_{copy,ref}` lints to more consistent naming
This PR renames previous uplifted lints in https://github.com/rust-lang/rust/pull/109732 to more consistent naming.
I followed the renaming done [here](https://github.com/rust-lang/rust/issues/53224) and also advocated in this [clippy issue](https://github.com/rust-lang/rust-clippy/issues/2845):
- `drop_copy` to `dropping_copy_types`
- `forget_copy` to `forgetting_copy_types`
- `drop_ref` to `dropping_references`
- `forget_ref` to `forgetting_references`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
update Miri
and run mir-opt-level=4 tests in rustc CI so issues like https://github.com/rust-lang/rust/issues/111422 are caught before they land.
r? `@oli-obk` due to the bootstrap changes
|
|
Add `./miri run-dep` for running a file with test dependencies available
fixes #2443
|
|
|
|
Uplift `clippy::{drop,forget}_{ref,copy}` lints
This PR aims at uplifting the `clippy::drop_ref`, `clippy::drop_copy`, `clippy::forget_ref` and `clippy::forget_copy` lints.
Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted.
## `drop_ref` and `forget_ref`
The `drop_ref` and `forget_ref` lint checks for calls to `std::mem::drop` or `std::mem::forget` with a reference instead of an owned value.
### Example
```rust
let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();
```
### Explanation
Calling `drop` or `forget` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` or `forget` method on the underlying referenced value, which is likely what was intended.
## `drop_copy` and `forget_copy`
The `drop_copy` and `forget_copy` lint checks for calls to `std::mem::forget` or `std::mem::drop` with a value that derives the Copy trait.
### Example
```rust
let x: i32 = 42; // i32 implements Copy
std::mem::forget(x) // A copy of x is passed to the function, leaving the
// original unaffected
```
### Explanation
Calling `std::mem::forget` [does nothing for types that implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the value will be copied and moved into the function on invocation.
-----
Followed the instructions for uplift a clippy describe here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
cc `@m-ou-se` (as T-libs-api leader because the uplifting was discussed in a recent meeting)
|
|
|
|
|
|
|
|
It isn't clear to me why these error patterns do not trigger,
but I am not going to waste time analyzing bugs in compiletest.
|
|
|
|
|
|
|
|
|
