It sees them as regular impls; the details are abstracted. It's beautiful for the IDE layer, and less beautiful for `hir`, so this is a big change.
Some small differences still exist:
- We show builtin derives impl (to the IDE layer) as if they have had no generic parameters. It is possible to show the parameters, but that means also having to handle fake impls in `TypeParam` etc., and the benefit is questionable.
- Getting the fn *def* type of a method of a builtin derive impl is not supported, as there is no real `FunctionId`, therefore no `CallableDefId`. The trait method is returned instead. Note: getting the fn *ptr* type of the method is supported well.
- Builtin derive impls and their methods do not fully support `HasSource`, because, well, they have no source (at least, not in the form of `ast::Impl` and `ast::Fn`). To support them, we use the derive's `TextRange` where possible, and the trait method's source when not.
It's important to note that the def map still records the `MacroCallId`. I have doubts over this, as this means it's very easy to create the queries we don't want to create, but it does make things more convenient. In particular, a nicety of this setup is that even "Expand macro recursively" works (it creates the macro input/output query, but given that they will only be created when the user invokes the command, that does not seem to be a problem).
And remove it when needed, the opposite of what was previously, where we stored without a tuple and tupled for the solver (because it requires that).
Because this is what rustc does, and generally, the closer we follow rustc, the easier our lives become.
The weird name `signature_unclosure()` also comes from rustc.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150141 (Misc cleanups from reading some borrowck code)
- rust-lang/rust#150297 (Fix compile issue in Vita libstd)
- rust-lang/rust#150341 (Fix some divergences with the cg_clif subtree)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix some divergences with the cg_clif subtree
For some reason git-subtree incorrectly synced those changes.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Fix compile issue in Vita libstd
Unfortunately it looks like the Vita libc does not support
the "utimensat" function, which is needed for setting file times.
To fix the build, this commit marks Vita as unsupported for the
function that sets the file times.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150311 (Avoid using env::temp when linking a binary)
- rust-lang/rust#150336 (Disable f16 on LoongArch for LLVM < 21)
- rust-lang/rust#150338 (Include rustc version in ICE messages)
r? `@ghost`
`@rustbot` modify labels: rollup
Include rustc version in ICE messages
Rather than only including them in the ICE file. Not every user includes the ICE file in their bug reports, nor do they always list the rustc version.
Disable f16 on LoongArch for LLVM < 21
The `f16` type works on the LoongArch target starting from LLVM 21. However, the current minimum supported external LLVM version is 20, so `f16` must not be enabled on LoongArch for LLVM version < 21.
Avoid using env::temp when linking a binary
This keeps all build artefacts (even temporary ones) within the build directory.
Fixesrust-lang/rust#139963
The `f16` type works on the LoongArch target starting from LLVM 21.
However, the current minimum supported external LLVM version is 20,
so `f16` must not be enabled on LoongArch for LLVM version < 21.
mir_build: Classify `TestableCase::Constant` into multiple sub-kinds
In match lowering, when choosing a test for a `TestableCase::Constant`, there is some ad-hoc logic for inspecting the pattern type and deciding what kind of test is suitable. There is also some very similar logic later, when partitioning cases into buckets based on the chosen test.
Instead of having that ad-hoc logic in multiple places, I think it's better to perform an up-front classification when lowering `thir::PatKind::Constant` to `TestableCase::Constant`, and then have the later steps simply match on an enum variant.
There should be no change to the resulting built MIR.
(I will note that the logic/invariants involved are a bit unclear, so there is a risk of accidental minor differences.)
Correct terminology in Clone
I think the current wording around Clone here is confusing:
- "Rust does not allow you to reimplement `Copy`" - reimplement isn't a piece of Rust terminology, but as written it sounds like you can't write `impl Copy for X`, which you can.
- "you may reimplement `Clone`" - again reimplement isn't really a thing that you do to a trait, the distinction is between manually implementing and deriving.
- "you can automatically make anything `Copy` be `Clone` as well" - you don't have a choice about it, so it doesn't really make sense to say you "can ... make" this happen.
Remap both absolute and relative paths when building `rustc` and `std`
Turns out [#150110](https://github.com/rust-lang/rust/issues/150110) didn't work as expected, because when the standard library sources are present, we [helpfully un-remap the paths](https://github.com/rust-lang/rust/blob/e951f470d76febcc6f0a5b409c509eb77450a336/compiler/rustc_metadata/src/rmeta/decoder.rs#L1656-L1702) to the local directory of the user, including when we are building the compiler and standard library it-self (duh!), and since those paths are absolute (not relative), our purely relative remapping didn't pick them up.
This behavior wasn't a issue before because the un-remap logic immediately tries to remap them again, and since we had the absolute remapping we would just remap them to the the same thing.
To fix that issue I've adjusted our remapping to remap both the absolute and relative paths when building `rustc` and `std`, as well as added a run-make to make sure we don't regress it again (with a new `needs-std-remap-debuginfo` directive).
r? `@jieyouxu`
Yotam Ofek