fix: Recompiles due to RUSTC_BOOTSTRAP
Some packages (e.g. thiserror) force a recompile if the value of the `RUSTC_BOOTSTRAP` env var changes. RA sets the variable to 1 in order to enable rustc / cargo unstable options. This causes flapping recompiles when building outside of RA.
Fixes#15057
Make QNX/NTO specific "timespec capping" public to crate::sys
It is used in:
- `library/std/src/sys/locks/condvar/pthread.rs`
- `library/std/src/sys/pal/unix/thread_parking/pthread.rs`
This is probably required due to introduction of `sys/pal` and #121177
`@rustbot` label +O-neutrino
CC: `@jonathanpallant` `@japaric` `@gh-tr`
coverage: Rename `is_closure` to `is_hole`
Extracted from #121433, since I was having second thoughts about some of the other changes bundled in that PR, but these changes are still fine.
---
When refining covspans, we don't specifically care which ones represent closures; we just want to know which ones represent "holes" that should be carved out of other spans and then discarded.
(Closures are currently the only source of hole spans, but in the future we might want to also create hole spans for nested items and inactive `#[cfg(..)]` regions.)
``@rustbot`` label +A-code-coverage
Don't ICE on anonymous struct in enum variant
Fixes#121446
Computing `adt_def` for the anon struct calls `adt_def` on the parent to find its repr. If the parent is a non-item (e.g. an enum variant) we should have already emitted at least one error, so we just use the repr of the anonymous struct to avoid an ICE.
cc ``@frank-king``
mark `min_exhaustive_patterns` as complete
This is step 1 and 2 of my [proposal](https://github.com/rust-lang/rust/issues/119612#issuecomment-1918097361) to move `min_exhaustive_patterns` forward. The vast majority of in-tree use cases of `exhaustive_patterns` are covered by `min_exhaustive_patterns`. There are a few cases that still require `exhaustive_patterns` in tests and they're all behind references.
r? ``@ghost``
internal: Optimize salsa memory usage
Reduces memory on self by ~20mb for me, there is a few more mb to save here if we made LRU caching opt-in, as currently every entry in a memoized query will store an `AtomicUsize` for the LRU.
Thank you.
This is part of changing attributes to only_local. I hope get your opinion whether I should split into multiple PRs, or submit in one.
According to [try to not rely on attributes from extern crates](https://github.com/rust-lang/compiler-team/issues/505) and lcnr's guidance.
region unification: update universe of region vars
necessary for #119106. see inline comment for why this is necessary
r? `@compiler-errors` `@BoxyUwU`
When refining covspans, we don't specifically care which ones represent
closures; we just want to know which ones represent "holes" that should be
carved out of other spans and then discarded.
(Closures are currently the only source of hole spans, but in the future we
might want to also create hole spans for nested items and inactive `#[cfg(..)]`
regions.)
Explicitly call `emit_stashed_diagnostics`.
Commit 72b172b in #121206 changed things so that
`emit_stashed_diagnostics` is only called from `run_compiler`. But rustfmt doesn't use `run_compiler`, so it needs to call `emit_stashed_diagnostics` itself to avoid an abort in `DiagCtxtInner::drop` when stashed diagnostics occur.
Fixes#121450.
r? `@oli-obk`
coverage: Use variable name `this` in `CoverageGraph::from_mir`
A tiny little improvement, extracted from #120013.
This makes it easier to see that we're manipulating the instance that is being constructed, and is a lot less verbose than `basic_coverage_blocks`.
Allow for a missing `adt_def` in `NamePrivacyVisitor`.
This was caused by 72b172bdf6 in #121206. That commit removed an early return from `analysis` when there are stashed errors. As a result, it's possible to reach privacy analysis when there are stashed errors, which means more code paths can be reached. One such code path was handled in that commit, where a `span_bug` was changed to a `span_delayed_bug`.
This commit handles another such code path uncovered by fuzzing, in much the same way.
Fixes#121455.
r? `@oli-obk`
Fix more #121208 fallout
#121208 converted lots of delayed bugs to bugs. Unsurprisingly, there were a few invalid conversion found via fuzzing.
r? `@lcnr`
fix generalizer unsoundness
I ended up getting confused while trying to flip the variances when flipping the order. Should be all right now.
This is only exploitable when generalizing if the `ambient_variance` of the relation is `Contravariant`. This can currently only be the case in the NLL generalizer which only rarely generalizes, causing us to miss this regression. Very much an issue with #121462 however.
remove `llvm.assertions=true` in compiler profile
Having this set to true disrupts compiler development workflows for people who use `llvm.download-ci-llvm = true` because we don't provide ci-llvm on the `rustc-alt-builds` server. Therefore, it is kept off by default.
cc `@Nilstrieb` `@compiler-errors`
For more context, see https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/CI.20LLVM.20for.20aarch64
When encountering `<&T as Clone>::clone(x)` because `T: Clone`, suggest `#[derive(Clone)]`
CC #40699.
```
warning: call to `.clone()` on a reference in this situation does nothing
--> $DIR/noop-method-call.rs:23:71
|
LL | let non_clone_type_ref_clone: &PlainType<u32> = non_clone_type_ref.clone();
| ^^^^^^^^
|
= note: the type `PlainType<u32>` does not implement `Clone`, so calling `clone` on `&PlainType<u32>` copies the reference, which does not do anything and can be removed
help: remove this redundant call
|
LL - let non_clone_type_ref_clone: &PlainType<u32> = non_clone_type_ref.clone();
LL + let non_clone_type_ref_clone: &PlainType<u32> = non_clone_type_ref;
|
help: if you meant to clone `PlainType<u32>`, implement `Clone` for it
|
LL + #[derive(Clone)]
LL | struct PlainType<T>(T);
|
```
