Remove reachable coverage without counters to maintain invariant that
either there is no coverage at all or there is a live coverage counter
left that provides the function source hash.
The motivating example would be a following closure:
```rust
let f = |x: bool| {
debug_assert!(x);
};
```
Which, with span changes from #93967, with disabled debug assertions,
after the final CFG simplifications but before removal of dead blocks,
gives rise to MIR:
```rust
fn main::{closure#0}(_1: &[closure@a.rs:2:13: 2:22], _2: bool) -> () {
debug x => _2;
let mut _0: ();
bb0: {
Coverage::Expression(4294967295) = 1 - 2;
return;
}
...
}
```
add miri-track-caller to more intrinsic-exposing methods
Follow-up to https://github.com/rust-lang/rust/pull/98674: I went through the Miri test suite to find more functions that would benefit from Miri backtrace pruning, and this is what I found.
Basically anything that just exposes a potentially-UB intrinsic to the user should get this treatment.
Use `VecMap::get` in `ConstraintLocator::check`
Also rename the `def_id` param to `item_def_id` because that's easily confused with `self.def_id` (which is the opaque ty did).
Add `sign-ext` target feature to the WASM target
Some target features are still missing from that list.
See #97808 for basically the same PR by `@alexcrichton.`
Related issue: #96472.
PR introducing this issue: #87402.
Improve error messages involving `derive` and `packed`.
There are two errors involving `derive` and `packed`.
```
`#[derive]` can't be derived on a `#[repr(packed)]` struct with type or const parameters
`#[derive]` can't be derived on a `#[repr(packed)]` struct that does not derive Copy
```
The second one overstates things. It is possible to use derive on a
repr(packed) struct that doesn't derive Copy in two cases.
- If all the fields within the struct meet the required alignment: 1 for
`repr(packed)`, or `N` for `repr(packed(N))`.
- If `Default` is the only trait derived.
This commit improves things in a few ways.
- Changes the errors to say `this trait can't be derived on this ...`.
This is more accurate, because it's just *this* trait and *this*
packed struct that are a problem, not *all* derived traits on *all*
packed structs.
- Adds more details to the "ERROR" lines in the test case, enough to
distinguish between the two error messages.
- Adds more cases to the test case that don't cause errors, e.g. `Default`
derives.
- Uses a wider variety of builtin traits in the test case, for better coverage.
r? `@estebank`
Use non-relocatable code in nofile-limit.rs test
To avoid using static-pie which is not essential to the test but which
was reported to cause problems on Void Linux where glibc is build
without support for static-pie.
kmc-solid: Use `libc::abort` to abort a program
This PR updates the target-specific abort subroutine for the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
The current implementation uses a `hlt` instruction, which is the most direct way to notify a connected debugger but is not the most flexible way. This PR changes it to call the `abort` libc function, making it possible for a system designer to override its behavior as they see fit.
rmeta: avoid embedding `StabilityLevel::Unstable` reason multiple times into .rmeta\.rlib files
Avoids bloating size of some rmeta\rlib files by not placing default string for `StabilityLevel::Unstable` reason multiple times, affects only stdlib\rustc artifacts. For stdlib cuts about 3% (diff of total size for patched\unpatched *.rmeta files of stage1-std) of file size, depending on crates.
fixes#88180
There are two errors involving `derive` and `packed`.
```
`#[derive]` can't be derived on a `#[repr(packed)]` struct with type or const parameters
`#[derive]` can't be derived on a `#[repr(packed)]` struct that does not derive Copy
```
The second one overstates things. It is possible to use derive on a
repr(packed) struct that doesn't derive Copy in two cases.
- If all the fields within the struct meet the required alignment: 1 for
`repr(packed)`, or `N` for `repr(packed(N))`.
- If `Default` is the only trait derived.
This commit improves things in a few ways.
- Changes the errors to say `$TRAIT can't be derived on this ...`.
This is more accurate, because it's just $TRAIT and *this* packed
struct that are a problem, not *all* derived traits on *all* packed
structs.
- Adds more details to the "ERROR" lines in the test case, enough to
distinguish between the two error messages.
- Adds more cases to the test case that don't cause errors, e.g. `Default`
derives.
- Uses a wider variety of builtin traits in the test case, for better coverage.
Support vec zero-alloc optimization for tuples and byte arrays
* Implement IsZero trait for tuples up to 8 IsZero elements;
* Implement IsZero for u8/i8, leading to implementation of it for arrays of them too;
* Add more codegen tests for this optimization.
* Lower size of array for IsZero trait because it fails to inline checks
Convert rust-analyzer to an in-tree tool
This re-adds `rust-lang/rust-analyzer` as a git subtree rather than a submodule.
Closes https://github.com/rust-lang/rust-analyzer/issues/12815.
Prior attempt (research PR): https://github.com/rust-lang/rust/pull/99465
* [x] Remove submodule: `git rm -f src/tools/rust-analyzer`
* [x] Add subtree: `git subtree add -P src/tools/rust-analyzer https://github.com/rust-lang/rust-analyzer.git master`
* [x] Move to `SourceType::InTree`,
* [x] Enable `rust-analyzer/in-rust-tree` feature when built through `x.py`
* [x] Add 'check' step
* [x] Add 'test' step
With this PR, rust-analyzer becomes an "in-tree" tool. Syncs can happen in both directions, see [clippy's relevant book section](https://doc.rust-lang.org/nightly/clippy/development/infrastructure/sync.html).
Making sure `proc-macro-srv` doesn't break when the proc_macro bridge changes effectively becomes the responsibility of `rust-lang/rust` contributors. These days, that's mostly `@mystor,` who has been consulted throughout the process. I'm also making myself available in case there's questions / work needed that nobody else signed up for.
This doesn't change rust-analyzer's release cycle. After this PR is merged and the next nightly goes out, one can point `rust-analyzer.procMacro.server` to the rustup-provided `rust-analyzer` binary. Changes to improve the situation further (auto-discovery/install of the rust-analyzer component) will happen in `rust-lang/rust-analyzer` and be synced here eventually.
* Implement IsZero trait for tuples up to 8 IsZero elements;
* Implement IsZero for u8/i8, leading to implementation of it for arrays of them too;
* Add more codegen tests for this optimization.
* Lower size of array for IsZero trait because it fails to inline checks