Do not use effective_visibilities query for Adt types of a local trait while proving a where-clause
Partially fixrust-lang/rust#145611, but we should do something make cycle in this situation ICE.
Instead of using a query, call `&tcx.resolutions(()).effective_visibilities`.
r? `````@lcnr`````
cc `````@compiler-errors`````
Unconditionally-const supertraits are considered not dyn compatible
Let's save some space in the design of const traits by making `dyn Trait` where `trait Trait: const Super` not dyn compatible.
Such a trait cannot satisfy `dyn Trait: Trait`; we could in the future make this dyn compatible but *NOT* implement `Trait`, but that's a bit weird and seems like it needs to be independently justified moving forward.
Fixes https://github.com/rust-lang/rust/issues/145198
r? fee1-dead
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
stdlib: Replace typedef -> type alias in doc comment
'typedef' is jargon from C and C++.
Since the Rust reference uses the term [type alias](https://doc.rust-lang.org/reference/items/type-aliases.html),
this patch changes the doc comment in io/error.rs
to also use 'type alias'.
std_detect: RISC-V: implement implication to "C"
Just like we implemented relatively complex rules to imply other extensions **from** "C" (and some others), this commit implements implication **to** the "C" extension from others, complying the following text in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations (*not* in this implementation) can (currently) imply the "C" extension.
Note: this is a `std_detect` change and not main target feature handling.
Shorten some dependency chains in the compiler
(I recommend reviewing this commit by commit.)
One of the long dependency chains in the compiler is:
- Many things depend on `rustc_errors`.
- `rustc_errors` depended on many things prior to this PR, including `rustc_target`, `rustc_type_ir`, `rustc_hir`, and `rustc_lint_defs`.
- `rustc_lint_defs` depended on `rustc_hir` prior to this PR.
- `rustc_hir` depends on `rustc_target`.
- `rustc_target` is large and takes a while.
This PR breaks that chain, through a few steps:
- The `IntoDiagArgs` trait, from `rustc_errors`, moves earlier in the dependency chain. This allows `rustc_errors` to stop depending on a pile of crates just to implement `IntoDiagArgs` for their types.
- Split `rustc_hir_id` out of `rustc_hir`, so crates that just need `HirId` and similar don't depend on all of `rust_hir` (and thus `rustc_target`).
- Make `rustc_lint_defs` stop depending on `rustc_hir`.
fix(debuginfo): handle false positives in overflow check
Fixesrust-lang/rust#144636.
Duplicate wrappers and normal recursive types can lead to false positives.
```rust
struct Recursive {
a: Box<Box<Recursive>>,
}
```
The ADT stack can be:
- `Box<Recursive>`
- `Recursive`
- `Box<Box<Recursive>>` (`Box` now detected as expanding)
We can filter them out by tracing the generic arg back through the stack, as true expanding recursive types must have their expanding arg used as generic arg throughout.
r? ````@wesleywiser````
Add new `--test-codegen-backend` bootstrap option
This new bootstrap command line flag allows to do:
```shell
./x.py test tests/ui/intrinsics/panic-uninitialized-zeroed.rs --stage 1 -j8 --test-codegen-backend gcc
```
This is the last step before running it into the CI.
Supersedes rust-lang/rust#144687.
r? ``````@Kobzol``````
Defer tail call ret ty equality to check_tail_calls
Fixesrust-lang/rust#144892.
Currently the tail call signature check assumes that return types have been accounted for. However, this is not complete for several reasons.
Firstly, we were using subtyping instead of equality in the HIR typeck code:
e1b9081e69/compiler/rustc_hir_typeck/src/expr.rs (L1096)
We could fix this, but it doesn't really do much for us anyways since HIR typeck doesn't care about regions.
That means, secondly, we'd need to fix the terminator type check in MIR typeck to account for variances, since tail call terminators need to relate their arguments invariantly to account for the "signature must be equal" rule. This seems annoying.
All of this seems like a lot of work, and we already are *manually* checking argument equality. Let's just extend the `check_tail_calls` to account for mismatches in return types anyways.
r? ``````@WaffleLapkin``````
support non-defining uses of opaques in borrowck
Reimplements the first part of rust-lang/rust#139587, but limited to only the new solver. To do so I also entirely rewrite the way we handle opaque types in borrowck even on stable. This should not impact behavior however.
We now support revealing uses during MIR borrowck with the new solver:
```rust
fn foo<'a>(x: &'a u32) -> impl Sized + use<'a> {
let local = 1;
foo::<'_>(&local);
x
}
```
### How do opaque types work right now
Whenever we use an opaque type during type checking, we remember this use in the `opaque_type_storage` of the `InferCtxt`.
Right now, we collect all *member constraints* at the end of MIR type check by looking at all uses from the `opaque_type_storage`. We then apply these constraints while computing the region values for each SCC. This does not add actual region constraints but directly updates the final region values.
This means we need to manually handle any constraints from member constraints for diagnostics. We do this by separately tracking `applied_member_constraints` in the `RegionInferenceContext`.
After we've finished computing the region values, it is now immutable and we check whether all member constraints hold. If not, we error.
We now map the hidden types of our defining uses to the defining scope. This assumes that all member constraints apply. To handle non-member regions, we simply map any region in the hidden type we fail to map to a choice region to `'erased` b1b26b834d/compiler/rustc_borrowck/src/region_infer/opaque_types.rs (L126-L132)
### How do we handle opaque types with this PR
MIR type check still works the same by populating the `opaque_type_storage` whenever we use an opaque type.
We now have a new step `fn handle_opaque_type_uses` which happens between MIR type check and `compute_regions`.
This step looks at all opaque type uses in the storage and first checks whether they are defining: are the arguments of the `opaque_type_key` unique region parameters. *With the new solver we silently ignore any *non-defining* uses here. The old solver emits an errors.*
`fn compute_concrete_opaque_types`: We then collect all member constraints for the defining uses and apply them just like we did before. However, we do it on a temporary region graph which is only used while computing the concrete opaque types. We then use this region graph to compute the concrete type which we then store in the `root_cx`.
`fn apply_computed_concrete_opaque_types`: Now that we know the final concrete type of each opaque type and have mapped them to the definition of the opaque. We iterate over all opaque type uses and equate their hidden type with the instantiated final concrete type. This is the step which actually mutates the region graph.
The actual region checking can now entirely ignores opaque types (outside of the `ConstraintCategory` from checking the opaque type uses).
### Diagnostics issue (chill)
Because we now simply use type equality to "apply member constraints" we get ordinary `OutlivesConstraint`s, even if the regions were already related to another.
This is generally not an issue, expect that it can *hide* the actual region constraints which resulted in the final value of the opaque. The constraints we get from checking against the final opaque type definition relies on constraints we used to compute that definition.
I mostly handle this by updating `find_constraint_path_between_regions` to first ignore member constraints in its search and only if that does not find a path, retry while considering member constraints.
### Diagnostics issue (not chill)
A separate issue is that `find_constraint_paths_between_regions` currently looks up member constraints by their **scc**, not by region value:
2c1ac85679/compiler/rustc_borrowck/src/region_infer/mod.rs (L1768-L1775)
This means that in the `borrowck-4` test, the resulting constraint path is currently
```
('?2: '?5) due to Single(bb0[5]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?5: '?3) due to Single(bb0[6]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?3: '?0) due to All(src/main.rs:15:5: 15:6 (#0)) (None) (OpaqueType) (ConstraintSccIndex(1): ConstraintSccIndex(1))
```
Here `'?3` is equal to `'?4`, but the reason why it's in the opaque is that it's related to `'?4`. With my PR this will be correctly tracked so we end up with
```
('?2: '?5) due to Single(bb0[5]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?5: '?3) due to Single(bb0[6]) (None) (Boring) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?3: '?4) due to Single(bb0[6]) (None) (Assignment) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
('?4: '?0) due to All(src/main.rs:15:5: 15:6 (#0)) (None) (OpaqueType) (ConstraintSccIndex(1): ConstraintSccIndex(1)),
```
This additional `Assignment` step then worsens the error message as we stop talking about the fact that the closures is returned from the function. Fixing this is hard. I've looked into this and it's making me sad :< Properly handling this requires some deeper changes to MIR borrowck diagnostics and that seems like too much for this PR. Given that this only impacts a single test, it seems acceptable to me.
r? `@ghost`
Tell LLVM about read-only captures
`&Freeze` parameters are not only `readonly` within the function, but any captures of the pointer can also only be used for reads. This can now be encoded using the `captures(address, read_provenance)` attribute.
`rustc_lint_defs` uses `rustc_hir` solely for the `Namespace` type,
which it only needs the static description from. Use the static
description directly, to eliminate the dependency on `rustc_hir`.
This reduces a long dependency chain:
- Many things depend on `rustc_errors`
- `rustc_errors` depends on `rustc_lint_defs`
- `rustc_lint_defs` depended on `rustc_hir` prior to this commit
- `rustc_hir` depends on `rustc_target`
Some crates depend on `rustc_hir` but only want `HirId` and similar id
types. `rustc_hir` is a heavy dependency, since it pulls in
`rustc_target`. Split these types out into their own crate
`rustc_hir_id`.
This allows `rustc_errors` to drop its direct dependency on `rustc_hir`.
(`rustc_errors` still depends on `rustc_hir` indirectly through
`rustc_lint_defs`; a subsequent commit will fix that.)
`rustc_errors` depends on numerous crates, solely to implement its
`IntoDiagArg` trait on types from those crates. Many crates depend on
`rustc_errors`, and it's on the critical path.
We can't swap things around to make all of those crates depend on
`rustc_errors` instead, because `rustc_errors` would end up in
dependency cycles.
Instead, move `IntoDiagArg` into `rustc_error_messages`, which has far
fewer dependencies, and then have most of these crates depend on
`rustc_error_messages`.
This allows `rustc_errors` to drop dependencies on several crates,
including the large `rustc_target`.
(This doesn't fully reduce dependency chains yet, as `rustc_errors`
still depends on `rustc_hir` which depends on `rustc_target`. That will
get fixed in a subsequent commit.)
The capture of i in assert_ne!() is now known read-only, which
enables early SROA. Block this by passing i to println, where
we currently cannot recognize this.
`&Freeze` parameters are not only `readonly` within the function,
but any captures of the pointer can also only be used for reads.
This can now be encoded using the `captures(address, read_provenance)`
attribute.
Fix rustc uplifting (take two)
The rustc uplifting logic is really annoying.. https://github.com/rust-lang/rust/pull/145557 was not enough to fix it.
Consider https://github.com/rust-lang/rust/issues/145534#issuecomment-3201868888: in this situation, we do a stage3 build of a cross-compiled rustc (it happens because we run `x test --stage 2`, which mistakenly builds a stage3 rustc, but it doesn't matter what casuses it, what matters is that the stage3 build isn't working).
Currently, a stage3 cross-compiled build of rustc works like this:
1) stage0 (host) -> stage1 (host)
2) stage1 (host) -> stage2 (host)
3) stage2 (host) -> stage3 (target)
The problem is that in the uplifting logic, I assumed that we will have a stage2 (target) rustc available, which we can uplift. And that would indeed be an ideal solution. But currently, we will actually build a stage2 (*host*) rustc, and only then start the cross-compilation. So the uplifting is broken.
I spend a couple of hours trying to fix this, and do the uplifting "from the other direction", so that already when we assemble a stage3 rustc, we notice that an uplift should happen, and we only build stage1 (host) rustc, which also helps avoid one needless rustc build. However, this was relatively complicated and would require larger changes that I was not confident landing at this time.
So instead I decided to do a much simpler fix, and just disable rustc uplifting when cross-compiling. Since we currently do the `stage2 (host) -> stage3 (target)` step, it should not actually affect stage3 cross-compiled builds in any way (I hope..), and should only affect stage4+ builds, about which I don't really care (the only change there should be more rustc builds). For normal builds, the stage2 host rustc should (hopefully) always be present, so we shouldn't run into this issue.
Eventually, I would like to remove rustc uplifting completely. However, `x test --stage 2` on CI still currently builds a stage3 rustc for some reason, and if we removed uplifting completely, even for non-cross-compiled builds, that would cause an additional rustc build, and that's not great. So for now let's just allow uplifting for non-cross-compiled builds.
Fixesrust-lang/rust#145534.
r? `@jieyouxu`
