Stabilize `style_edition = "2024"` in-tree
This PR stabilizes the `style_edition` flag in rustfmt.
**Why am I doing this in-tree?** The beta release cut is imminent (according to forge, on January 3) and this is the most lightweight approach to getting this flag stable on nightly. It's imperative (as far as I can tell -- `@traviscross` can verify or disagree) that we stabilize the `style_edition` flag so that users can control their style edition separately from the edition.
I'm happy to move this PR to the rustfmt repo and subsequently prepare a subtree sync if someone on `@rust-lang/rustfmt` believes that we should get this landed on the rustfmt side then synced. If this is the right recourse, I'd like to note that this is still quite time-sensitive. However, I'm happy to dedicate time to get this done if necessary, since I'd really like to un-jeopardize the style edition.
Tracking:
- https://github.com/rust-lang/rust/issues/123799
stabilize const_swap
libs-api FCP passed in https://github.com/rust-lang/rust/issues/83163.
However, I only just realized that this actually involves an intrinsic. The intrinsic could be implemented entirely with existing stable const functionality, but we choose to make it a primitive to be able to detect more UB. So nominating for `@rust-lang/lang` to make sure they are aware; I leave it up to them whether they want to FCP this.
While at it I also renamed the intrinsic to make the "nonoverlapping" constraint more clear.
Fixes#83163
ci: Cleanup docker build logs in CI
Cleaning up the CI logs to make reviewing CI failures easier. This PR adds a `::group` around the docker tag hash input which is pretty large (250+ lines) and is probably not relevant for most people.
Related to #134910 , see this [comment](https://github.com/rust-lang/rust/issues/134910#issuecomment-2565612463)
Add illumos target documentation
Fixes https://github.com/rust-lang/rust/pull/130132#issuecomment-2339055221
`@jclulow` `@pfmooney` I'm adding you as requested.
The page is very barebones (as I do not know illumos well) and could use some improvements (for example in the "Cross-compilation toolchains and C code" section).
Feel free to suggest improvements (or rewrite it from scratch) if you find something.
A couple datalog/borrowck cleanups
As discussed on zulip, here's a chill one in between slightly more interesting PRs:
- I hadn't noticed there still were a couple of datalog-related modules outside of their dedicated `polonius` module (go to horn-clause jail, bonk!).
- there somehow was both a `diags` module and a `diagnostics` module.
- a couple other tiny things being renamed -- let me know what you think.
As requested I've tried to have somewhat granular commits to ease review, but the last two or three could be squashed together, since they're all related to the `diags` module (but moving its contents is less tedious to check in its own commit).
r? `@jackh726`
tests: add basic test coverage for stable `--crate-type` flag
I experimented locally with making the compiler panic if multiple crate types are passed to a single `--crate-type` flag, and it turns out not only does the compiler successfully bootstrap, only two ui tests failed:
```
failures:
[ui] tests/ui/sepcomp/sepcomp-lib.rs
[ui] tests/ui/sepcomp/sepcomp-lib-lto.rs
test result: FAILED. 4 passed; 2 failed; 18181 ignored; 0 measured; 0 filtered out; finished in 364.55ms
```
These are not specific tests for the `--crate-type` flag, only their auxiliary *happens* to use a `--crate-type` with two crate types:
```rs
//@ compile-flags: -C codegen-units=3 --crate-type=rlib,dylib -g
```
I was not able to find a specific test in run-make test suite either.
So this PR tries to add some basic test coverage for the stable `--crate-type` flag's interface (including to check that `--crate-type` accepts multiple crate types), since I imagine it might be slightly awkward if we accidentally regressed this.
r? compiler
bootstrap: Don't apply -Ztls-model=initial-exec to deps of proc-macros
Fixes#134863
1. Checks if a crate name is in a static list before applying the flag
2. Adds a tidy check that gathers transitive deps of proc macros and ensures the list is up to date
cc `@bjorn3` - the issue specifies `rustc_fluent_macro` but I assume this applies to all proc macro crates.
rustc_codegen_ssa: Buffer file writes in link_rlib
This makes this step take ~25ms on my machine (M3 Max 64GB) for Zed repo instead of ~150ms (on editor crate). Additionally it takes down the time needed for a clean cargo build of ripgrep from ~6.1s to 5.9s.
This change is mostly relevant for dev builds of crates with multiple large CGUs.
I imagine it could be quite relevant for dev scenarios on Windows, but sadly I have no way to measure that myself.
Compute liveness constraints in location-sensitive polonius
This continues the location-sensitive prototype. In this episode, we build the liveness constraints.
Reminder of the approach we're taking: we need variance data to create liveness edges in the forward/backward/both directions (respectively in the cases of covariance, contravariance, invariance) in the localized constraint graph.
This PR:
- introduces the holder for that, and for the liveness data in the correct shape: the transpose of what we're using today, "live regions per points".
- records use/drop live region variance during tracing
- records regular live region variance at the end of liveness
- records the correctly shaped live region per point matrix
- uses all of the above to compute the liveness constraints
(There's still technically one tiny part of the liveness owl left to do, but I'll leave it for a future PR: we also need to disable the NLL optimization that avoids computing liveness for locals whose types contain a region outliving a free region -- the existing constraints make it effectively live at all points; this doesn't work under polonius)
r? `@jackh726` cc `@matthewjasper`
