Allow #[rustc_builtin_macro = "name"]
This adds the option of specifying the name of a builtin macro in the `#[rustc_builtin_macro]` attribute: `#[rustc_builtin_macro = "name"]`.
This makes it possible to have both `std::panic!` and `core::panic!` as a builtin macro, by using different builtin macro names for each. This is needed to implement the edition-specific behaviour of the panic macros of RFC 3007.
Also removes `SyntaxExtension::is_derive_copy`, as the macro name (e.g. `sym::Copy`) is now tracked and provides that information directly.
r? ``@petrochenkov``
Remove under-used ImplPolarity enum
It doesn't make much sense to have an enum with only two possible values and to store it inside an `Option` in my opinion when you can do all the same with a simple boolean. I don't expect any chances, performance or RSS usage wise.
r? ``@jyn514``
Support `download-ci-llvm` on NixOS
In particular, the CI built `libLLVM-*.so` needs to have `libz.so`
RPATHed so that binaries like `llvm-config` work at all.
Use correct span for structured suggestion
On structured suggestion for `let` -> `const` and `const` -> `let`, use
a proper `Span` and update tests to check the correct application.
Follow up to #80012.
Fix safety comment
The size assertion in the comment was inverted compared to the code. After fixing that the implication that `(new_size >= old_size) => new_size != 0` still doesn't hold so explain why `old_size != 0` at this point.
Improve core::ptr::drop_in_place debuginfo
* Use span of the dropped type as function span when possible.
* Rename symbol from `core::ptr::drop_in_place::$hash` to `{{drop}}::<$TYPE>::$hash`.
Fixes#77465
(I haven't yet updated the tests)
Implement From<char> for u64 and u128.
With this PR you can write
```
let u = u64::from('👤');
let u = u128::from('👤');
```
Previously, you could already write `as` conversions ([Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cee18febe28e69024357d099f07ca081)):
```
// Lossless conversions
dbg!('👤' as u32); // Prints 128100
dbg!('👤' as u64); // Prints 128100
dbg!('👤' as u128); // Prints 128100
// truncates, thus no `From` impls.
dbg!('👤' as u8); // Prints 100
dbg!('👤' as u16); // Prints 62564
// These `From` impls already exist.
dbg!(u32::from('👤')); // Prints 128100
dbg!(u64::from(u32::from('👤'))); // Prints 128100
```
The idea is from ``@gendx`` who opened [this Internals thread](https://internals.rust-lang.org/t/implement-from-char-for-u64/13454), and ``@withoutboats`` responded that someone should open a PR for it.
Some people mentioned `From<char>` impls for `f32` and `f64`, but that doesn't seem correct to me, so I didn't include them here.
I don't know what the feature should be named. Must it be registered somewhere, like unstable features?
r? ``@withoutboats``
Don't mark `force_query_with_job` as `inline(always)`
It's rather large, and using `inline(always)` forces it to be recompiled
in each calling crate. Hopefully this change will help with #65031. I intentionally only removed inline from `force_query_with_job` because the other functions are tiny and I wanted to measure this change on its own.
This may conflict with https://github.com/rust-lang/rust/issues/78780. I am not sure if it will hurt or help.
cc `@cjgillot`
Use an empty `TokenCursorFrame` stack when capturing tokens
We will never need to pop past our starting frame during token
capturing. Using an empty stack allows us to avoid pointless heap
allocations/deallocations.
This makes it possible to have both std::panic and core::panic as a
builtin macro, by using different builtin macro names for each.
Also removes SyntaxExtension::is_derive_copy, as the macro name (e.g.
sym::Copy) is now tracked and provides that information directly.
resolve/expand: Improve attribute expansion on macro definitions and calls
- Do not forget to visit attributes on macro definitions and calls in couple of places.
- Remove some weird special treatment of macro definition items, which is probably left from old times when macro definitions were treated more like macro calls.
Fixes https://github.com/rust-lang/rust/issues/80540
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
We will never need to pop past our starting frame during token
capturing. Using an empty stack allows us to avoid pointless heap
allocations/deallocations.
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.
