Make `feature(effects)` require `-Znext-solver`
Per https://github.com/rust-lang/rust/pull/120639#pullrequestreview-2144804638
I made this a hard error because otherwise it should be a lint and that seemed more complicated. Not sure if this is the best place to put the error though.
r? project-const-traits
Cleanup bootstrap check-cfg
This PR cleanup many custom `check-cfg` in bootstrap that have been accumulated over the years.
As well as updating some outdated comments.
Add a regression test for #123630Fixes#123630
compiler should not suggest nonsensical signatures, original suggestion was
```
error[E0308]: mismatched types
--> src/lib.rs:3:31
|
3 | fn select<F, I>(filter: F) -> Select<F, I> {
| ------ ^^^^^^^^^^^^ expected `Select<F, I>`, found `()`
| |
| implicitly returns `()` as its body has no tail or `return` expression
|
= note: expected struct `Select<F, I>`
found unit type `()`
error[E0282]: type annotations needed for `Select<{closure@src/lib.rs:8:22: 8:25}, I>`
--> src/lib.rs:8:9
|
8 | let lit = select(|x| match x {
| ^^^
|
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
|
8 | let lit: Select<{closure@src/lib.rs:8:22: 8:25}, I> = select(|x| match x {
| ++++++++++++++++++++++++++++++++++++++++++++
Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`.
```
coverage: Avoid getting extra unexpansion info when we don't need it
Several callers of `unexpand_into_body_span_with_visible_macro` would immediately discard the additional macro-related information, which is wasteful. We can avoid this by having them instead call a simpler method that just returns the span they care about.
This PR also moves the relevant functions out of `coverage::spans::from_mir` and into a new submodule `coverage::unexpand`, so that calling them from `coverage::mappings` is less awkward.
There should be no actual changes to coverage-instrumentation output, as demonstrated by the absence of test updates.
small correction to fmt::Pointer impl
~~The `addr` method does not require `T: Sized`, and is preferred for use over `expose_provenance`.~~
`expose_provenance` does not require `T: Sized`.
Update the LoongArch target documentation
The docs for the LoongArch targets are a bit dated since their introduction, and the prose has some room for improvement as well. Streamline a bit, referring to the neighboring targets' docs, and provide up-to-date information as much as I can come up with.
cc fellow target maintainer `@heiher` for review of target-specific bits
Replace some magic booleans in match-lowering with enums
This PR takes some boolean arguments used by the match-lowering code, and replaces them with dedicated enums that more clearly express their effect, while also making it much easier to find how each value is ultimately used.
Remove the `box_pointers` lint.
As the comment says, this lint "is mostly historical, and not particularly useful". It's not worth keeping it around.
r? ``@estebank``
Avoid cloning jump threading state when possible
The current implementation of jump threading passes most of its time cloning its state. This PR attempts to avoid such clones by special-casing the last predecessor when recursing through a terminator.
This is not optimal, but a first step while I refactor the state data structure to be sparse.
The two other commits are drive-by.
Fixes https://github.com/rust-lang/rust/issues/116721
r? `@oli-obk`
ignore `llvm::Lld` if lld is not enabled
People are having trouble ([ref. zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/MSVC.20Runtime.20mismatch.20when.20building.20LLD)) when they don't want to build `lld` for their custom distribution tarballs even with `lld = false` in their config.toml. This is because it is not controlled by `lld_enabled` flag. This change ensures that `llvm:Lld` is controlled by lld configuration.
Additionally, `lld = true` is set by default for dist profile, because we have been building it all along and this maintains that behavior.
try-job: x86_64-mingw
ast: Standardize visiting order
Order: ID, attributes, inner nodes in source order if possible, tokens, span.
Also always use exhaustive matching in visiting infra, and visit some discovered missing nodes.
Unlike https://github.com/rust-lang/rust/pull/125741 this shouldn't affect anything serious like `macro_rules` scopes.
rustdoc: use current stage if download-rustc enabled
When using download-rustc, using stage 1 rustdoc results in the wrong librustc_driver being used.
```sh
$ ./build/host/stage1/bin/rustdoc --version
./build/host/stage1/bin/rustdoc: error while loading shared libraries: librustc_driver-7ff02ed05016d515.so: cannot open shared object file: No such file or directory
```
This change fixes that by not cutting the stage if download-rustc is enabled.
Fixes for 32-bit SPARC on Linux
This PR fixes a number of issues which previously prevented `rustc` from being built
successfully for 32-bit SPARC using the `sparc-unknown-linux-gnu` triplet.
In particular, it adds linking against `libatomic` where necessary, uses portable `AtomicU64`
for `rustc_data_structures` and rewrites the spec for `sparc_unknown_linux_gnu` to use
`TargetOptions` and replaces the previously used `-mv8plus` with the more portable
`-mcpu=v9 -m32`.
To make `rustc` build successfully, support for 32-bit SPARC needs to be added to the `object`
crate as well as the `nix` crate which I will be sending out later as well.
r? nagisa
patch `rust-lld` and `ld.lld` on NixOS
When `rustc` uses its self-contained lld, we also need to patch `rust-lld` and `ld.lld`.
The `rpath` for `rust-lld` is `$ORIGIN/../../../:$ORIGIN/../lib`, so I use `--add-rpath` instead of `--set-rpath`, which should be easier to maintain.
I also changed `src/bootstrap/src/core/download.rs`, even this doesn't fix any known issues.
For the `lld-wrapper.sh` of lld, refer to: https://github.com/rust-lang/rustc-dev-guide/pull/1999.
Remove more `PtrToPtr` casts in GVN
This addresses two things I noticed in MIR:
1. `NonNull::<T>::eq` does `(a as *mut T) == (b as *mut T)`, but it could just compare the `*const T`s, so this removes `PtrToPtr` casts that are on both sides of a pointer comparison, so long as they're not fat-to-thin casts.
2. `NonNull::<T>::addr` does `transmute::<_, usize>(p as *const ())`, but so long as `T: Thin` that cast doesn't do anything, and thus we can directly transmute the `*const T` instead.
r? mir-opt
Various refactorings to rustc_interface
This should make it easier to move the driver interface away from queries in the future. Many custom drivers call queries like `queries.global_ctxt()` before they are supposed to be called, breaking some things like certain `--print` and `-Zunpretty` options, `-Zparse-only` and emitting the dep info at the wrong point in time. They are also not actually necessary at all. Passing around the query output manually would avoid recomputation too and would be just as easy. Removing driver queries would also reduce the amount of global mutable state of the compiler. I'm not removing driver queries in this PR to avoid breaking the aforementioned custom drivers.
transmute size check: properly account for alignment
Fixes another place where ZST alignment was ignored when checking whether something is a newtype. I wonder how many more of these there are...
Fixes https://github.com/rust-lang/rust/issues/101084
Allow constraining opaque types during various unsizing casts
allows unsizing of tuples, arrays and Adts to constraint opaque types in their generic parameters to concrete types on either side of the unsizing cast.
Also allows constraining opaque types during trait object casts that only differ in auto traits or lifetimes.
cc #116652
Save 2 pointers in `TerminatorKind` (96 → 80 bytes)
These things don't need to be `Vec`s; boxed slices are enough.
The frequent one here is call arguments, but MIR building knows the number of arguments from the THIR, so the collect is always getting the allocation right in the first place, and thus this shouldn't ever add the shrink-in-place overhead.
std: refactor the TLS implementation
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
`@rustbot` label +A-thread-locals
Remove confusing `use_polonius` flag and do less cloning
The `use_polonius` flag is both redundant and confusing since every function it's propagated to also checks if `all_facts` is `Some`, the true test of whether to generate Polonius facts for Polonius or for external consumers. This PR makes that path clearer by simply doing away with the argument and handling the logic in precisely two places: where facts are populated (check for `Some`), and where `all_facts` are initialised. It also delays some statements until after that check to avoid the miniscule performance penalty of executing them when Polonius is disabled.
This also addresses `@lqd's` concern in #125652 by reducing the size of what is cloned out of Polonius facts to just the facts being added, as opposed to the entire vector of potential inputs, and added descriptive comments.
*Reviewer note*: the comments in `add_extra_drop_facts` should be inspected by a reviewer, in particular the one on [L#259](https://github.com/rust-lang/rust/compare/master...amandasystems:you-dropped-this-again?expand=1#diff-aa727290e6670264df2face84f012897878e11a70e9c8b156543cfcd9619bac3R259) in this PR, which should be trivial for someone with the right background knowledge to address.
I also included some lints I found on the way there that I couldn't help myself from addressing.
fix: use ItemInNs::Macros to convert ModuleItem to ItemInNs
fix#17425.
When converting `PathResolution` to `ItemInNs`, we should convert `ModuleDef::Macro` to `ItemInNs::Macros` to ensure that it can be found in `DefMap`.
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental
work towards https://github.com/rust-lang/rust/issues/90317
Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.
r? `@cjgillot`
