Additionally gate negative bounds behind new `-Zinternal-testing-features` by fmease · Pull Request #156212 · rust-lang/rust

fmease · 2026-05-05T22:18:20Z

Support for negative bounds (not to be confused with negative impls) was added in PR RUST-110791 (2023) for internal testing purposes only.

In PR RUST-119354 (2023) I marked it internal. Moreover, we intentionally never advertise this feature and we declare it as an internal-only feature for testing the trait solver in the Unstable Book (via).

However, these measures didn't prevent someone from trying to use them in the public API of the stdlib¹! I can't blame them in the slightest: The stdlib uses unstable and internal features left and right, even in stable APIs. What's more, there's the sibling feature negative impls that obviously bears a similar name, is not internal and is used in stable APIs. I can see that it's easy to miss that their status differs so drastically.

Well, I have to admit, it's unlikely that such a PR would ever pass review. However, there's a chance it might, I don't know. Last time it was me who caught it.

I argue that "better docs" just wouldn't really help, a tidy rule would be too much effort & be too fragile and triagebot mentions would be the wrong tool for the job (see also) even if their functionality got extended.

Therefore I've decided to additionally gate negative bounds behind a new -Zinternal-testing-features flag. This should be deterrent enough since surely nobody would modify the build flags for the stdlib I'm thinking and the name should scream "I'm unfit for general use".

If y'all disagree with the hypothesis and the solution, please voice your concern! I'm fine with retracting this PR if it's not liked.

This should go without saying but don't put any blame on individuals! Context: https://github.com/rust-lang/rust/pull/146668#issuecomment-3303881805. ↩

rustbot · 2026-05-05T22:18:25Z

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 73 candidates
Random selection from 20 candidates

fmease · 2026-05-05T22:27:00Z

    track_diagnostics: bool = (false, parse_bool, [UNTRACKED],
        "tracks where in rustc a diagnostic was emitted"),
+    trait_solver_testing_features: bool = (false, parse_bool, [TRACKED],
+        "allow certain internal language features to be enabled that help exercise & test the trait solver"),


it's "allow […] to be enabled" not "allow" since it doesn't automatically allow negative bounds as they're still gated behind internal feature negative_bounds; it merely allows you to allow negative_bounds.

View changes since the review

fmease · 2026-05-05T22:28:19Z

    track_diagnostics: bool = (false, parse_bool, [UNTRACKED],
        "tracks where in rustc a diagnostic was emitted"),
+    trait_solver_testing_features: bool = (false, parse_bool, [TRACKED],
+        "allow certain internal language features to be enabled that help exercise & test the trait solver"),


I'm not saying "trait solvers", plural, so this description doesn't need to be updated when the next solver supersedes the old one.

View changes since the review

nnethercote

If y'all disagree with the hypothesis and the solution, please voice your concern! I'm fine with retracting this PR if it's not liked.

This seems fine to me: simple and reasonable. But I'm not an expert on features (stable and unstable). Do you want to wait for (or request) feedback from additional people?

View changes since this review

mejrs · 2026-05-06T07:59:06Z

I like using the playground to experiment with all the crazy internal stuff. Will that no longer be possible with this? At least you can pass arguments on rust.godbolt.org, but stilll...

Can we instead rename the feature gate to something like trait_system_testing_internals? Or require both that and negative_bounds enabled or something like that?

fmease · 2026-05-06T08:27:30Z

Interesting point which I do understand but on the other hand it would sadden me if playground limitations actively dictated how we design our internals.

I also use the playground for experimenting with wacky features and for finding bugs from time to time (and it's easier to use on the phone compared to Godbolt last time I checked). In recent years however I almost always use my local machine for speed, access to IR-dumping -Z flags (oh well), the possibility to compare behavior against much older toolchains etc. One can't even test the next solver on the playground.

I need to think on that.

fmease · 2026-05-06T12:53:34Z

Do you want to wait for (or request) feedback from additional people?

cc @lcnr for visibility

lcnr · 2026-05-06T13:24:30Z

we could generalize this just to -Ztest-internals 🤔 🤷

generally in favor, yeah

nnethercote · 2026-05-08T00:31:53Z

r=me in its current form. I don't have strong opinions about the flag or feature name. Reusing the existing -Ztest-internals also seems fine, that would be nice to not create an additional new flag.

fmease · 2026-06-05T14:33:41Z

Reusing the existing -Ztest-internals also seems fine, that would be nice to not create an additional new flag.

-Ztest-internals as proposed by lcnr doesn't exist yet either, maybe you thought of -Zverbose-internals while writing that. I just thought longer == scarier but I wanna ponder a bit more esp. about whether to replace this flag with a new internal feature.

lcnr · 2026-06-11T11:35:23Z

-Zinternal-testing-features or sth 🤷 don't have a strong preference and its not like we're stabilizing anything here :3

idk, going through my notifs this seems a bit ambiguously stuck. So I'd just go with "r=lcnr,nnethercote" no matter what name you choose

rustbot · 2026-06-11T13:13:39Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

…ures`

fmease · 2026-06-11T13:16:03Z

Renamed to -Zinternal-testing-features.

@bors r=lcnr,nnethercote rollup

rust-bors · 2026-06-11T13:16:06Z

📌 Commit fcbfc8f has been approved by lcnr,nnethercote

It is now in the queue for this repository.

…, r=lcnr,nnethercote Additionally gate negative bounds behind new `-Zinternal-testing-features` Support for negative bounds (not to be confused with negative impls) was added in PR RUST-110791 (2023) for internal testing purposes only. In PR RUST-119354 (2023) I marked it internal. Moreover, we intentionally never advertise this feature and we declare it as *an internal-only feature for testing the trait solver* in the Unstable Book ([via](https://doc.rust-lang.org/unstable-book/language-features/negative-bounds.html#negative_bounds)). However, these measures didn't prevent someone from trying to use them in the public API of the stdlib[^1]! I can't blame them in the slightest: The stdlib uses unstable and internal features left and right, even in stable APIs. What's more, there's the sibling feature *negative impls* that obviously bears a similar name, is not internal and is used in stable APIs. I can see that it's easy to miss that their status differs so drastically. Well, I have to admit, it's unlikely that such a PR would ever pass review. However, there's a chance it might, I don't know. Last time it was me who caught it. I argue that "better docs" just wouldn't really help, a tidy rule would be too much effort & be too fragile and triagebot mentions would be the wrong tool for the job ([see also](rust-lang/triagebot#2182 (comment))) even if their functionality got extended. Therefore I've decided to additionally gate negative bounds behind a new `-Zinternal-testing-features` flag. This should be deterrent enough since surely nobody would modify the build flags for the stdlib I'm thinking and the name should scream "I'm unfit for general use". If y'all disagree with the hypothesis and the solution, please voice your concern! I'm fine with retracting this PR if it's not liked. [^1]: This should go without saying but don't put any blame on individuals! Context: rust-lang#146668 (comment).

…uwer Rollup of 23 pull requests Successful merges: - #157716 (update Enzyme, June'26) - #149793 (Add inline asm support for amdgpu) - #152852 (Remove driver_lint_caps) - #155299 (make repr_transparent_non_zst_fields a hard error) - #155439 (Enable Cargo's new build-dir layout) - #157612 (Add a test where subtyping inhibits coercion.) - #157626 (Autogenerate unstable compiler flag stubs for unstable-book) - #157667 (Rename typing modes to better describe real usage) - #156212 (Additionally gate negative bounds behind new `-Zinternal-testing-features`) - #157342 (Reduce verbosity of cycle errors when possible) - #157366 (Add a regression test for an unconstrained TransmuteFrom ICE) - #157459 (rustc_target: callconv: powerpc64: Remove unreachable fallback code path) - #157658 (UnsafeCell: mention shared-ref-to-interior case, fix aliasing model inaccuracy) - #157698 (Remove an unnecessary cloning) - #157699 (Arg splat experiment - hir FnDecl impl) - #157713 (resolve: Remove exported imports from `maybe_unused_trait_imports`) - #157722 (Move create_scope_map to rustc_codegen_ssa.) - #157725 (Keep generic suggestion for macro-expanded missing-type items) - #157733 (Remove old FIXMEs about nocapture attribute) - #157737 (Reorganize `tests/ui/issues` [7/N]) - #157746 (supports_c_variadic_definitions: extend checklist for new targets) - #157763 (Move unused target expression error to appropriate place and rename it) - #157768 (codegen_ssa: peel trans. wrappers on scalable vecs)

…, r=lcnr,nnethercote Additionally gate negative bounds behind new `-Zinternal-testing-features` Support for negative bounds (not to be confused with negative impls) was added in PR RUST-110791 (2023) for internal testing purposes only. In PR RUST-119354 (2023) I marked it internal. Moreover, we intentionally never advertise this feature and we declare it as *an internal-only feature for testing the trait solver* in the Unstable Book ([via](https://doc.rust-lang.org/unstable-book/language-features/negative-bounds.html#negative_bounds)). However, these measures didn't prevent someone from trying to use them in the public API of the stdlib[^1]! I can't blame them in the slightest: The stdlib uses unstable and internal features left and right, even in stable APIs. What's more, there's the sibling feature *negative impls* that obviously bears a similar name, is not internal and is used in stable APIs. I can see that it's easy to miss that their status differs so drastically. Well, I have to admit, it's unlikely that such a PR would ever pass review. However, there's a chance it might, I don't know. Last time it was me who caught it. I argue that "better docs" just wouldn't really help, a tidy rule would be too much effort & be too fragile and triagebot mentions would be the wrong tool for the job ([see also](rust-lang/triagebot#2182 (comment))) even if their functionality got extended. Therefore I've decided to additionally gate negative bounds behind a new `-Zinternal-testing-features` flag. This should be deterrent enough since surely nobody would modify the build flags for the stdlib I'm thinking and the name should scream "I'm unfit for general use". If y'all disagree with the hypothesis and the solution, please voice your concern! I'm fine with retracting this PR if it's not liked. [^1]: This should go without saying but don't put any blame on individuals! Context: rust-lang#146668 (comment).

…uwer Rollup of 23 pull requests Successful merges: - #157716 (update Enzyme, June'26) - #149793 (Add inline asm support for amdgpu) - #155299 (make repr_transparent_non_zst_fields a hard error) - #155439 (Enable Cargo's new build-dir layout) - #157612 (Add a test where subtyping inhibits coercion.) - #157626 (Autogenerate unstable compiler flag stubs for unstable-book) - #157667 (Rename typing modes to better describe real usage) - #149749 (Make `BorrowedBuf` and `BorrowedCursor` generic over the data) - #156212 (Additionally gate negative bounds behind new `-Zinternal-testing-features`) - #157342 (Reduce verbosity of cycle errors when possible) - #157366 (Add a regression test for an unconstrained TransmuteFrom ICE) - #157459 (rustc_target: callconv: powerpc64: Remove unreachable fallback code path) - #157658 (UnsafeCell: mention shared-ref-to-interior case, fix aliasing model inaccuracy) - #157698 (Remove an unnecessary cloning) - #157699 (Arg splat experiment - hir FnDecl impl) - #157713 (resolve: Remove exported imports from `maybe_unused_trait_imports`) - #157722 (Move create_scope_map to rustc_codegen_ssa.) - #157725 (Keep generic suggestion for macro-expanded missing-type items) - #157733 (Remove old FIXMEs about nocapture attribute) - #157737 (Reorganize `tests/ui/issues` [7/N]) - #157746 (supports_c_variadic_definitions: extend checklist for new targets) - #157763 (Move unused target expression error to appropriate place and rename it) - #157768 (codegen_ssa: peel trans. wrappers on scalable vecs)

Rollup of 24 pull requests Successful merges: - #157716 (update Enzyme, June'26) - #149793 (Add inline asm support for amdgpu) - #155299 (make repr_transparent_non_zst_fields a hard error) - #157612 (Add a test where subtyping inhibits coercion.) - #157626 (Autogenerate unstable compiler flag stubs for unstable-book) - #157667 (Rename typing modes to better describe real usage) - #149749 (Make `BorrowedBuf` and `BorrowedCursor` generic over the data) - #155113 (Ensure Send/Sync impl for std::process::CommandArgs) - #156212 (Additionally gate negative bounds behind new `-Zinternal-testing-features`) - #157342 (Reduce verbosity of cycle errors when possible) - #157366 (Add a regression test for an unconstrained TransmuteFrom ICE) - #157459 (rustc_target: callconv: powerpc64: Remove unreachable fallback code path) - #157658 (UnsafeCell: mention shared-ref-to-interior case, fix aliasing model inaccuracy) - #157698 (Remove an unnecessary cloning) - #157699 (Arg splat experiment - hir FnDecl impl) - #157713 (resolve: Remove exported imports from `maybe_unused_trait_imports`) - #157722 (Move create_scope_map to rustc_codegen_ssa.) - #157723 (Move uninhabited unreachable code lint to rustc_mir_transform) - #157725 (Keep generic suggestion for macro-expanded missing-type items) - #157733 (Remove old FIXMEs about nocapture attribute) - #157737 (Reorganize `tests/ui/issues` [7/N]) - #157746 (supports_c_variadic_definitions: extend checklist for new targets) - #157763 (Move unused target expression error to appropriate place and rename it) - #157768 (codegen_ssa: peel trans. wrappers on scalable vecs)

Rollup merge of #156212 - fmease:double-gate-negative-bounds, r=lcnr,nnethercote Additionally gate negative bounds behind new `-Zinternal-testing-features` Support for negative bounds (not to be confused with negative impls) was added in PR RUST-110791 (2023) for internal testing purposes only. In PR RUST-119354 (2023) I marked it internal. Moreover, we intentionally never advertise this feature and we declare it as *an internal-only feature for testing the trait solver* in the Unstable Book ([via](https://doc.rust-lang.org/unstable-book/language-features/negative-bounds.html#negative_bounds)). However, these measures didn't prevent someone from trying to use them in the public API of the stdlib[^1]! I can't blame them in the slightest: The stdlib uses unstable and internal features left and right, even in stable APIs. What's more, there's the sibling feature *negative impls* that obviously bears a similar name, is not internal and is used in stable APIs. I can see that it's easy to miss that their status differs so drastically. Well, I have to admit, it's unlikely that such a PR would ever pass review. However, there's a chance it might, I don't know. Last time it was me who caught it. I argue that "better docs" just wouldn't really help, a tidy rule would be too much effort & be too fragile and triagebot mentions would be the wrong tool for the job ([see also](rust-lang/triagebot#2182 (comment))) even if their functionality got extended. Therefore I've decided to additionally gate negative bounds behind a new `-Zinternal-testing-features` flag. This should be deterrent enough since surely nobody would modify the build flags for the stdlib I'm thinking and the name should scream "I'm unfit for general use". If y'all disagree with the hypothesis and the solution, please voice your concern! I'm fine with retracting this PR if it's not liked. [^1]: This should go without saying but don't put any blame on individuals! Context: #146668 (comment).

Rollup of 24 pull requests Successful merges: - rust-lang/rust#157716 (update Enzyme, June'26) - rust-lang/rust#149793 (Add inline asm support for amdgpu) - rust-lang/rust#155299 (make repr_transparent_non_zst_fields a hard error) - rust-lang/rust#157612 (Add a test where subtyping inhibits coercion.) - rust-lang/rust#157626 (Autogenerate unstable compiler flag stubs for unstable-book) - rust-lang/rust#157667 (Rename typing modes to better describe real usage) - rust-lang/rust#149749 (Make `BorrowedBuf` and `BorrowedCursor` generic over the data) - rust-lang/rust#155113 (Ensure Send/Sync impl for std::process::CommandArgs) - rust-lang/rust#156212 (Additionally gate negative bounds behind new `-Zinternal-testing-features`) - rust-lang/rust#157342 (Reduce verbosity of cycle errors when possible) - rust-lang/rust#157366 (Add a regression test for an unconstrained TransmuteFrom ICE) - rust-lang/rust#157459 (rustc_target: callconv: powerpc64: Remove unreachable fallback code path) - rust-lang/rust#157658 (UnsafeCell: mention shared-ref-to-interior case, fix aliasing model inaccuracy) - rust-lang/rust#157698 (Remove an unnecessary cloning) - rust-lang/rust#157699 (Arg splat experiment - hir FnDecl impl) - rust-lang/rust#157713 (resolve: Remove exported imports from `maybe_unused_trait_imports`) - rust-lang/rust#157722 (Move create_scope_map to rustc_codegen_ssa.) - rust-lang/rust#157723 (Move uninhabited unreachable code lint to rustc_mir_transform) - rust-lang/rust#157725 (Keep generic suggestion for macro-expanded missing-type items) - rust-lang/rust#157733 (Remove old FIXMEs about nocapture attribute) - rust-lang/rust#157737 (Reorganize `tests/ui/issues` [7/N]) - rust-lang/rust#157746 (supports_c_variadic_definitions: extend checklist for new targets) - rust-lang/rust#157763 (Move unused target expression error to appropriate place and rename it) - rust-lang/rust#157768 (codegen_ssa: peel trans. wrappers on scalable vecs)

rustbot assigned nnethercote May 5, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 5, 2026

fmease commented May 5, 2026

View reviewed changes

nnethercote approved these changes May 5, 2026

View reviewed changes

Comment thread compiler/rustc_ast_passes/src/feature_gate.rs Outdated

fmease force-pushed the double-gate-negative-bounds branch from 0f6b69b to 5105d28 Compare May 6, 2026 08:52

fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 6, 2026

fmease force-pushed the double-gate-negative-bounds branch from 5105d28 to fcbfc8f Compare June 11, 2026 13:13

Additionally gate negative bounds behind new `-Zinternal-testing-feat…

fcbfc8f

…ures`

fmease changed the title ~~Additionally gate negative bounds behind new -Ztrait-solver-testing-features~~ Additionally gate negative bounds behind new -Zinternal-testing-features Jun 11, 2026

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 11, 2026

JonathanBrouwer mentioned this pull request Jun 11, 2026

Rollup of 16 pull requests #157775

Closed

JonathanBrouwer mentioned this pull request Jun 11, 2026

Rollup of 23 pull requests #157784

Closed

JonathanBrouwer mentioned this pull request Jun 11, 2026

Rollup of 23 pull requests #157790

Closed

jhpratt mentioned this pull request Jun 12, 2026

Rollup of 24 pull requests #157794

Merged

rust-bors Bot merged commit 72c2c3a into rust-lang:main Jun 12, 2026
12 checks passed

rustbot added this to the 1.98.0 milestone Jun 12, 2026

fmease deleted the double-gate-negative-bounds branch June 12, 2026 07:04

Uh oh!

Conversation

fmease commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

rustbot commented May 5, 2026

Uh oh!

fmease May 5, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease May 5, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nnethercote left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mejrs commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease commented May 6, 2026

Uh oh!

lcnr commented May 6, 2026

Uh oh!

nnethercote commented May 8, 2026

Uh oh!

fmease commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lcnr commented Jun 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jun 11, 2026

Uh oh!

fmease commented Jun 11, 2026

Uh oh!

rust-bors Bot commented Jun 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

fmease commented May 5, 2026 •

edited

Loading

fmease May 5, 2026 •

edited by rustbot

Loading

fmease May 5, 2026 •

edited by rustbot

Loading

nnethercote left a comment •

edited

Loading

mejrs commented May 6, 2026 •

edited

Loading

fmease commented May 6, 2026 •

edited

Loading

fmease commented Jun 5, 2026 •

edited

Loading

lcnr commented Jun 11, 2026 •

edited

Loading