Stabilize `unsafe_attributes`
# Stabilization report
## Summary
This is a tracking issue for the RFC 3325: unsafe attributes
We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`.
RFC: rust-lang/rfcs#3325
Tracking issue: #123757
## What is stabilized
### Summary of stabilization
Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones.
```rust
#[unsafe(no_mangle)]
fn a() {}
#[cfg_attr(any(), unsafe(export_name = "c"))]
fn b() {}
```
For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](https://github.com/rust-lang/rust/pull/124214#issuecomment-2124753464)
## Tests
The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.
Use `FnSig` instead of raw `FnDecl` for `ForeignItemKind::Fn`, fix ICE for `Fn` trait error on safe foreign fn
Let's use `hir::FnSig` instead of `hir::FnDecl + hir::Safety` for `ForeignItemKind::Fn`. This consolidates some handling code between normal fns and foreign fns.
Separetly, fix an ICE where we weren't handling `Fn` trait errors for safe foreign fns.
If perf is bad for the first commit, I can rework the ICE fix to not rely on it. But if perf is good, I prefer we fix and clean up things all at once 👍
r? spastorino
Fixes#128764
Remove useless attributes in merged doctest generated code
I took another look at the generated code for merged doctests and it seems like those attributes are only useful when running `rustc --test`, which isn't the case for merged doctests. Less code generated. \o/
r? `@notriddle`
rustdoc-json: Clean up serialization and printing.
Somewhat a followup to #128963, but makes sense regardless.
- Renames `out_path` to `out_dir` because it's not the path to the JSON, but the directory
- Also adds a comment explaining `None`
- Renames `write` to `serialize_and_write` because it does both.
- Also renames the self-profile activity name to be clear this measures both IO cost and serialization CPU cost
- Expands the timer to cover flushing
- Renames `output` to `output_crate`, to emphasize it's the contents, not the `--output` flag.
r? `@GuillaumeGomez`
epoll test: further clean up check_epoll_wait
Given that `check_epoll_wait` compared the length of the two slices, I don't think it was possible for it to ever return `false`. It's also strange to have some requirements checked inside the function and some checked by the caller, so let's just move it all inside the function.
Cc `@tiif` -- did I miss anything?
add 'project' process guidlines for larger contributions
Fixes https://github.com/rust-lang/miri/issues/3443
I am honestly not entirely sure what the consensus from what issue was. I feel like the epoll PR worked reasonably well, and not having been closely involved I am not sure which process `@oli-obk` followed there. Compared to the first draft in #3443 I tried to make this less formal and framed more as guidelines than hard rules.
Migrate `validate_json.py` script to rust in `run-make/rustdoc-map-file` test
This PR fixes the FIXME I added for future-me who become present-me. :')
Since there are multiple `run-make` tests using python scripts, I suppose more of them will migrate to Rust, hence why I added the `jzon` public reexport to the `run-make-support` crate.
cc `@jieyouxu`
r? `@Kobzol`
Migrate `reproducible-build` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This will likely fail. Locally, rustc errors with `linker 'linker' not found` on line 36 while the file exists according to the dir-debug statement before it.
If this gets fixed and the test passes, further developments may include:
- [x] There may be some leftovers from each test - `test_in_tmpdir` may therefore be required.
- [ ] Try jobs on all ignored architectures.
- [x] A potential refactor with a struct and a custom function like #128410 so this isn't just a huge stream of `rfs` and `rustc`. This is a little bit harder to do in this test considering the variability present in each test case.
// try-job: x86_64-msvc // windows jobs passed in a prior run
// try-job: x86_64-mingw
// try-job: i686-msvc
// try-job: i686-mingw
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: armhf-gnu
try-job: test-various
try-job: dist-various-1
FD: remove big surrounding RefCell, simplify socketpair
A while ago, I added the big implicit RefCell for all file descriptions since it avoided interior mutability in `eventfd`. However, this requires us to hold the RefCell "lock" around the entire invocation of the `read`/`write` methods on an FD, which is not great. For instance, if an FD wants to update epoll notifications from inside its `read`/`write`, it is very crucial that the notification check does not end up accessing the FD itself. Such cycles, however, occur naturally:
- eventfd wants to update notifications for itself
- socketfd wants to update notifications on its "peer", which will in turn check *its* peer to see whether that buffer is empty -- and my peer's peer is myself.
This then also lets us simplify socketpair, which currently holds a weak reference to its peer *and* a weak reference to the peer's buffer -- that was previously needed precisely to avoid this issue.
Make unused states of Reserved unrepresentable
In the [previous TB update](https://github.com/rust-lang/miri/pull/3742) we discovered that the existence of `Reserved + !ty_is_freeze + protected` is undesirable.
This has the side effect of making `Reserved { conflicted: true, ty_is_freeze: false }` unreachable.
As such it is desirable that this state would also be unrepresentable.
This PR eliminates the unused configuration by changing
```rs
enum PermissionPriv {
Reserved { ty_is_freeze: bool, conflicted: bool },
...
}
```
into
```rs
enum PermissionPriv {
ReservedFrz { conflicted: bool },
ReservedIM,
...
}
```
but this is not the only solution and `Reserved(Activable | Conflicted | InteriorMut)` could be discussed.
In addition to making the unreachable state not representable anymore, this change has the nice side effect of enabling `foreign_read` to no longer depend explicitly on the `protected` flag.
Currently waiting for
- `@JoJoDeveloping` to confirm that this is the same representation of `Reserved` as what is being implemented in simuliris,
- `@RalfJung` to approve that this does not introduce too much overhead in the trusted codebase.
