exhaustiveness: Rework constructor splitting
`SplitWildcard` was pretty opaque. I replaced it with a more legible abstraction: `ConstructorSet` represents the set of constructors for patterns of a given type. This clarifies responsibilities: `ConstructorSet` handles one clear task, and diagnostic-related shenanigans can be done separately.
I'm quite excited, I had has this in mind for years but could never quite introduce it. This opens up possibilities, including type-specific optimisations (like using a `FxHashSet` to collect enum variants, which had been [hackily attempted some years ago](https://github.com/rust-lang/rust/pull/76918)), my one-pass rewrite (https://github.com/rust-lang/rust/pull/116042), and future librarification.
Copy 1-element arrays as scalars, not vectors
For `[T; 1]` it's silly to copy as `<1 x T>` when we can just copy as `T`.
Inspired by https://github.com/rust-lang/rust/issues/101210#issuecomment-1732470941, which pointed out that `Option<[u8; 1]>` was codegenning worse than `Option<u8>`.
(I'm not sure *why* LLVM doesn't optimize out `<1 x u8>`, but might as well just not emit it in the first place in this codepath.)
---
I think I bit off too much in #116479; let me try just the scalar case first.
r? `@ghost`
Fix mips platform support entries.
The table entries for these MIPS entries were broken because they had the wrong number of columns (from #116503). Additionally, there was a conflict with #115238, which made the same change (but on different lines, so git didn't complain).
coverage: Clarify loop-edge detection and graph traversal
This is a collection of improvements to two semi-related pieces of code:
- The code in `counters` that detects which graph edges don't exit a loop, and would therefore be good candidates to have their coverage computed as an expression rather than having a physical counter.
- The code in `graph` that traverses the coverage BCB graph in a particular order, and tracks loops and loop edges along the way (which is relevant to the above).
I was originally only planning to make the `graph` changes, but there was going to be a lot of indentation churn in `counters` anyway, and once I started looking I noticed a lot of opportunities for simplification.
---
`@rustbot` label +A-code-coverage
Handle several `#[diagnostic::on_unimplemented]` attributes correctly
This PR fixes an issues where rustc would ignore subsequent `#[diagnostic::on_unimplemented]` attributes. The [corresponding RFC](https://rust-lang.github.io/rfcs/3368-diagnostic-attribute-namespace.html) specifies that the first matching instance of each option is used. Invalid attributes are linted and otherwise ignored.
Having to keep passing in a graph reference was a holdover from when the graph
was partly mutated during traversal. As of #114354 that is no longer necessary,
so we can simplify the traversal code by storing a graph reference as a field
in `TraverseCoverageGraphWithLoops`.
The previous code was storing the worklist in a vector, and then selectively
adding items to the start or end of the vector. That's a perfect use-case for a
double-ended queue.
This change also reveals that the existing code was a bit confused about which
end of the worklist is the front or back. For now, items are always removed
from the front of the queue (instead of the back), and code that adds items to
the queue has been flipped, to preserve the existing behaviour.
Show enum discriminant if a compatible repr is used
Follow-up of #116142.
It was mentioned in the [team meeting](https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.2002-10-2023/near/394504024) that an enum with a `repr` should also get its discriminants displayed. Forgot to implement it in #116142...
It also allowed to uncover a bug: i was not providing the correct `DefId` in case it was a type alias to `render_enum_fields`. It's also fixed in this PR.
r? `@fmease`
Fix duplicate note on internal feature gates with associated issues
Fixes#116293
Note sure if I should add tests because the issue occurs only for feature gates having associated issues and that set of feature gates will change unpredictably leading to an unnecessary churn in tests.
Use structured suggestion for #113174
When encountering a for loop that is rejected by the borrow checker because it is being advanced within its body, provide a structured suggestion for `while let Some(pat) = iter.next()`.
The BuiltinInternalFeatures gate already has a struct level #[note]
attribute. The additional note field in it caused a duplicate to be
displayed when it was set to Some(...) which happened when the
feature had an associated issue
Remove unnecessary tmp variable in default_read_exact
This `tmp` variable has existed since the original implementation (added in ff81920f03), but it's not necessary (maybe non-lexical lifetimes helped?).
It's common to read std source code to understand how things actually work, and this tripped me up on my first read.
Pass rustc shim flags using environment variable
This PR implements a generalized way of passing of host flags to the `rustc` shim in bootstrap, as proposed [here](https://github.com/rust-lang/rust/pull/116278#discussion_r1346979960).
I tried to implement the bootstrap side using `OsString`, but then I realized that the shim code was using `env::var` before anyway, instead of `env::var_os`, so I just settled on a `String`. The shim side is still general and uses `env::vars_os` now.
I'm not sure if we actually need to do something with the `rustdoc` shim. It *seems* to me that the env. vars passed to it (`RUSTDOC_LINKER`) and (`RUSTDOC_LLD_NO_THREADS`) could just be passed to cargo directly (or rather, the commands that they invoke in the shim could be passed directly). I'm not sure why are they set by the shim.
r? `@onur-ozkan`
CC `@petrochenkov`
This PR fixes an issues where rustc would ignore subsequent
`#[diagnostic::on_unimplemented]` attributes. The [corresponding
RFC](https://rust-lang.github.io/rfcs/3368-diagnostic-attribute-namespace.html)
specifies that the first matching instance of each option is used.
Invalid attributes are linted and otherwise ignored.
Rollup of 5 pull requests
Successful merges:
- #116219 (Relate alias ty with variance)
- #116315 (Do not check for impossible predicates in const-prop lint.)
- #116436 (Structurally normalize for closure)
- #116597 (Prevent showing methods from blanket impls of not available foreign traits to show up in the search results)
- #116627 (small cleanup)
r? `@ghost`
`@rustbot` modify labels: rollup
When encountering a for loop that is rejected by the borrow checker
because it is being advanced within its body, provide a structured
suggestion for `while let Some(pat) = iter.next()`.
Prevent showing methods from blanket impls of not available foreign traits to show up in the search results
Fixes https://github.com/rust-lang/rust/issues/115480.
In the case that the blanket impl trait is not available in the current crate, we prevent adding its methods in the search index.
Now how I found how to fix the issue: the `equivalent` method is not generated in the documentation pages but was still added to the search index. To render impls, we iterate over `cache.impls` so I took a look at how this was generated. Inside `formats/cache.rs`, we have `CacheBuilder::populate` where we push impls into `impls` but with this condition:
```rust
if cx.cache.traits.contains_key(&trait_did) {
```
I re-used this condition in `CacheBuilder::fold_item` to prevent this method from being added in `cache.search_index` or `cache.orphan_impl_items`.
PS: If you want to double-check if the added test works, just comment the code I added in `cache.rs` and it should fail.
r? ``@notriddle``
Do not check for impossible predicates in const-prop lint.
The enclosing query already checks for them, and replaces the body with a single `unreachable` if they are indeed impossible.
Relate alias ty with variance
In the new solver, turns out that the subst-relate branch of the alias-relate predicate was relating args invariantly even for opaques, which have variance 💀.
This change is a bit more invasive, but I'd rather not special-case it [here](aeaa5c30e5/compiler/rustc_trait_selection/src/solve/alias_relate.rs (L171-L190)) and then have it break elsewhere. I'm doing a perf run to see if the extra call to `def_kind` is that expensive, if it is, I'll reconsider.
r? ``@lcnr``
Compute NLL loan scopes using the polonius model
For a *location-insensitive* analysis (that is, without expressiveness improvements for users yet), this PR implements loans going out of scope using reachability and liveness, rather than checking if the issuing region's values contain a given CFG point. This is equivalent to NLL scopes and computes the same data.
r? `@matthewjasper`
A couple of notes:
- there are some assumptions about SCC representatives, placeholders, free regions, and member constraints that I believe hold, and they're documented in the code
- this passes all the UI tests with `-Zpolonius=next` -- the perf is [not terrible](https://github.com/rust-lang/rust/pull/112432#issuecomment-1749685862) and there are a bunch of ways to improve it in the future.
- there's a fixme left, hopefully Matthew you know a clean way to get the information it mentions.
Implement `-Clink-self-contained=-linker` opt out
This implements the `-Clink-self-contained` opt out necessary to switch to lld by changing rustc's defaults instead of cargo's.
Components that are enabled and disabled on the CLI are recorded, for the purpose of being merged with the ones which the target spec will declare (I'll open another PR for that tomorrow, for easier review).
For MCP510, we now check whether using the self-contained linker is disabled on the CLI. Right now it would only be sensible to with `-Zgcc-ld=lld` (and I'll add some checks that we don't both enable and disable a component on the CLI in a future PR), but the goal is to simplify adding the check of the target's enabled components here in the follow-up PRs.
r? `@petrochenkov`
Fix overflow checking in range patterns
When a range pattern contains an overflowing literal, if we're not careful we might not notice the overflow and use the wrapped value. This makes for confusing error messages because linting against overflowing literals is only done in a later pass. So when a range is invalid we check for overflows to provide a better error.
This check didn't use to handle negative types; this PR fixes that. First commit adds tests, second cleans up without changing behavior, third does the fix.
EDIT: while I was at it, I fixed a small annoyance about the span of the overflow lint on negated literals.
Fixes https://github.com/rust-lang/rust/issues/94239
