Stop using span hack for contracts feature gating #136835
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
compiler-errors
commented
Feb 10, 2025
| @@ -18,26 +18,6 @@ LL | #[core::contracts::ensures(|ret| *ret > 0)] | |||
| = help: add `#![feature(contracts)]` to the crate attributes to enable | |||
| = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date | |||
|
|
|||
| error[E0658]: contracts are incomplete | |||
There was a problem hiding this comment.
This was redundant. We're already issuing a library feature error above, since we're just using a library feature.
Changing it to supporting issuing two feature gates is an undue burden to the parser impl unless we want to gate the internal machinery under both contracts and contracts_internals.
|
Thank you for removing this hack! @bors r+ rollup |
bors
added
S-waiting-on-bors
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Feb 11, 2025
…k, r=celinval Stop using span hack for contracts feature gating The contracts machinery is a pretty straightforward case of an *external* feature using a (perma-unstable) *internal* feature within its implementation. There's no reason why it needs to be implemented any differently than other features by using global span tracking hacks to change whether the internals are gated behind the `contracts` or `contracts_internals` feature gate -- for the case of macro expansions we already have `allow_internal_unstable` for exactly this situation. This PR changes the internal, perma-unstable AST syntax to use the `contracts_internals` gate always, and adjusts the macro expansion to use the right spans so that `allow_internal_unstable` works correctly. As a follow-up, there's really no reason to have `contracts` be a *compiler feature* since it's at this point fully a *library feature*; the only reason it's a compiler feature today is so we can mark it as incomplete, but that seems like a weak reason. I didn't do anything in this PR for this. r? `@celinval`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 11, 2025
Rollup of 11 pull requests Successful merges: - rust-lang#136606 (Fix long lines which rustfmt fails to format) - rust-lang#136663 (Stabilize `NonZero::count_ones`) - rust-lang#136672 (library: doc: core::alloc::Allocator: trivial typo fix) - rust-lang#136704 (Improve examples for file locking) - rust-lang#136721 (cg_llvm: Reduce visibility of some items outside the `llvm` module) - rust-lang#136813 (rustc_target: Add the fp16 target feature for AArch32) - rust-lang#136830 (fix i686-unknown-hurd-gnu x87 footnote) - rust-lang#136832 (Fix platform support table for i686-unknown-uefi) - rust-lang#136835 (Stop using span hack for contracts feature gating) - rust-lang#136837 (Overhaul how contracts are lowered on fn-like bodies) - rust-lang#136839 (fix ensure_monomorphic_enough) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 11, 2025
Rollup merge of rust-lang#136835 - compiler-errors:contracts-span-hack, r=celinval Stop using span hack for contracts feature gating The contracts machinery is a pretty straightforward case of an *external* feature using a (perma-unstable) *internal* feature within its implementation. There's no reason why it needs to be implemented any differently than other features by using global span tracking hacks to change whether the internals are gated behind the `contracts` or `contracts_internals` feature gate -- for the case of macro expansions we already have `allow_internal_unstable` for exactly this situation. This PR changes the internal, perma-unstable AST syntax to use the `contracts_internals` gate always, and adjusts the macro expansion to use the right spans so that `allow_internal_unstable` works correctly. As a follow-up, there's really no reason to have `contracts` be a *compiler feature* since it's at this point fully a *library feature*; the only reason it's a compiler feature today is so we can mark it as incomplete, but that seems like a weak reason. I didn't do anything in this PR for this. r? ``@celinval``
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The contracts machinery is a pretty straightforward case of an external feature using a (perma-unstable) internal feature within its implementation. There's no reason why it needs to be implemented any differently than other features by using global span tracking hacks to change whether the internals are gated behind the
contractsorcontracts_internalsfeature gate -- for the case of macro expansions we already haveallow_internal_unstablefor exactly this situation.This PR changes the internal, perma-unstable AST syntax to use the
contracts_internalsgate always, and adjusts the macro expansion to use the right spans so thatallow_internal_unstableworks correctly.As a follow-up, there's really no reason to have
contractsbe a compiler feature since it's at this point fully a library feature; the only reason it's a compiler feature today is so we can mark it as incomplete, but that seems like a weak reason. I didn't do anything in this PR for this.r? @celinval