Ignore intrinsic calls in cross-crate-inlining cost model
I noticed in a side project that a function which just compares to `[u64; 2]` for equality is not cross-crate-inlinable. That was surprising to me because I didn't think that code contained a function call, but of course our array comparisons are lowered to an intrinsic. Intrinsic calls don't make a function no longer a leaf, so it makes sense to add this as an exception to the "only leaves" cross-crate-inline heuristic.
This is the useful compare link: https://perf.rust-lang.org/compare.html?start=7cb1a81145a739c4fd858abe3c624ce8e6e5f9cd&end=c3f0a64dbf9fba4722dacf8e39d2fe00069c995e&stat=instructions%3Au because it disables CGU merging in both commits, so effects that cause changes in the sysroot to perturb partitioning downstream are excluded. Perturbations to what is and isn't cross-crate-inlinable in the sysroot has chaotic effects on what items are in which CGUs after merging. It looks like before this PR by sheer luck some of the CGUs dirtied by the patch in eza incr-unchanged happened to be merged together, and with this PR they are not.
The perf runs on this PR point to a nice runtime performance improvement.
Reimplement DestinationPropagation according to live ranges.
This PR reimplements DestinationPropagation as a problem of merging live-ranges of locals. We merge locals that have disjoint live-ranges. This allows merging several locals in the same round by updating live range information.
Live ranges are mainly computed using the `MaybeLiveLocals` analysis. The subtlety is that we split each statement and terminator in 2 positions. The first position is the regular statement. The second position is a shadow, which is always more live. It encodes partial writes and dead writes as a local being live for half a statement. This half statement ensures that writes conflict with another local's writes and regular liveness.
r? `@Amanieu`
Use `Itertools::all_equal_value()` where applicable
Just a small cleanup.
We already have `itertools` as a dep in these crates, so might as well use another of its features.
Makes the code simpler IMHO :)
lint ImproperCTypes: refactor linting architecture (part 1)
This is the first PR in an effort to split rust-lang/rust#134697 into individually-mergeable parts.
This one focuses on properly packaging the lint and its tests, as well as properly separate the "linting" and "type-checking" code.
There is exactly one user-visible change: the safety of `Option<Box<FFISafePointee>>` is now the same in `extern` blocks and function definitions: it is safe.
r? `@tgross35` because you are already looking at the original
gpu offload: change suspicious map into filter
Fixes clippy warning:
```text
warning: this call to `map()` won't have an effect on the call to `count()`
--> compiler/rustc_codegen_llvm/src/builder/gpu_offload.rs:194:25
|
194 | let num_ptr_types = types
| _________________________^
195 | | .iter()
196 | | .map(|&x| matches!(cx.type_kind(x), rustc_codegen_ssa::common::TypeKind::Pointer))
197 | | .count();
| |________________^
|
= help: make sure you did not confuse `map` with `filter`, `for_each` or `inspect`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#suspicious_map
= note: `-W clippy::suspicious-map` implied by `-W clippy::suspicious`
= help: to override `-W clippy::suspicious` add `#[allow(clippy::suspicious_map)]`
```
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#139524 (Add socket extensions for cygwin)
- rust-lang/rust#145940 (single buffer for exponent fmt of integers)
- rust-lang/rust#146206 (identity uses are ok, even if there are no defining uses)
- rust-lang/rust#146272 (Update comment for `-Werror` on LLVM builds)
- rust-lang/rust#146280 (Make `LetChainsPolicy` public for rustfmt usage)
r? `@ghost`
`@rustbot` modify labels: rollup
No changes should be visible by rustc users
This is just some architecture changes to the type checking to
facilitate FFI-safety decisions that depend on how the type is used
(the change here is not complete, there are still bits of "legacy" state
passing for this, but since this is a retconned commit, I can tell you
those bits will disappear before the end of the commit chain)
(there is at least one bit where the decision making code is weird, but
that this is because we do not want to change the lint's behaviour this
early in the chain)
no visible changes to rust users, just making the inner architecture of
the ImproperCTypes lints more sensible, with a clean separation between
the struct (now singular) that interacts with the linting system
and the struct (now singular) that visits the types to check FFI-safety
Mainly, we realise that the non-null assumption on a Box<_> argument
does not depend on what side of the FFI boundary the function is on.
And anyway, this is not the way to deal with this assumption being maybe violated.
identity uses are ok, even if there are no defining uses
fixrust-lang/rust#146191
I've tried moving the "is this an identity use" check to `fn clone_and_resolve_opaque_types` and this would allow the following code to compile as it now ignores `Opaque<'!a> = Opaque<'!a>` while they previously resulted in errors 71289c378d/tests/ui/type-alias-impl-trait/hkl_forbidden.rs (L42-L46)
The closure signature gets inferred to `for<'a> fn(&'a ()) -> Inner<'a>`. The closure then has a defining use `Inner<'a_latbound> = &'a_latebound ()` while the parent function has a non-defining `Inner<'!a> = Inner<'!a>`. By eagerly discarding identity uses we don't error on the non-defining use in the parent.
r? `@BoxyUwU`
Split `run-make` into two {`run-make`,`run-make-cargo`} test suites
## Summary
Split `tests/run-make` into two test suites, to make it faster and more convenient for contributors to run run-make tests that do not need in-tree `cargo`.
| New test suites | Explanation |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tests/run-make` | The "fast path" test suite intended for run-make tests that do not need in-tree `cargo`. These tests may not use `cargo`. |
| `tests/run-make-cargo` | The "slow path" test suite that requires checking out `cargo` submodule and building in-tree `cargo`, and thus will have access to in-tree `cargo`. In practice, these constitute a very small portion of the original `run-make` tests. |
This PR carries out [MCP 847: Split run-make test suite into slower-building test suite with suitably-staged cargo and faster-building test suite without cargo](https://github.com/rust-lang/compiler-team/issues/847).
Fixesrust-lang/rust#135573 (for the tests that do not need in-tree `cargo`).
Fixesrust-lang/rust#134109.
## Remarks
- I considered if we want to split by in-tree tools previously. However, as discussed rust-lang/rust#134109, in practice `rustdoc` is not very slow to build, but `cargo` takes a good few minutes. So, the partition boundary was determined to be along in-tree `cargo` availability.
- The `run-make` tests previously that wanted to use `cargo` cannot just use the bootstrap `cargo`, otherwise they would run into situations where bootstrap `cargo` can significantly diverge from in-tree `cargo` (see https://github.com/rust-lang/rust/pull/130642).
---
try-job: aarch64-msvc-1
try-job: test-various
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
try-job: aarch64-apple
try-job: dist-various-1
Disallow shebang in `--cfg` and `--check-cfg` arguments
This PR is similar to https://github.com/rust-lang/rust/issues/146130, where we disallowed frontmatter in `--cfg` and `--check-cfg` arguments. While fixing the other one we also discovered that shebang `#!/usr/bin/shebang` are currently also allowed in `--cfg` and `--check-cfg` arguments.
Allowing shebang in them (which are just ignored) was never intended, this PR fixes that by not stripping shebang for `--cfg` and `--check-cfg` arguments.
This is technically a breaking-change, although I don't expect anyone to actually rely on this unintended behavior.
Fixes https://github.com/rust-lang/rust/issues/146130#issuecomment-3246299499
r? fmease
Suggest bounds in more cases, accounting for type parameters referenced in predicate
Use a `ty::Visitor` to see if the failed predicate references a type parameter. If it does, then we only suggest adding a bound to an (associated) item only if the referenced parameter is present in its generics.
Provide adding bound suggestion in trait and impl associated functions in cases we previously weren't:
```
error[E0277]: `?` couldn't convert the error to `ApplicationError`
--> $DIR/suggest-complex-bound-on-method.rs:18:16
|
LL | t.run()?;
| -----^ the trait `From<<T as Trait>::Error>` is not implemented for `ApplicationError`
| |
| this can't be annotated with `?` because it has type `Result<_, <T as Trait>::Error>`
|
note: `ApplicationError` needs to implement `From<<T as Trait>::Error>`
--> $DIR/suggest-complex-bound-on-method.rs:12:1
|
LL | enum ApplicationError {
| ^^^^^^^^^^^^^^^^^^^^^
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: consider introducing a `where` clause, but there might be an alternative better way to express this requirement
|
LL | fn thing<T: Trait>(&self, t: T) -> Result<(), ApplicationError> where ApplicationError: From<<T as Trait>::Error> {
| +++++++++++++++++++++++++++++++++++++++++++++++++
```
Fixrust-lang/rust#144734.
move pinned version from tracing_core to tracing
This PR removes pin from `tracing-core` and moves it to `tracing`, which regressed perf in > 0.1.37 versions.
