Additionally gate negative bounds behind new -Ztrait-solver-testing-features

[fmease]

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 -Ztrait-solver-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.

Footnotes

1. 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]

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]

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]

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 feature (stable and unstable). Do you want to wait for (or request) feedback from additional people?

View changes since this review

[mejrs]

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]

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.