| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.)
|
|
|
|
|
|
|
|
|
|
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`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suppress "erroneous constant used" for constants tainted by errors
When constant evaluation fails because its MIR is tainted by errors,
suppress note indicating that erroneous constant was used, since those
errors have to be fixed regardless of the constant being used or not.
Fixes #110891.
|
|
|
|
|
|
|
|
When constant evaluation fails because its MIR is tainted by errors,
suppress note indicating that erroneous constant was used, since those
errors have to be fixed regardless of the constant being used or not.
|
|
support array return types in simd_bitmask
Fixes https://github.com/rust-lang/miri/issues/2734
As usual I am stomped by the simd_bitmask behavior wrt endianess. I confirmed that for little endian, Miri matches what rustc currently does, but I can't test rustc on big endian. `@workingjubilee` `@calebzulawski` could you have a look whether those new tests make sense?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Include the current Crate name in the measureme output name
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/measureme.20flamegraph.20panics/near/356367013
cc `@andjo403`
Currently, attempting to use `MIRIFLAGS=-Zmiri-measureme=miri cargo miri test` on a crate with multiple test targets (which is very common) will produce a corrupted measureme output file, because the various interpreter processes will stomp each other's output.
This change does not entirely prevent this, but the various test targets seem to always have different crate names, so if nothing else this will make the broken measureme files much harder to encounter by accident, while also making it clear what they are all for.
|
|
|
|
|
