Fix x.py install not working with relative prefix
The code powering `./x.py install` did not handle relative paths well: the installation script is executed inside a temporary directory, so all the relative paths specified in `config.toml` and in the `DESTDIR` environment variable were relative to that temporary directory. The original code fixed the problem for `config.toml` paths by canonicalizing the prefix, but breaking `DESTDIR`. https://github.com/rust-lang/rust/pull/80240 fixed the `DESTDIR` problem, but also regressed `config.toml` paths (#80683).
This PR refactors the installation code to generate paths that *in my understanding* are correct, adding comments in the meantime to explain what each step does. There was no documentation on why choices were made before, so my understanding could actually be wrong.
Regardless, executed `./x.py install` with various combinations of `config.toml` and `DESTDIR` paths, and everything seems to work according to my understanding. Still, I'd love if `@vext01` and `@yshui` could test these changes.
r? `@Mark-Simulacrum`
`@rustbot` modify labels: beta-nominated T-infra
Optimize away some path lookups in the generic `fs::copy` implementation
This also eliminates a use of a `Path` convenience function, in support
of #80741, refactoring `std::path` to focus on pure data structures and
algorithms.
Make target-cpu=native detect individual features
This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for.
This should resolve issues with miscompilations on e.g. "Haswell" Pentiums and Celerons that lack support for AVX, and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633).
Fixes#54688Fixes#48464Fixes#38218
Access query (DepKind) metadata through fields
This refactors the access to query definition metadata (attributes such as eval always, anon, has_params) and loading/forcing functions to generate a number of structs, instead of matching on the DepKind enum. This makes access to the fields cheaper to compile. Using a struct means that finding the metadata for a given query is just an offset away; previously the match may have been compiled to a jump table but likely not completely inlined as we expect here.
A previous attempt explored a similar strategy, but using trait objects in #78314 that proved less effective, likely due to higher overheads due to forcing dynamic calls and poorer cache utilization (all metadata is fairly densely packed with this PR).
This adjusts the `rustdoc` trait impl collection path to preserve `Deref` impls
from other crates. This adds a first pass to map all of the `Deref` type to
target edges and then recursively preserves all targets.
Optimize away some `fs::metadata` calls.
This also eliminates a use of a `Path` convenience function, in support
of #80741, refactoring `std::path` to focus on pure data structures and
algorithms.
Rollup of 7 pull requests
Successful merges:
- #79675 (Make sure rust-call errors occur correctly for traits)
- #80372 (Don't panic when an external crate can't be resolved)
- #80761 (handle generic trait methods in coverage-report tests)
- #80785 (rustc_ast_pretty: Remove `PrintState::insert_extra_parens`)
- #80791 (Fix type name in doc example for Iter and IterMut)
- #80794 (Use Option::map_or instead of `.map(..).unwrap_or(..)`)
- #80799 (Get rid of custom pretty-printing in rustdoc)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
handle generic trait methods in coverage-report tests
also make the generic function pattern more specific and remove the extra $ that fails the matching.
r? `@wesleywiser`
as this was failing the test of #76896
Don't panic when an external crate can't be resolved
This isn't actually a bug, it can occur when rustdoc tries to resolve a
crate that isn't used in the main code.
Fixes#72381.
r? `@kinnison` if you have time, otherwise `@Manishearth`
Make sure rust-call errors occur correctly for traits
Fixes#79669
Adds trait method resolution to the error, and adds UI tests to ensure it doesn't happen again. Opening as draft because I'm getting weird link errors from unrelated code on my machine, and want to see what CI thinks.
