Revert stabilization of the `#[coverage(..)]` attribute
Due to a process mixup, the PR to stabilize the `#[coverage(..)]` attribute (#130766) was merged while there are still outstanding concerns. The default action in that situation is to revert, and the feature is not sufficiently urgent or uncontroversial to justify special treatment, so this PR reverts that stabilization.
---
- A key point that came up in offline discussions is that unlike most user-facing features, this one never had a proper RFC, so parts of the normal stabilization process that implicitly rely on an RFC break down in this case.
- As the implementor and de-facto owner of the feature in its current form, I would like to think that I made good choices in designing and implementing it, but I don't feel comfortable proceeding to stabilization without further scrutiny.
- There hasn't been a clear opportunity for T-compiler to weigh in or express concerns prior to stabilization.
- The stabilization PR cites a T-lang FCP that occurred in the tracking issue, but due to the messy design and implementation history (and lack of a clear RFC), it's unclear what that FCP approval actually represents in this case.
- At the very least, we should not proceed without a clear statement from T-lang or the relevant members about the team's stance on this feature, especially in light of the other concerns listed here.
- The existing user-facing documentation doesn't clearly reflect which parts of the feature are stable commitments, and which parts are subject to change. And there doesn't appear to be a clear consensus anywhere about where that line is actually drawn, or whether the chosen boundary is acceptable to the relevant teams and individuals.
- For example, the [stabilization report comment](https://github.com/rust-lang/rust/issues/84605#issuecomment-2166514660) mentions that some aspects are subject to change, but that text isn't consistent with my earlier comments, and there doesn't appear to have been any explicit discussion or approval process.
- [The current reference text](4dfaa4f/src/attributes/coverage-instrumentation.md) doesn't mention this distinction at all, and instead simply describes the current implementation behaviour.
- When the implementation was changed to its current form, the associated user-facing error messages were not updated, so they still refer to the attribute only being allowed on functions and closures.
- On its own, this might have been reasonable to fix-forward in the absence of other concerns, but the fact that it never came up earlier highlights the breakdown in process that has occurred here.
---
Apologies to everyone who was excited for this stabilization to land, but unfortunately it simply isn't ready yet.
Make sure we don't lose default struct value when formatting struct
The reason why https://github.com/rust-lang/rustfmt/issues/6424 broke when https://github.com/rust-lang/rust/pull/129514 landed is because the parser now *successfully* parses default struct values. That means that where we used to fail in `rewrite_macro_inner`:
e108481f74/src/tools/rustfmt/src/macros.rs (L263-L267)
... we now succeed, and we now proceed to format the inner struct as a macro arg. Since formatting was never implemented for default struct values, this means that we’ll always rewrite the struct to exclude the default value.
This PR makes it so that we simply don’t rewrite struct fields if they have a default value.
r? `@ytmimi`
test-infra: improve compiletest and run-make-support symlink handling
I was trying to implement #134656 to port `tests/run-make/incr-add-rust-src-component.rs`, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment).
Key changes:
- I needed to copy symlinks (duplicate a symlink pointing to the same file), so I pulled out the copy symlink logic and re-exposed it as `run_make_support::rfs::copy_symlink`. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks.
- `recursive_remove`:
- I needed a way to remove symlinks themselves (no symlink traversal). `std::fs::remove_dir_all` handles them, but only if the root path is a directory. So I wrapped `std::fs::remove_dir_all` to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks.
- I wanted to use this for both compiletest and run-make-support, so I put the implementation and accompanying tests in `build_helper`.
- In this sense, it's a reland of #129302 with proper test coverage.
- It's a thin wrapper around `std::fs::remove_dir_all` (`remove_dir_all` correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry.
Fixes#126334.
Add `ignore-rustc-debug-assertions` to `tests/ui/associated-consts/issue-93775.rs`
Closes#132111. Closes#133432.
I think this test case is flaky because the recursive calls happen to hit the upper limit of the call stack.
IMO, this may not be an issue, as it's reasonable for overly complex code to require additional build configurations (such as increasing the call stack size).
After set `rust.debug-assertions` is true, the test case requires a larger call stack, so disable it on `rust.debug-assertions=true`.
r? jieyouxu
try-job: x86_64-msvc
try-job: i686-msvc
cleanup `TypeVerifier`
We should merge it with the `TypeChecker` as we no longer bail in cases where it encounters an error since #111863.
It's quite inconsistent whether a check lives in the verifier or the `TypeChecker`, so this feels like a quite impactful cleanup. I expect that for this we may want to change the `TypeChecker` to also be a MIR visitor 🤔 this is non-trivial so I didn't fully do it in this PR.
Best reviewed commit by commit.
r? `@compiler-errors` feel free to reassign however
Rollup of 6 pull requests
Successful merges:
- #130289 (docs: Permissions.readonly() also ignores root user special permissions)
- #134583 (docs: `transmute<&mut T, &mut MaybeUninit<T>>` is unsound when exposed to safe code)
- #134611 (Align `{i686,x86_64}-win7-windows-msvc` to their parent targets)
- #134629 (compiletest: Allow using a specific debugger when running debuginfo tests)
- #134642 (Implement `PointerLike` for `isize`, `NonNull`, `Cell`, `UnsafeCell`, and `SyncUnsafeCell`.)
- #134660 (Fix spacing of markdown code block fences in compiler rustdoc)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix spacing of markdown code block fences in compiler rustdoc
Two place have misaligned open and close ```` ``` ````.
I noticed these because one of them disrupted syntax highlighting in my editor for the rest of the file as I was working on a different change.
<p align="center"><img src="https://github.com/user-attachments/assets/5de21d08-c30c-4e9c-8587-e83b988b9db5" width="500"></p>
Implement `PointerLike` for `isize`, `NonNull`, `Cell`, `UnsafeCell`, and `SyncUnsafeCell`.
* Implementing `PointerLike` for `UnsafeCell` enables the possibility of interior mutable `dyn*` values. Since this means potentially exercising new codegen behavior, I added a test for it in `tests/ui/dyn-star/cell.rs`. Please let me know if there are further sorts of tests that should be written, or other care that should be taken with this change.
It is unfortunately not possible without compiler changes to implement `PointerLike` for `Atomic*` types, since they are not `repr(transparent)` (and, in theory if not in practice, `AtomicUsize`'s alignment may be greater than that of an ordinary pointer or `usize`).
* Implementing `PointerLike` for `NonNull` is useful for pointer types which wrap `NonNull`.
* Implementing `PointerLike` for `isize` is just for completeness; I have no use cases in mind, but I cannot think of any reason not to do this.
* Tracking issue: #102425
`@rustbot` label +F-dyn_star
(there is no label or tracking issue for F-pointer_like_trait)
compiletest: Allow using a specific debugger when running debuginfo tests
r? `@jieyouxu`
Closes#134468
Example: `./x test tests/debuginfo -- --debugger gdb`
Align `{i686,x86_64}-win7-windows-msvc` to their parent targets
There were some changes to `{i686,x86_64}-pc-windows-msvc`, include them in the backward compatibility targets as well.
CC `@roblabla`
docs: `transmute<&mut T, &mut MaybeUninit<T>>` is unsound when exposed to safe code
Closes#66699
On my system (Edit: And also in the [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=90529e2a9900599cb759e4bfaa5b5efe)) the example program terminates with an unpredictable exit code:
```console
$ cargo +nightly build && target/debug/bin ; echo $?
255
$ cargo +nightly build && target/debug/bin ; echo $?
253
```
And miri considers the code to have undefined behavior:
```console
$ cargo +nightly miri run
error: Undefined Behavior: using uninitialized data, but this operation requires initialized memory
--> src/main.rs:12:24
|
12 | std::process::exit(*code); // UB! Accessing uninitialized memory
| ^^^^^ using uninitialized data, but this operation requires initialized memory
|
error: aborting due to 1 previous error
```
docs: Permissions.readonly() also ignores root user special permissions
The root user can write to files without any (write) permission bits set. But this is not taken into account by `std::fs::Permissions.readonly()`.
The rustdoc for `readonly()` also mentions shortcomings later:
> On Unix-based platforms this checks if any of the owner, group or others write permission bits are set. It does not check if the current user is in the file’s assigned group. It also does not check ACLs.
But since this part already clarifies how it works -- it checks write permission bits -- I think it's not necessary to repeat the root user shortcomings here.
This facade is like other `run_make_support::fs` APIs that
panic-on-failure but includes the path that the operation was called on
in the panic message.
`recursive_remove` is intended to be a wrapper around
`std::fs::remove_dir_all`, but which also allows the removal target to
be a non-directory entry, i.e. a file or a symlink. It also tries to
remove read-only attributes from filesystem entities on Windows for
non-dir entries, as `std::fs::remove_dir_all` handles the dir (and its
children) read-only cases.
Co-authored-by: Chris Denton <chris@chrisdenton.dev>
Implementing `PointerLike` for `UnsafeCell` enables the possibility of
interior mutable `dyn*` values. Since this means potentially exercising
new codegen behavior, I added a test for it in `tests/ui/dyn-star/cell.rs`.
Also updated UI tests to account for the `isize` implementation changing
error messages.
Delete `Rvalue::Len` 🎉
Everything's moved to `PtrMetadata`, so we can get rid of the `Len` variant now.
~~Depends on #134326, so draft until that lands~~ Ready!
r? mir
Asserts the maximum value that can be returned from `Vec::len`
Currently, casting `Vec<i32>` to `Vec<u32>` takes O(1) time:
```rust
// See <https://godbolt.org/z/hxq3hnYKG> for assembly output.
pub fn cast(vec: Vec<i32>) -> Vec<u32> {
vec.into_iter().map(|e| e as _).collect()
}
```
But the generated assembly is not the same as the identity function, which prevents us from casting `Vec<Vec<i32>>` to `Vec<Vec<u32>>` within O(1) time:
```rust
// See <https://godbolt.org/z/7n48bxd9f> for assembly output.
pub fn cast(vec: Vec<Vec<i32>>) -> Vec<Vec<u32>> {
vec.into_iter()
.map(|e| e.into_iter().map(|e| e as _).collect())
.collect()
}
```
This change tries to fix the problem. You can see the comparison here: <https://godbolt.org/z/jdManrKvx>.
