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.
Update books
## rust-lang/book
21 commits in 9900d976bbfecf4e8124da54351a9ad85ee3c7f3..ad2011d3bcad9f152d034faf7635c22506839d58
2024-12-16 16:11:34 UTC to 2024-12-05 19:19:24 UTC
- Ch. 10: clarify note about compiler errors and `'static` (rust-lang/book#4164)
- Introduce `let`-`else` statement (rust-lang/book#3702)
- Fix misleading explanation of comma in `$(),*` (rust-lang/book#3800)
- ch18-03: Matching Named Variables: mention `if let`/`while let` (rust-lang/book#3110)
- Ch. 4: Rephrase/clarify paragraph on reference scope (rust-lang/book#3688)
- Simplify note about functions in ch13-01-closures.md (rust-lang/book#3699)
- fix: make the reason more understandable (rust-lang/book#4074)
- Fixed grammatical error in the comment on line 22 (rust-lang/book#3180)
- ch17-02: Monomorphization applies to generics in general (rust-lang/book#3367)
- Ch. 21: Use `Vec::drain` to teach alternatives to `Option` (rust-lang/book#4159)
- fix(typo): correct punctuation in ch15-06-reference-cycles.md (rust-lang/book#4155)
- Ch. 20: show both `impl Fn` and `Box<dyn Fn>` (rust-lang/book#4152)
- Add `use super::*;` to unit-test examples. (rust-lang/book#4151)
- Remove emphasis on four-space indents (rust-lang/book#4150)
- Fix `.git-blame-ignore-revs` file (rust-lang/book#4149)
- Rust 2024: distinguish `unsafe fn` vs. `unsafe` blocks (rust-lang/book#4148)
- Update README.md typo (rust-lang/book#4146)
- Ch. 15.5: account for improved error message (rust-lang/book#4142)
- Document use of rustfmt and dprint for formatting (rust-lang/book#4138)
- tools: fix nostarch build reference to mdbook-trpl (rust-lang/book#4137)
- Revise sentence to not refer to two subjects as it (rust-lang/book#4136)
## edition-guide
6 commits in 128669297c8a7fdf771042eaec18b8adfaeaf0cd..bc4ce51e1d4dacb9350a92e95f6159a42de2f8c6
2024-12-03 22:02:43 +0000 to 2024-12-18 05:34:59 +0000
- Add chapter for 2024 match ergonomics reservations (rust-lang/edition-guide#349)
- Re-title "Additions to the prelude" (rust-lang/edition-guide#348)
- Show tail expression temporary example that fails in 2024 (rust-lang/edition-guide#345)
- Add more triagebot labeling support (rust-lang/edition-guide#346)
- 2024: Assignment operator RHS indentation (rust-lang/edition-guide#341)
- 2024: Add chapter on single-line `where` clauses (rust-lang/edition-guide#340)
## rust-lang/nomicon
1 commits in 0674321898cd454764ab69702819d39a919afd68..97e84a38c94bf9362b11284c20b2cb4adaa1e868
2024-12-10 02:41:27 UTC to 2024-12-10 02:41:27 UTC
- races.md: data race -> race condition to violate memory safety (rust-lang/nomicon#470)
## reference
8 commits in ede56d1bbe132bac476b5029cd6d7508ca9572e9..9f41bc11342d46544ae0732caf14ec0bcaf27376
2024-12-03 22:26:55 +0000 to 2024-12-18 23:04:30 +0000
- `coverage` attribute (rust-lang/reference#1628)
- Clarify that `extern crate foo as føø` is allowed (rust-lang/reference#1697)
- Fix rule auto-linking on Windows (rust-lang/reference#1698)
- Reflect rust#133422 & rust#133587 to inline assembly documentation (rust-lang/reference#1695)
- Describe async closures (rust-lang/reference#1692)
- Update closures for edition 2021 disjoint closure capturing (rust-lang/reference#1521)
- Fix paragraphs with trailing `\1` (rust-lang/reference#1696)
- Add triagebot autolabel (rust-lang/reference#1694)
## rust-lang/rust-by-example
1 commits in e1d1f2cdcee4d52b9a01ff7c448be4372a377b70..76406337f4131253443aea0ed7e7f451b464117c
2024-12-07 00:24:30 UTC to 2024-12-07 00:24:30 UTC
- Fix#1900 (rust-lang/rust-by-example#1901)
## rust-lang/rustc-dev-guide
9 commits in b21d99b770f9aceb0810c843847c52f86f45d2ed..7f7ba48f04abc2ad25e52f30b5e2bffa286b019f
2024-12-16 07:12:01 UTC to 2024-12-05 05:01:46 UTC
- Specify what a CGU is (rust-lang/rustc-dev-guide#2163)
- functionality removed from codebase (part 2) (rust-lang/rustc-dev-guide#2160)
- functionality removed from codebase (rust-lang/rustc-dev-guide#2159)
- remove polymorphization (rust-lang/rustc-dev-guide#2158)
- squashing: recommend --keep-base when squashing without a conflict (rust-lang/rustc-dev-guide#2157)
- update section even more (rust-lang/rustc-dev-guide#2156)
- extend closure constraints section (rust-lang/rustc-dev-guide#2155)
- Remove `//@ compare-output-lines-by-subset` directive (rust-lang/rustc-dev-guide#2151)
- Document `needs-target-has-atomic` directive (rust-lang/rustc-dev-guide#2154)
Promote powerpc64le-unknown-linux-musl to tier 2 with host tools
MCP: https://github.com/rust-lang/compiler-team/issues/803
I'm using crosstool-ng for building a toolchain because GCC 9 from `musl-toolchain.sh` has float ABI issues (?) and can't compile LLVM, and writing a crosstool-ng config for a target feels less hacky than yet another target specific shell script. I also defined a kernel version, since there wasn't one specified before. If a lower version is desired, just let me know. I also tried to match the rust configure args with the loongarch64 musl tier 2 target.
The resulting compiler works fine, built with `DEPLOY=1 ./src/ci/docker/run.sh dist-powerpc64le-linux` and tested on Alpine Linux in a VM and on a bare metal POWER8 machine:
```
qemu-ppc64le:/tmp/rust-nightly-powerpc64le-unknown-linux-musl$ ash install.sh
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'rust-std-powerpc64le-unknown-linux-musl'
install: installing component 'cargo'
install: installing component 'rustfmt-preview'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'clippy-preview'
install: installing component 'miri-preview'
install: installing component 'rust-analysis-powerpc64le-unknown-linux-musl'
install: installing component 'llvm-bitcode-linker-preview'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error
rust installed.
qemu-ppc64le:~$ echo 'fn main() { println!("hello world"); }' > test.rs
qemu-ppc64le:~$ rustc test.rs
qemu-ppc64le:~$ ./test
hello world
qemu-ppc64le:~$ file test
test: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), statically linked, BuildID[sha1]=596ee6abf9add487ebc54fb71c2076fb6faea013, with debug_info, not stripped
```
try-job: dist-powerpc64le-linux
`CheckAttrVisitor::check_doc_keyword` checks `#[doc(keyword = "..")]`
attributes to ensure they are on an empty module, and that the value is
a non-empty identifier.
The `rustc::existing_doc_keyword` lint checks these attributes to ensure
that the value is the name of a keyword.
It's silly to have two different checking mechanisms for these
attributes. This commit does the following.
- Changes `check_doc_keyword` to check that the value is the name of a
keyword (avoiding the need for the identifier check, which removes a
dependency on `rustc_lexer`).
- Removes the lint.
- Updates tests accordingly.
There is one hack: the `SelfTy` FIXME case used to used to be handled by
disabling the lint, but now is handled with a special case in
`is_doc_keyword`. That hack will go away if/when the FIXME is fixed.
Co-Authored-By: Guillaume Gomez <guillaume1.gomez@gmail.com>
rustdoc-search: handle `impl Into<X>` better
This PR fixes two bugs I ran into while searching the compiler docs:
- It omitted an `impl Trait` entry in the type signature field, producing `TyCtxt, , Symbol -> bool`
- It didn't let me search for `TyCtxt, DefId, Symbol -> bool` even though that's a perfectly good description of the function I was looking for (the function actually used `impl Into<DefId>`
r? ``@GuillaumeGomez`` cc ``@lolbinarycat``
rustbook: update to use new mdbook-trpl package from The Book
Updates to the latest merge from `rust-lang/book` and simplifies the dependency chain there. There are now three preprocessors, but only one package, so everything is a lot nicer to deal with from the consuming POV (i.e. here).
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)
Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.
- Tracking issue: https://github.com/rust-lang/rust/issues/116973
Fix "std" support status of some tier 3 targets
https://github.com/rust-lang/rust/pull/127265 marked targets with empty "std" support status as no-std targets in target-spec metadata:
> * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build
However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.)
https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3
> The `std` column in the table below has the following meanings:
>
> * ✓ indicates the full standard library is available.
> * \* indicates the target only supports [`no_std`] development.
> * ? indicates the standard library support is unknown or a work-in-progress.
>
> [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html
This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata.
The new status is set based on the following criteria:
- Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl)
- Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl f3068b66e0), so I included them in the group below that means “work in progress” rather than in this group.
- Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available.
- Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported.
r? Noratrieb
cc ``@harmou01``
