bootstrap: still require `COMPILETEST_FORCE_STAGE0` for `./x test rustdoc-js --stage 0`
This PR reverts #135375, because through some more testing I found out `./x test rustdoc-js --stage 0` does not in fact build rustdoc, and all the tests fail. This can't be intended behavior, so at least require `COMPILETEST_FORCE_STAGE0` to make it less likely to run `rustdoc-js --stage 0` by accident.
The problem that `--stage 0` is not working at all for this rustdoc-js test suite is tracked over at #135603.
cc `@lolbinarycat`
r? bootstrap
Use trait definition cycle detection for trait alias definitions, too
fixes#133901
In general doing this for `All` is not right, but this code path is specifically for traits and trait aliases, and there we only ever use `All` for trait aliases.
Add license-metadata.json to rustc-src tarball.
Adds a license-metadata.json to the source tarball.
This file was reported as missing as a comment on #133461, and it prevents you building the compiler from the source tarball (unless you re-generate it yourself, which is non-obvious and requires `reuse` to be installed).
r? Kobzol
resolve symlinks of LLVM tool binaries before copying them
There is a chance that these tools are being installed from an external LLVM and we have no control over them. If any of these tools use symlinks, they will fail during tarball distribution. This change makes copying process to resolve symlinks just before placing them into the destination path.
Fixes https://github.com/rust-lang/rust/issues/135554
Update docs for `-Clink-dead-code` to discourage its use
The `-Clink-dead-code` flag was originally added way back in #31368, apparently to help improve the output of some older forms of code coverage measurement, and also to address some use-cases for wanting to suppress linker flags like `-dead_strip` and `--gc-section`.
In the past it might have also been useful in conjunction with `-Cinstrument-coverage`, but subsequent improvements to coverage instrumentation have made it unnecessary there.
[It is also currently used by cargo-fuzz by default](https://github.com/rust-fuzz/cargo-fuzz/issues/391), for reasons that are possibly no longer relevant.
---
The flag currently does more than its name suggests, affecting not just linker flags, but also monomorphization decisions. It has also contributed to ICEs (e.g. #135515) that would not have occurred without link-dead-code.
---
For now, this PR just updates the documentation to be more realistic about what the flag does, and when it should be used (approximately never). In the future, it might be worth looking into properly deprecating this flag, and perhaps making it a no-op if feasible.
coverage: Completely overhaul counter assignment, using node-flow graphs
The existing code for choosing where to put physical counter-increments gets the job done, but is very ad-hoc and hard to modify without introducing tricky regressions.
This PR replaces all of that with a more principled approach, based on the algorithm described in "Optimal measurement points for program frequency counts" (Knuth & Stevenson, 1973).
---
We start by ensuring that our graph has “balanced flow”, i.e. each node's flow (execution count) is equal to the sum of all its in-edge flows, and equal to the sum of all its out-edge flows. That isn't naturally true of control-flow graphs, so we introduce a wrapper type `BalancedFlowGraph` to fix that by introducing synthetic nodes and edges as needed.
Once our graph has balanced flow, the next step is to create another view of that graph in which each node's successors have all been merged into one “supernode”. Consequently, each node's out-edges can be coalesced into a single out-edge to one of those supernodes. Because of the balanced-flow property, the flow of that coalesced edge is equal to the flow of the original node.
Having expressed all of our node flows as edge flows, we can then analyze node flows using techniques for analyzing edge flows. We incrementally build a spanning tree over the merged supernodes, such that each new edge in the spanning tree represents a node whose flow can be computed from that of other nodes.
When this is done, we end up with a list of “counter terms” for each node, describing which nodes need physical counters, and how the remaining nodes can have their flow calculated by adding and subtracting those physical counters.
---
The re-blessed coverage tests show that this results in modest or major improvements for our test programs. Some tests need fewer physical counters, some tests need fewer expression nodes for the same number of physical counters, and some tests show striking reductions in both.
Clarify note in `std::sync::LazyLock` example
I doubt most people know what it means, as I did not until a week ago. In the current form, it seems like a `TODO:`.
Fix overflows in the implementation of `overflowing_literals` lint's help
This PR fixes two overflow problems that cause the `overflowing_literals` lint to behave incorrectly in some edge cases.
1. When an integer literal is between `i128::MAX` and `u128::MAX`, an overflowing `as` cast can cause the suggested type to be overly small. It's fixed by using checked type conversion and returning `u128` when it's the only choice. (Fixes#135248)
2. When an integer literal is `i128::MIN` but is of a smaller type, an overflowing negation cause the compiler to panic in debug build. Fixed by checking the number size beforehand and `wrapping_neg`. (Fixes#131849)
Edit: extracted the type conversion part into a standalone function to separate the concern of overflowing.
Update documentation for Arc::from_raw, Arc::increment_strong_count, and Arc::decrement_strong_count to clarify allocator requirement
### Related Issue:
This update addresses parts of the issue raised in [#134242](https://github.com/rust-lang/rust/issues/134242), where Arc's documentation lacks `Global Allocator` safety descriptions for three APIs. And this was confirmed by ```@workingjubilee``` :
> Wait, nevermind. I apparently forgot the `increment_strong_count` is implicitly A = Global. Ugh. Another reason these things are hard to track, unfortunately.
### PR Description
This PR updates the document for the following APIs:
- `Arc::from_raw`
- `Arc::increment_strong_count`
- `Arc::decrement_strong_count`
These APIs currently lack an important piece of documentation: **the raw pointer must point to a block of memory allocated by the global allocator**. This crucial detail is specified in the source code but is not reflected in the documentation, which could lead to confusion or incorrect usage by users.
### Problem:
The following example demonstrates the potential confusion caused by the lack of documentation:
```rust
#![feature(allocator_api)]
use std::alloc::{Allocator,AllocError, Layout};
use std::ptr::NonNull;
use std::sync::Arc;
struct LocalAllocator {
memory: NonNull<u8>,
size: usize,
}
impl LocalAllocator {
fn new(size: usize) -> Self {
Self {
memory: unsafe { NonNull::new_unchecked(&mut 0u8 as *mut u8) },
size,
}
}
}
unsafe impl Allocator for LocalAllocator {
fn allocate(&self, _layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
Ok(NonNull::slice_from_raw_parts(self.memory, self.size))
}
unsafe fn deallocate(&self, _ptr: NonNull<u8>, _layout: Layout) {
}
}
fn main() {
let allocator = LocalAllocator::new(64);
let arc = Arc::new_in(5, &allocator); // Here, allocator could be any non-global allocator
let ptr = Arc::into_raw(arc);
unsafe {
Arc::increment_strong_count(ptr);
let arc = Arc::from_raw(ptr);
assert_eq!(2, Arc::strong_count(&arc)); // Failed here!
}
}
```
[cfg_match] Adjust syntax
A year has passed since the creation of #115585 and the feature, as expected, is not moving forward. Let's change that.
This PR proposes changing the arm's syntax from `cfg(SOME_CONDITION) => { ... }` to `SOME_CODITION => {}`.
```rust
match_cfg! {
unix => {
fn foo() { /* unix specific functionality */ }
}
target_pointer_width = "32" => {
fn foo() { /* non-unix, 32-bit functionality */ }
}
_ => {
fn foo() { /* fallback implementation */ }
}
}
```
Why? Because after several manual migrations in https://github.com/rust-lang/rust/pull/116342 it became clear, at least for me, that `cfg` prefixes are unnecessary, verbose and redundant.
Again, everything is just a proposal to move things forward. If the shown syntax isn't ideal, feel free to close this PR or suggest other alternatives.
There is a chance that these tools are being installed from an external LLVM
and we have no control over them. If any of these tools use symlinks, they will
fail during tarball distribution. This change makes copying process to resolve
symlinks just before placing them into the destination path.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Less unsafe in `dangling`/`without_provenance`
This PR was inspired by the new `NonNull::without_provenance` (cc https://github.com/rust-lang/rust/issues/135243#issuecomment-2583913562) since it made me realize that we could write `NonNull::dangling` in completely-safe code using other existing things.
Then doing that led me to a few more places that could be simplified, like now that GVN will optimize Transmute-then-PtrToPtr, we can just implement `ptr::without_provenance` by calling `ptr::without_provenance_mut` since the shipped rlib of `core` ends up with the same single statement as the implementation (thanks to GVN merging the steps) and thus there's no need to duplicate the `transmute` -- and more importantly, no need to repeat a long safety comment.
There did end up being a couple of other changes needed to avoid exploding certain bits of MIR, though -- like `<Box<[i32]>>::default()`'s MIR originally got way worse as certain things didn't inline, or had a bunch of extraneous UbChecks -- so there's a couple of other changes to solve that.
tests: Port `extern-fn-reachable` to rmake.rs
Part of #121876.
## Summary
This PR ports `tests/run-make/extern-fn-reachable` to use `rmake.rs`. Notable changes:
- We now use the `object` crate and look at the exported symbols specifically.
- This test's coverage regressed against windows-msvc back in [replace dynamic library module with libloading #90716](https://github.com/rust-lang/rust/pull/90716), but since we use `object` now, we're able to claw the test coverage back.
- The checks are now stricter:
1. It no longer looks for substring symbol matches in `nm` textual outputs, it inspects the symbol names precisely.
2. We now also explicitly check for the presence of leading underscore in exported symbol names on apple vs non-apple targets.
- Added another case of `#[no_mangle] fn fun6() {}` (note the lack of `pub`) to check that Rust nameres visibility is orthogonal to symbol visibility in dylib.
## History
- Test was initially introduced as a run-pass[^run-pass] test as part of [Don't mark reachable extern fns as internal #10539](https://github.com/rust-lang/rust/pull/10539).
- Test re-introduced as a run-make test in https://github.com/rust-lang/rust/pull/13741.
- Later, the test coverage regressed in https://github.com/rust-lang/rust/pull/90716.
[^run-pass]: no longer a thing nowadays
Supersedes #128314.
Co-authored with `@lolbinarycat.`
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: test-various
Rollup of 5 pull requests
Successful merges:
- #135497 (fix typo in typenames of pin documentation)
- #135522 (add incremental test for issue 135514)
- #135523 (const traits: remove some known-bug that do not seem to make sense)
- #135535 (Add GUI test for #135499)
- #135541 (Methods of const traits are const)
r? `@ghost`
`@rustbot` modify labels: rollup
const traits: remove some known-bug that do not seem to make sense
These tests were made to point to #103507 in https://github.com/rust-lang/rust/pull/114134; I think that was a mistake: that issue is about a rather specific problem, and most tests marked as known-bug in that PR are pointing at https://github.com/rust-lang/rust/issues/110395 which makes more sense.
Of the 4 tests that still point to #103507:
- One is [the original test](2088260852/tests/ui/impl-trait/normalize-tait-in-const.rs). It still fails to compile, though currently for unrelated reasons (`~const Fn` is not valid as that is not a const trait). I made it point at #110395 like all the other tests that were disabled when the previous const trait impl was removed.
- One is being fixed in https://github.com/rust-lang/rust/pull/135423
- The other two are fixed in this PR
The errors we are getting here are not great but they do look correct?
FWIW there are still a whole lot of tests mentioning #110395 despite that issue being closed... I hope someone is tracking that.^^
r? `@compiler-errors`
add incremental test for issue 135514
r? `@compiler-errors` as requested in https://github.com/rust-lang/rust/issues/135514#issuecomment-2591614811
This adds parts of `@steffahn's` repro as an incremental test for #135514. I had initially added the actual exploitation of the issue into the safe transmute, but removed it because it's not exactly needed for such a test. I can add it back if you'd like.
I've verified that the test fails with https://github.com/rust-lang/rust/pull/133828 reverted.
fix typo in typenames of pin documentation
I noticed this whilst reading the documentation for pin.
Basically there was just one to many closing angle brackets on the type parameters in the documentation where instead of being `Pin<&mut T>` it was `Pin<&mut T>>`
Add COPYRIGHT-*.html files to distribution and update `COPYRIGHT`
* Updates the `COPYRIGHT` file to describe how we actually do things now, and removes the licence text from it as they are stored elsewhere.
* dist tarballs get all of the files in `LICENSES/*`.
* This folder is managed by `reuse` and each file exists because we refer to the licence somewhere in our tree. We should be supplying these licence texts to anyone who obtains a copy of the source code and now we do.
* The binary rust tarball gets `COPYRIGHT.html` and `COPYRIGHT-library.html`, which are auto-generated files that describe the licence information for both the in-tree source files used to build the Rust toolchain, and the out-of-tree dependencies we used to build the toolchain.
* The other binary tarballs are unchanged, for now. In future you need to make a call whether to ship multiple version of COPYRIGHT.html, or whether to try and make, for example, a cargo-specific COPYRIGHT.html file.
* The `LICENSE-MIT` file now includes a blanket copyright statement, as the text indicates that it should and because users will expect to know who owns the copyright of the material they have been given (even if the answer is 'lots of people').
try-job: x86_64-fuchsia
TRPL: incorporate all backward-compatible Edition changes
This incorporates all the backwards-compatible changes for the 2024 Edition on stable. There will also be a follow-on PR to land revisions to the new chapter on async so it can be as ready as possible when officially released with 1.85 and the 2024 Edition.
Additionally, there are a few other, non-backward-compatible, changes (largely around `use<..>`) we can only land using the stable edition, which we may or may not be able to land in 1.85 by using the beta toolchain in the example code. Those may or may not be ported over, depending on how that does or does not play with the infrastructure.
There is also an accompanying PR, #135508, to land these changes on `beta` so they can go out with 1.85 and the Edition release.
Prefer lower `TraitUpcasting` candidates in selection
Fixes#135463. The underlying cause is this ambiguity, but it's more clear (and manifests as a coercion error, rather than a MIR validation error) when it's written the way I did in the UI test.
Sorry this is cursed r? lcnr
rustdoc: Remove `AttributesExt` trait magic that added needless complexity
The new code is more explicit and avoids trait magic that added needless
complexity to this part of rustdoc.
deprecate `std::intrinsics::transmute` etc, use `std::mem::*` instead
The `rustc_allowed_through_unstable_modules` attribute lets users call `std::mem::transmute` as `std::intrinsics::transmute`. The former is a reexport of the latter, and for a long time we didn't properly check stability for reexports, so making this a hard error now would be a breaking change for little gain. But at the same time, `std::intrinsics::transmute` is not the intended path for this function, so I think it is a good idea to show a deprecation warning when that path is used. This PR implements that, for all the functions in `std::intrinsics` that carry the attribute.
I assume this will need ``@rust-lang/libs-api`` FCP.
std: lazily allocate the main thread handle
https://github.com/rust-lang/rust/pull/123550 eliminated the allocation of the main thread handle, but at the cost of greatly increased complexity. This PR proposes another approach: Instead of creating the main thread handle itself, the runtime simply remembers the thread ID of the main thread. The main thread handle is then only allocated when it is used, using the same lazy-initialization mechanism as for non-runtime use of `thread::current`, and the `name` method uses the thread ID to identify the main thread handle and return the correct name ("main") for it.
Thereby, we also allow accessing `thread::current` before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from `name` will only be "main" after the runtime initialization code has run, but I think that is acceptable.
This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
Reverts #123550, CC ``@GnomedDev``
Treat safe target_feature functions as unsafe by default [less invasive variant]
This unblocks
* #134090
As I stated in https://github.com/rust-lang/rust/pull/134090#issuecomment-2541332415 I think the previous impl was too easy to get wrong, as by default it treated safe target feature functions as safe and had to add additional checks for when they weren't. Now the logic is inverted. By default they are unsafe and you have to explicitly handle safe target feature functions.
This is the less (imo) invasive variant of #134317, as it doesn't require changing the Safety enum, so it only affects FnDefs and nothing else, as it should.
