Split implied and super predicate queries, then allow elaborator to filter only supertraits
Split the `super_predicates_of` query into a new `implied_predicates_of` query. The former now only returns the *real* supertraits of a trait alias, and the latter now returns the implied predicates (which include all of the `where` clauses of the trait alias). The behavior of these queries is identical for regular traits.
Now that the two queries are split, we can add a new filter method to the elaborator, `filter_only_self()`, which can be used in instances that we need only the *supertrait* predicates, such as during the elaboration used in closure signature deduction. This toggles the usage of `super_predicates_of` instead of `implied_predicates_of` during elaboration of a trait predicate.
This supersedes #104745, and fixes the four independent bugs identified in that PR.
Fixes#104719Fixes#106238Fixes#110023Fixes#109514
r? types
- require `TypeErrCtxt` to always result in an error
- move `resolve_regions_and_report_errors` to the `ObligationCtxt`
- merge `process_registered_region_obligations` into `resolve_regions`
Support safe transmute in new solver
Basically copies the same implementation as the old solver, but instead of looking for param types, we look for type or const placeholders.
Initial support for loongarch64-unknown-linux-gnu
Hi, We hope to add a new port in rust for LoongArch.
LoongArch intro
LoongArch is a RISC style ISA which is independently designed by Loongson
Technology in China. It is divided into two versions, the 32-bit version (LA32)
and the 64-bit version (LA64). LA64 applications have application-level
backward binary compatibility with LA32 applications. LoongArch is composed of
a basic part (Loongson Base) and an expanded part. The expansion part includes
Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD
EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX).
Currently the LA464 processor core supports LoongArch ISA and the Loongson
3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit
high-performance processor core. It can be used as a single core for high-end
embedded and desktop applications, or as a basic processor core to form an
on-chip multi-core system for server and high-performance machine applications.
Documentations:
ISA:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
ABI:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
More docs can be found at:
https://loongson.github.io/LoongArch-Documentation/README-EN.html
Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally.
I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
It has a single call site, and the code is clearer with all region kinds
handled in one function, instead of splitting the handling across two
functions.
The commit also changes `DescriptionCtx::new` to use a more declarative
style, instead of creating a default `DescriptionCtx` and modifying it,
which I find easier to read.
Migrate most of `rustc_builtin_macros` to diagnostic impls
cc #100717
This is a couple of days work, but I decided to stop for now before the PR becomes too big. There's around 50 unresolved failures when `rustc::untranslatable_diagnostic` is denied, which I'll finish addressing once this PR goes thtough
A couple of outputs have changed, but in all instances I think the changes are an improvement/are more consistent with other diagnostics (although I'm happy to revert any which seem worse)
rustc_metadata: Filter encoded data more aggressively using `DefKind`
I focused on data that contains spans, because spans are expensive to encode/decode/hash, but also touched `should_encode_visibility` too.
One incorrect use of impl visibility in diagnostics is also replaced with trait visibility.
Rollup of 8 pull requests
Successful merges:
- #109527 (Set up standard library path substitution in rust-gdb and gdbgui)
- #109752 (Stall auto trait assembly in new solver for int/float vars)
- #109860 (Add support for RISC-V relax target feature)
- #109923 (Update `error [E0449]: unnecessary visibility qualifier` to be more clear)
- #110070 (The `wrapping_neg` example for unsigned types shouldn't use `i8`)
- #110146 (fix(doc): do not parse inline when output is json for external crate)
- #110147 (Add regression test for #104916)
- #110149 (Update books)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
There's a bad pattern matching confusion present in this function.
`_anon` gets assigned to, and then `_anon` is used as an unbound
variable in the pattern, which is unrelated to the first `_anon`.
If the `_anon` didn't start with `_` the compiler would give warnings.
This was introduced in #104239.
I have rewritten the function to remove the confusion and preserve the
existing behaviour. This seems safest, because the original intent is
not clear.
Update `error [E0449]: unnecessary visibility qualifier` to be more clear
This updates the error message `error[E0449]: unnecessary visibility qualifier` by clearly indicating that visibility qualifiers already inherit their visibility from a parent item. The error message previously implied that the qualifiers were permitted, which is not the case anymore.
Resolves#109822.
Add support for RISC-V relax target feature
This adds `relax` as an allowed RISC-V target feature. The relax feature in LLVM enables [linker relaxation](https://www.sifive.com/blog/all-aboard-part-3-linker-relaxation-in-riscv-toolchain), an optimization specific to RISC-V that allows global variable accesses to be resolved by the linker by using the global pointer (`gp`) register (rather than constructing the addresses from scratch for each access). Enabling `relax` will cause LLVM to emit relocations in the object file that support this. The feature can be enabled in rustc with `-C target-feature=+relax`.
Currently this feature is disabled by default, but maybe it should be enabled by default since it is an easy performance improvement (but requires the `gp` register to be set up properly). GCC/Clang enable this feature by default (for both hosted/bare-metal targets), and include the `-mno-relax` flag to disable it (see [here](466d554dca/clang/lib/Driver/ToolChains/Arch/RISCV.cpp (L145)) for the code that enables it in Clang). I think it would make sense to enable by default, at least for all hosted targets since the `gp` register should be automatically set up by the runtime. For bare-metal targets, `gp` must be set up manually, so it is probably best to leave off by default to avoid breaking existing applications that do not set up `gp`. Leaving it disabled by default for all targets is also reasonable though.
Let me know your thoughts. Thanks!
Fixes#109426.
We store argument indexes on VarDebugInfo. Unlike the previous method of
relying on the variable index to know whether a variable is an argument,
this survives MIR inlining.
We also no longer check if var.source_info.scope is the outermost scope.
When a function gets inlined, the arguments to the inner function will
no longer be in the outermost scope. What we care about though is
whether they were in the outermost scope prior to inlining, which we
know by whether we assigned an argument index.
rustc_middle: Document which exactly `DefId`s don't have `DefKind`s
I don't currently have time to investigate when and how to create these missing HIR nodes, but if someone else could do that it would be great.
Add suggestion to remove `derive()` if invoked macro is non-derive
Adds to the existing `expected derive macro, found {}` error message:
```
help: remove the surrounding "derive()":
--> $DIR/macro-path-prelude-fail-4.rs:1:3
|
LL | #[derive(inline)]
| ^^^^^^^ ^
```
This suggestion will either fix the issue, in the case that the macro was valid, or provide a better error message if not
Not ready for merge yet, as the highlighted span is only valid for trivial formatting. Is there a nice way to get the parent span of the macro path within `smart_resolve_macro_path`?
Closes#109589
