1
Fork 0
Empowering everyone to build reliable and efficient software. Gabriel's commits. https://www.rust-lang.org/
Find a file
Trevor Gross 8fc4ba2ac1
Rollup merge of #134672 - Zalathar:revert-coverage-attr, r=wesleywiser
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.
2024-12-23 02:07:32 -05:00
.github ci: use ubuntu 24 instead of latest 2024-12-19 16:02:05 +01:00
compiler Rollup merge of #134672 - Zalathar:revert-coverage-attr, r=wesleywiser 2024-12-23 02:07:32 -05:00
library Rollup merge of #134672 - Zalathar:revert-coverage-attr, r=wesleywiser 2024-12-23 02:07:32 -05:00
LICENSES Synchronize Unicode license text from unicode.org 2024-11-20 00:54:12 -08:00
src Rollup merge of #134672 - Zalathar:revert-coverage-attr, r=wesleywiser 2024-12-23 02:07:32 -05:00
tests Rollup merge of #134672 - Zalathar:revert-coverage-attr, r=wesleywiser 2024-12-23 02:07:32 -05:00
.clang-format
.editorconfig
.git-blame-ignore-revs
.gitattributes Revert "Stop git from merging generated files" 2024-12-12 07:20:11 +01:00
.gitignore only ignore {flake,default}.nix and {.envrc,.direnv/} in the root 2024-12-10 00:08:26 +01:00
.gitmodules Update LLVM to 19.1.5 2024-12-03 21:12:47 +08:00
.ignore
.mailmap Update mailmap 2024-12-01 22:07:51 -05:00
Cargo.lock cargo update 2024-12-22 00:22:56 +00:00
Cargo.toml move src/tools/build_helper into src/build_helper 2024-11-11 11:19:11 +03:00
CODE_OF_CONDUCT.md
config.example.toml update build.vendor documentation 2024-12-04 16:02:07 +03:00
configure
CONTRIBUTING.md
COPYRIGHT Synchronize Unicode license text from unicode.org 2024-11-20 00:54:12 -08:00
INSTALL.md
LICENSE-APACHE
license-metadata.json collect-license-metadata: move JSON to root, and add a 'check' mode 2024-11-25 14:14:57 +00:00
LICENSE-MIT
README.md Grammar fixes 2024-12-09 17:17:27 -05:00
RELEASES.md Removed Unnecessary Spaces From RELEASES.md 2024-12-07 01:01:03 +05:30
REUSE.toml collect-license-metadata: move JSON to root, and add a 'check' mode 2024-11-25 14:14:57 +00:00
rust-bors.toml
rustfmt.toml Use field init shorthand where possible 2024-12-17 14:33:10 -08:00
triagebot.toml Add nnethercote to the triagebot.toml vacation list. 2024-12-19 07:41:00 +11:00
x
x.ps1
x.py Reformat Python code with ruff 2024-12-04 23:03:44 +01:00

This is the main source code repository for Rust. It contains the compiler, standard library, and documentation.

Why Rust?

  • Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages.

  • Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.

  • Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).

Quick Start

Read "Installation" from The Book.

Installing from Source

If you really want to install from source (though this is not recommended), see INSTALL.md.

Getting Help

See https://www.rust-lang.org/community for a list of chat platforms and forums.

Contributing

See CONTRIBUTING.md.

License

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.

See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.

Trademark

The Rust Foundation owns and protects the Rust and Cargo trademarks and logos (the "Rust Trademarks").

If you want to use these names or brands, please read the media guide.

Third-party logos may be subject to third-party copyrights and trademarks. See Licenses for details.