Simplify `jemalloc` setup
In the past, `#[used]` had to appear in the top-level crate to have a consistent effect on the linker. This has been fixed a while ago for ELF with the introduction of the `symbols.o` file in https://github.com/rust-lang/rust/pull/95604, and more recently for Mach-O in https://github.com/rust-lang/rust/pull/133832, which means that libraries can now implement the required workarounds themselves. This allows moving these `#[used]` declarations out of our `main.rs`.
Specifically, I have moved them into `tikv-jemalloc-sys` where they belong in https://github.com/tikv/jemallocator/pull/109 and done the same for `mimalloc` in https://github.com/purpleprotocol/mimalloc_rust/pull/146 (in case we want to experiment with switching to that one day).
Test with:
```sh
./x build library src/tools/rustdoc src/tools/clippy --set rust.jemalloc=true
# macOS
lldb -- ./build/host/stage1/bin/rustc -vV
(lldb) b _rjem_je_zone_register
(lldb) run
# Should breakpoint, this means that the allocator was properly linked
# Linux
lldb -- ./build/host/stage1/bin/rustc -vV
(lldb) b malloc
(lldb) run
# Should breakpoint, inspect that the `malloc` symbol comes from the `rustc` binary and not from `libc`
```
try-job: `aarch64-gnu`
try-job: `dist-aarch64-linux`
try-job: `dist-x86_64-musl`
try-job: `dist-x86_64-apple`
try-job: `dist-aarch64-apple`
cleanup: merge `RvalueScopes` into `ScopeTree`
This gets rid of `RvalueCandidate`, inlines the definition of `RvalueScopes` into `ScopeTree`, and removes two `RvalueScopes`-specific modules, consolidating the scoping logic a bit. Removing the extra step of going from `RvalueCandidate`s to `RvalueScopes` and removing the duplication between them should also hopefully improve perf.
I've also taken the liberty of doing a bit of renaming and comment updates, changing some "rvalue scope"s to "extended temporary scope"s. This is a bit closer to the Reference's terminology and makes it clearer that it's specific to temporary lifetime extension. This isn't comprehensive. In particular, I've left `record_rvalue_scope_if_borrow_expr` untouched since rust-lang/rust#146098 gets rid of it.
Pulled out from rust-lang/rust#146098.
r? BoxyUwU as the reviewer of rust-lang/rust#146098 (though feel free to reassign/claim! this is just cleanup)
cc `@dingxiangfei2009`
This is useful when you have two dependencies that use different trait for
the same thing and with the same name. The user can accidentally implement
the bad one which might be confusing. This commits refactorizes existing
diagnostics about multiple different crates with the same version and adds
a note when similarly named traits are found. All diagnostics are merged
into a single one.
Document (and test) a problem with `Clone`/`Copy` deriving.
I think this is useful information. I have worked on `derive` impls quite a bit and didn't know about this issue until today.
r? `@saethlin`
[rustdoc] Remove unneeded `allow(rustc::potential_query_instability)`
Originally replaced it with an `expect` and since it failed compilation because it wasn't triggered, I removed it.
Implement DynSend and DynSync for std::panic::Location.
Allows the compiler to build with the `debug_refcell` stdlib cargo feature.
With `rust.std-features = ["debug_refcell"]` in bootstrap.toml, `./x.py build --stage 2` fails before this patch, and succeeds afterwards.
<details> <summary>error for `./x.py build --stage 2` before this patch</summary>
```Rust
error[E0277]: `NonNull<str>` doesn't implement `DynSync`. Add it to `rustc_data_structures::marker` or use `IntoDynSyncSend` if it's already `Sync`
--> compiler/rustc_query_system/src/dep_graph/serialized.rs:719:33
|
719 | let results = broadcast(|_| {
| _______________________---------_^
| | |
| | required by a bound introduced by this call
720 | | let mut local = self.local.borrow_mut();
... |
734 | | });
| |_________^ within `Location<'static>`, the trait `DynSync` is not implemented for `NonNull<str>`
|
note: required because it appears within the type `Location<'static>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/panic/location.rs:39:12
|
39 | pub struct Location<'a> {
| ^^^^^^^^
= note: required for `&'static Location<'static>` to implement `DynSend`
note: required because it appears within the type `std::option::Option<&'static Location<'static>>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/option.rs:599:10
|
599 | pub enum Option<T> {
| ^^^^^^
note: required because it appears within the type `std::cell::UnsafeCell<std::option::Option<&'static Location<'static>>>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/cell.rs:2289:12
|
2289 | pub struct UnsafeCell<T: ?Sized> {
| ^^^^^^^^^^
note: required because it appears within the type `Cell<std::option::Option<&'static Location<'static>>>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/cell.rs:313:12
|
313 | pub struct Cell<T: ?Sized> {
| ^^^^
note: required because it appears within the type `RefCell<LocalEncoderState>`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/cell.rs:822:12
|
822 | pub struct RefCell<T: ?Sized> {
| ^^^^^^^
= note: required for `rustc_data_structures::sync::WorkerLocal<RefCell<LocalEncoderState>>` to implement `DynSync`
note: required because it appears within the type `EncoderState<D>`
--> compiler/rustc_query_system/src/dep_graph/serialized.rs:546:8
|
546 | struct EncoderState<D: Deps> {
| ^^^^^^^^^^^^
= note: required because it appears within the type `&EncoderState<D>`
note: required because it's used within this closure
--> compiler/rustc_query_system/src/dep_graph/serialized.rs:719:33
|
719 | let results = broadcast(|_| {
| ^^^
note: required by a bound in `rustc_data_structures::sync::broadcast`
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/compiler/rustc_data_structures/src/sync/parallel.rs:239:56
|
239 | pub fn broadcast<R: DynSend>(op: impl Fn(usize) -> R + DynSync) -> Vec<R> {
| ^^^^^^^ required by this bound in `broadcast`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `rustc_query_system` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:02:04
```
</details>
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#141470 (Add new `function_casts_as_integer` lint)
- rust-lang/rust#143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks)
- rust-lang/rust#146495 (rustdoc: Erase `#![doc(document_private_items)]`)
- rust-lang/rust#147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`)
- rust-lang/rust#147833 (rustdoc-json: move `target` to `json::conversions`)
- rust-lang/rust#147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers)
- rust-lang/rust#148480 (Add `Steal::risky_hack_borrow_mut`)
- rust-lang/rust#148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`)
- rust-lang/rust#148508 (Provide more context when mutably borrowing an imutably borrowed value)
- rust-lang/rust#148530 (update the bootstrap readme)
- rust-lang/rust#148608 (Add test for --test-builder success path)
- rust-lang/rust#148636 (bootstrap: respect `build.python` on macOS)
- rust-lang/rust#148639 (test(rustdoc): move tests into jump-to-def)
- rust-lang/rust#148647 (Check unsafety for non-macro attributes in `validate_attr`)
- rust-lang/rust#148667 (a few small clippy fixes)
r? `@ghost`
`@rustbot` modify labels: rollup
Port `cfg_select!` to the new attribute parsing system
Best reviewed commit by commit, since it involves some moving around of code
r? `````@jdonszelmann`````
std: support `RwLock` and thread parking on TEEOS
Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms.
CC ``@petrochenkov`` ``@Sword-Destiny``
Check unsafety for non-macro attributes in `validate_attr`
r? `````@jdonszelmann`````
Also adds a test for a previously untested case, unnecessary unsafe on a proc macro attribute
In preparation for https://github.com/rust-lang/rust/issues/148453
bootstrap: respect `build.python` on macOS
The `python()` method was hardcoded to return `/usr/bin/python3` on macOS, ignoring the `build.python` config option. This change respects the config while maintaining the system Python as the default.
Provide more context when mutably borrowing an imutably borrowed value
Point at statics and consts being mutable borrowed or written to:
```
error[E0594]: cannot assign to immutable static item `NUM`
--> $DIR/E0594.rs:4:5
|
LL | static NUM: i32 = 18;
| --------------- this `static` cannot be written to
...
LL | NUM = 20;
| ^^^^^^^^ cannot assign
```
Point at the expression that couldn't be mutably borrowed from a pattern:
```
error[E0596]: cannot borrow data in a `&` reference as mutable
--> $DIR/mut-pattern-of-immutable-borrow.rs:19:14
|
LL | match &arg.field {
| ---------- this cannot be borrowed as mutable
LL | Some(ref mut s) => s.push('a'),
| ^^^^^^^^^ cannot borrow as mutable
```
Partially address rust-lang/rust#74617.
Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`
```
error[E0310]: the parameter type `R` may not live long enough
--> $DIR/implicit-static-lifetime-in-dyn-trait-return-type.rs:10:5
|
LL | fn bb<R>(r: R) -> Box<dyn Foo> {
| ------- this `dyn Trait` has an implicit `'static` lifetime bound
LL | Box::new(Bar(r))
| ^^^^^^^^^^^^^^^^
| |
| the parameter type `R` must be valid for the static lifetime...
| ...so that the type `R` will meet its required lifetime bounds
|
help: consider adding an explicit lifetime bound
|
LL | fn bb<R: 'static>(r: R) -> Box<dyn Foo> {
| +++++++++
```
Partly address rust-lang/rust#41966 and rust-lang/rust#54753. rust-lang/rust#103849, which shows a case where there's an intermediary binding, is not addressed at all, as aren't cases *other* than `Box<dyn Trait>` return type.
Add `Steal::risky_hack_borrow_mut`
I'm working on a rustc driver (Creusot) which needs to modify the MIR read by two queries, `mir_borrowck` and `check_liveness`, in different ways for each query. Both of these queries use `mir_promoted` to read the MIR, which is immutable (until it is stolen).
This adds an escape hatch so rustc drivers can mutate MIR for specific queries. And this removes `get_mut` which is unused and also unusable now that there's no way to get a `&mut Steal` from the rustc API.
Another approach may be to override the queries to modify the MIR after having read it from `mir_promoted`. However the implementation of queries is largely hidden, so I can't just copy their code to then modify it. A solution would be to parameterize the queries with callbacks which get instantiated with `mir_promoted` by default, but that seems more involved and ad hoc. That's why I'm proposing this smaller change instead.
compiletest: Migrate `TestProps` directive handling to a system of named handlers
One of the very silly things about directive processing in compiletest is that for each directive in the test file, we proceed to check it against dozens of different directive names in linear sequence, without any kind of indexed lookup, and without any early-exit after a known directive name is found (unless a panic occurs).
This PR is a big step away from that, by taking the `iter_directives` loop in `TestProps::load_from` and making all of its directive processing dispatch to a hashtable of individual name-specific handlers instead.
---
The handler system is set up in a way that should allow us to add capabilities or change the implementation as needed, without having to mass-modify the existing handlers (e.g. this is why the `handler` and `multi_handler` functions are used).
---
This PR is focused on mass-migrating all of the `TestProps` directive processing into handlers. Most of the resulting handlers could obviously be simplified further (e.g. by avoiding the redundant name checks that were needed in the pre-migration code), but I've avoided doing any such simplifications in this PR to keep its scope limited and make reviewing easier.
The patches in this PR have been arranged so that the main migration can be inspected with `git diff --color-moved --color-moved-ws=ignore-all-space` to verify that it moves all of the relevant lines intact, without modifying or discarding any of them.
r? jieyouxu
rustdoc-json: move `target` to `json::conversions`
It belongs here, because it moves from a `rustc_*` type to a `rustdoc_json_types` type.
r? ```````@GuillaumeGomez```````
rustdoc: Erase `#![doc(document_private_items)]`
I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang/rust#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`.
However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang/rust#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang/rust#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted.
Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute.
I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say.
Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks
This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations).
As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0:
```rust
#[cfg(any())] // Equivalent to the more recent #[cfg(false)]
unsafe extern "C" fn bar(_: u32, ...) {}
```
Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP.
The idea of rejecting `...` pre-expansion was first raised here https://github.com/rust-lang/rust/pull/143546#issuecomment-3043142052.
Tracking issue: rust-lang/rust#44930
cc `@folkertdev` `@workingjubilee`
r? `@joshtriplett`
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to https://github.com/rust-lang/rust/issues/81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
