Only create a single expansion for each inline integration.
The inlining integrator used to create one expansion for each span from the callee body.
This PR reverses the logic to create a single expansion for the whole call,
which is more consistent with how macro expansions work for macros.
This should remove the large memory regression in #91743.
Apply noundef metadata to loads of types that do not permit raw init
This matches the noundef attributes we apply on arguments/return types.
Fixes (partially) #74378.
Rollup of 7 pull requests
Successful merges:
- #94396 (1 - Make more use of `let_chains`)
- #94397 (Document that pre-expansion lint passes are softly deprecated)
- #94399 (Add test for #79465 to prevent regression)
- #94409 (avoid rebuilding bootstrap when PATH changes)
- #94415 (Use the first codegen backend in the config.toml as default)
- #94417 (Fix duplicated impl links)
- #94420 (3 - Make more use of `let_chains`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Apply noundef attribute to all scalar types which do not permit raw init
Beyond `&`/`&mut`/`Box`, this covers `char`, enum discriminants, `NonZero*`, etc.
All such types currently cause a Miri error if left uninitialized,
and an `invalid_value` lint in cases like `mem::uninitialized::<char>()`.
Note that this _does not_ change whether or not it is UB for `u64` (or
other integer types with no invalid values) to be undef.
Fixes (partially) #74378.
r? `@ghost` (blocked on #94127)
`@rustbot` label S-blocked
Use the first codegen backend in the config.toml as default
It is currently hard coded to llvm if enabled and cranelift otherwise.
This made some sense when cranelift was the only alternative codegen
backend. Since the introduction of the gcc backend this doesn't make
much sense anymore. Before this PR bootstrapping rustc using a backend
other than llvm or cranelift required changing the source of
rustc_interface. With this PR it becomes a matter of putting the right
backend as first enabled backend in config.toml.
cc ```@antoyo```
Document that pre-expansion lint passes are softly deprecated
The pre-expansion lint pass has been softly deprecated since https://github.com/rust-lang/rust/pull/69838. Every once in a while I see someone mention it as a possibility, only get the feedback that it's deprecated. This PR officially documents that the method is soft deprecated to have a single point of truth for it.
That's it. Have a great rest of the day 🙃
---
* See [rust#69838](https://github.com/rust-lang/rust/pull/69838)
* See [rust-clippy#5518](https://github.com/rust-lang/rust-clippy/pull/5518)
Avoid query cache sharding code in single-threaded mode
In non-parallel compilers, this is just adding needless overhead at compilation time (since there is only one shard statically anyway). This amounts to roughly ~10 seconds reduction in bootstrap time, with overall neutral (some wins, some losses) performance results.
Parallel compiler performance should be largely unaffected by this PR; sharding is kept there.
It is currently hard coded to llvm if enabled and cranelift otherwise.
This made some sense when cranelift was the only alternative codegen
backend. Since the introduction of the gcc backend this doesn't make
much sense anymore. Before this PR bootstrapping rustc using a backend
other than llvm or cranelift required changing the source of
rustc_interface. With this PR it becomes a matter of putting the right
backend as first enabled backend in config.toml.
rustc_trait_selection: adopt let else in more places
Continuation of #89933, #91018, #91481, #93046, #93590, #94011.
I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This PR handles rustc_trait_selection.
No branch protection metadata unless enabled
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.
This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.
Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
Beyond `&`/`&mut`/`Box`, this covers `char`, discriminants, `NonZero*`, etc.
All such types currently cause a Miri error if left uninitialized,
and an `invalid_value` lint in cases like `mem::uninitialized::<char>()`
Note that this _does not_ change whether or not it is UB for `u64` (or
other integer types with no invalid values) to be undef.
Restrict query recursion in `needs_significant_drop`
Overly aggressive use of the query system to improve caching lead to query cycles and consequently ICEs. This patch fixes this by restricting the use of the query system as a cache to those cases where it is definitely correct.
Closes#92725 .
This is essentially a revert of #90845 for the significant drop case only. The general `needs_drop` still does the same thing. The hope is that this is enough to preserve the performance improvements of that PR while fixing the ICE. Should get a perf run to verify that this is the case.
cc `@cjgillot`
Initiate the inner usage of `let_chains`
The intention here is create a strong and robust foundation for a possible future stabilization so please, do not let the lack of any external tool support prevent the merge of this PR. Besides, `let_chains` is useful by itself.
cc #53667
Rollup of 5 pull requests
Successful merges:
- #93400 (Do not suggest using a const parameter when there are bounds on an unused type parameter)
- #93982 (Provide extra note if synthetic type args are specified)
- #94087 (Remove unused `unsound_ignore_borrow_on_drop`)
- #94235 (chalk: Fix wrong debrujin index in opaque type handling.)
- #94306 (Avoid exhausting stack space in dominator compression)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid exhausting stack space in dominator compression
Doesn't add a test case -- I ended up running into this while playing with the generated example from #43578, which we could do with a run-make test (to avoid checking a large code snippet into tree), but I suspect we don't want to wait for it to compile (locally it takes ~14s -- not terrible, but doesn't seem worth it to me). In practice stack space exhaustion is difficult to test for, too, since if we set the bound too low a different call structure above us (e.g., a nearer ensure_sufficient_stack call) would let the test pass even with the old impl, most likely.
Locally it seems like this manages to perform approximately equivalently to the recursion, but will run perf to confirm.
chalk: Fix wrong debrujin index in opaque type handling.
A folder in opaque type lowering was substituting all opaque type references with a variable with debrujin index 0 ignoring how many binders deep we are.
This caused an ICE with `Not enough bound vars: ^0 not found in []` ([full logs](https://gist.github.com/Dirbaio/2b9374ff4fce37afb9d665dc9f0000df)) with the following code.
```rust
fn main() -> () {}
async fn foo(x: u32) -> u32 {
x
}
```
With the fix, it no longer ICEs. It still doesn't typecheck due to generator issues. I've added a "known-bug" test so that at least it doesn't regress back to ICEing.
r? ``@jackh726``
fix a message
implement a rustfix-applicable suggestion
implement `suggest_floating_point_literal`
add `ObligationCauseCode::BinOp`
remove duplicate code
fix function names in uitests
use `Diagnostic` instead of `DiagnosticBuilder`
Populate liveness facts when calling `get_body_with_borrowck_facts` without `-Z polonius`
For a new feature of [Flowistry](https://github.com/willcrichton/flowistry), a static-analysis tool, we need to obtain a `mir::Body`'s liveness facts using `get_body_with_borrowck_facts` (added in #86977). We'd like to do this without passing `-Z polonius` as a compiler arg to avoid borrow checking the entire crate.
Support for doing this was added in #88983, but the Polonius input facts used for liveness analysis are empty. This happens because the liveness input facts are populated in `liveness::generate` depending only on the value of `AllFacts::enabled` (which is toggled via compiler args).
This PR propagates the [`use_polonius`](8b09ba6a5d/compiler/rustc_borrowck/src/nll.rs (L168)) flag to `liveness::generate` to support populating liveness facts without requiring the `-Z polonius` flag.
This fix is somewhat patchy - if it'd be better to add more widely-accessible state (like `AllFacts::enabled`) I'd be open to ideas!
