Fix unused assignments in diverging branches
Fixesrust-lang/rust#156416
Add `location` and use `is_predecessor_of` to check in the control flow graph.
r? @ghost
I'd like to see whether there is performence regression.
Add Swift function call ABI
Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature gate, mapping to LLVM's `swiftcc` calling convention. This is only allowed (a) for `is_darwin_like` targets, since the [ABI is only stable for those platforms](https://www.swift.org/blog/abi-stability-and-more/) and (b) with the LLVM backend, since the other backends don't support it.
Current approaches to interoperability with Swift lower to Objective-C (or require a Swift stub exposing a C ABI), but that is an optional mapping on the Swift side that some newer Apple frameworks omit. It would be great to be able to more directly/natively be able to call into Swift code directly via its stable API (on Apple platforms at least).
Reimplements rust-lang/rust#64582 on top of current main. The main objection to the previous PR seemed to be that it needed an RFC, but there was pushback (which seems sensible to me) that an RFC could be deferred until stabilization.
I think this needs a tracking issue? Would be happy to write one up if/when there is a consensus that this will be merged.
It's currrently `(Option<(Level, Option<LintExpectationId>)>,
LintLevelSource)`. But when the first element of the pair is `None` the
second element is always `LintLevelSource::Default`. So this commit
moves the `LintLevelSource` within the `Option`, which simplifies
things a bit.
It currently returns a triple: `(Level, Option<LintExpectationId>,
LintLevelSource)`. That's structurally identical to `LevelAndSource`, so
this commit changes it accordingly.
`reveal_actual_level` has two call sites, which look like this:
```
let (level, mut src) = self.raw_lint_id_level(lint, idx, aux);
let (level, lint_id) = reveal_actual_level(level, &mut src, sess, lint, |id| {
self.raw_lint_id_level(id, idx, aux)
});
```
and:
```
let (level, mut src) = self.probe_for_lint_level(tcx, lint, cur);
let (level, lint_id) = reveal_actual_level(level, &mut src, tcx.sess, lint, |lint| {
self.probe_for_lint_level(tcx, lint, cur)
});
```
They both have the same pattern: there's a prior call expression that is then
repeated within a closure passed to `reveal_actual_level`.
This commit moves that prior call inside `reveal_actual_level`, making things
simpler.
Remove the dummy `PreCodegen` mir-opt pass, and use `runtime-optimized` instead
- Alternative to https://github.com/rust-lang/rust/pull/156358.
The `PreCodegen` pass doesn't do anything on its own; it was only serving as a marker to allow `-Zdump-mir` and mir-opt tests to easily dump the final MIR just before codegen.
However, https://github.com/rust-lang/rust/pull/156358#issuecomment-4422445297 pointed out that the `runtime-optimized` phase transition should dump the same MIR, so there shouldn't be any need for a separate *PreCodegen* pass.
---
r? oli-obk (or compiler)
bootstrap: remap windows-style OUT_DIR paths
### problem:
on windows, some paths embedded into debuginfo / metadata may internally use `\` separators, while the existing `RUSTC_DEBUGINFO_MAP` remapping only covers the `/` form of `self.build.out`.
### fix:
add an additional remap entry for the windows style `\` variant of `self.build.out`.
### result:
improves path remapping consistency on windows, in turn helping with reproducibility.
r? @bjorn3
Add support for Zprint-codegen-stats-json
Add a flag `-Zprint-codegen-stats-json=<file>` to collect and write LLVM statistics in JSON format. It makes use of the function `llvm::PrintStatisticsJSON` in LLVM.
The flag currently only obtains LLVM statistics for now, but could be used to collect more front-end statistics in the future.
This function doesn't have an obvious home, but there's little reason for it to
be in mir-transform, and having it in `rustc_driver_impl::pretty` at least puts
it near other callers of `write_mir_pretty`.
Unnormalized migration: assert_fully_normalized, struct_tail, and `field.ty`
tracking issue: https://github.com/rust-lang/rust/issues/155345 (first checkbox, and partial second checkbox, of that issue)
I'm going a bit slower than expected (less free time than I'd hope, lots of GCA work that I'm doing instead), and figured I'd just submit what I have now rather than building up a big batch of changes. Slow and steady!
r? @lcnr
Move `std::io::util` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Subset of: https://github.com/rust-lang/rust/pull/154684
## Description
Moves utility types and functions from `std::io::util` and `std::io` to `core::io`, leaving any IO trait implementations behind. They will be moved along with the traits themselves. Certain documentation links had to be amended.
- `Chain`
- `Empty`
- `Repeat`
- `Sink`
- `Take`
- `empty`
- `repeat`
- `sink`
---
## Notes
* This can be reviewed independently of the other PRs tracked in rust-lang/rust#154046.
* `Chain` and `Take` were previously in the main `mod.rs` file for `std::io`, but I've chosen to move them into the `util.rs` file in `core::io` instead. I think they make more sense in that file, but I'm happy to move them into `mod.rs` if that's a controversial decision.
* No AI tooling of any kind was used during the creation of this PR.
Move `std::io::Cursor` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Subset of: https://github.com/rust-lang/rust/pull/154684
## Description
Moves `std::io::Cursor` to `core::io`, leaving the IO trait implementations behind. They will be moved along with the traits themselves. Certain documentation links had to be amended, and a private/unstable `into_parts_mut` method was added to allow the internals to remain private.
---
## Notes
* This can be reviewed independently of the other PRs tracked in rust-lang/rust#154046.
* No AI tooling of any kind was used during the creation of this PR.
Adds an unstable `extern "Swift"` ABI behind the `abi_swift` feature
gate, mapping to LLVM's `swiftcc` calling convention. Cranelift and
GCC backends fall back to the platform default since they have no
equivalent.
Jonathan Brouwer