Set groundwork for proper const normalization
r? lcnr
Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented.
I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
Remove fragile equal-pointers-unequal tests.
Same as https://github.com/rust-lang/rust/pull/139176
---
These tests were added in #127003
These tests stop working when I change implementation details of format_args!(). These tests shouldn't rely on such implementation details.
Do these tests test anything that isn't already covered by other tests? If so, they should be expressed in a less fragile way that doesn't rely on internal details of format_args!().
cc `@GrigorenkoPV,` author of these tests.
organize and extend forbidden target feature tests
In particular this adds some loongarch tests for https://github.com/rust-lang/rust/pull/135015, Cc `@heiher`
Seems like the tests change so much git does not detect the renames; a commit-by-commit review should help.
try-job: `x86_64-gnu-llvm-20-*`
resolve: Support imports of associated types and glob imports from traits
Follow up to https://github.com/rust-lang/rust/pull/134754, part of https://github.com/rust-lang/rust/issues/134691.
This PR also closes https://github.com/rust-lang/rust/issues/138711 now.
Prohibiting `use Trait::AssocType;` at name resolution stage doesn't make sense, the name itself is perfectly resolveable.
It's a type checker's problem that the necessary generic args are not passed when the imported `AssocType` is used, so an error should be reported there.
And since we can import associated trait items now, glob imports from traits can also be allowed.
Fix the test for s390x by enabling s390x vector extension via
`target_feature(enable = "vector")`(#127506). As this is is still
gated by `#![feature(s390x_target_feature)]` we need that attribute
also.
Add regression test for #140545Closes#140545
I am not very knowledgable about the typesystem internals, so I couldn't come up with a good name for the test. But I'm happy to move it to a more appropriate place if there is one (`tests/ui/impl-trait/non-defining-uses` maybe?)
r? types (or reroll as appropriate if this is not actually a T-types issue; i'm clueless)
Emit user type annotations for free consts in pattern position
This previously wasnt done because free consts couldn't have any generic parameters that need to be preserved for borrowck. This is no longer the case with `feature(generic_const_items)`
r? fmease
Use select in projection lookup in `report_projection_error`
Using `for_each_relevant_impl` doesn't actually select the correct impl; we can use `select` here to actually get the correct impl with certainty. Follow-up to https://github.com/rust-lang/rust/pull/140278.
r? oli-obk
Rollup of 12 pull requests
Successful merges:
- #134034 (handle paren in macro expand for let-init-else expr)
- #137474 (pretty-print: Print shebang at the top of the output)
- #138872 (rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs)
- #139046 (Improve `Lifetime::suggestion`)
- #139206 (std: use the address of `errno` to identify threads in `unique_thread_exit`)
- #139608 (Clarify `async` block behaviour)
- #139847 (Delegate to inner `vec::IntoIter` from `env::ArgsOs`)
- #140159 (Avoid redundant WTF-8 checks in `PathBuf`)
- #140197 (Document breaking out of a named code block)
- #140389 (Remove `avx512dq` and `avx512vl` implication for `avx512fp16`)
- #140430 (Improve test coverage of HIR pretty printing.)
- #140507 (rustc_target: RISC-V: feature addition batch 3)
r? `@ghost`
`@rustbot` modify labels: rollup
rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs
Because RISC-V Calling Conventions note that:
> This means code targeting the `Zfinx` extension always uses the ILP32, ILP32E or LP64 integer calling-convention only ABIs as there is no dedicated hardware floating-point register file.
`{ILP32,LP64}[FD]` ABIs with hardware floating-point calling conventions are incompatible with the `Zfinx` extension.
This commit adds `"zfinx"` to the incompatible feature list to those ABIs and tests whether trying to add `"zdinx"` (that is analogous to `"zfinx"` but in double-precision) on a LP64D ABI configuration results in an error (it also tests extension implication; `Zdinx` requires `Zfinx` extension).
Links: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/v1.0/riscv-cc.adoc#named-abis>
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
handle paren in macro expand for let-init-else expr
Fixes#131655
This PR modifies the codegen logic of the macro expansion within `let-init-else` expression:
- Before: The expression `let xxx = (mac! {}) else {}` expands to `let xxx = (expanded_ast) else {}`.
- After: The same expression expands to `let xxx = expanded_ast else {}`.
An alternative solution to this issue could involve handling the source code directly when encountering unused parentheses in `let-init-else` expressions. However, this approach might be more cumbersome due to the absence of the necessary data structure.
r? `@petrochenkov`
