-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc standalone
doctest attribute is confusing, taking up a potentially useful name
#129098
Comments
For suggested names, I feel like I also think we could generalize In discussing this with @GuillaumeGomez , the name |
standlone
doctest attribute is confusing, taking up a potentially useful namestandalone
doctest attribute is confusing, taking up a potentially useful name
In the discussion, I pointed out that |
I like |
A verb-object form (or a full-sentence form to be more accurate) could make the meaning clearer, for example |
I like this approach. 👍 |
If this were a more common attribute, I would be against such a long descriptive name. With it being for such a specialized set of use cases, I am not against it
I feel like "this test" is implied by what you are applying it to. |
One advantage of a key-value approach is we could allow people to opt-in to the feature early, reducing the need for MSRV bumps. One level of reducing MSRV bumps is if the attribute is feature gated, erroring if not enabled, and then stabilized before Edition 2024. Even better is if we could ignore if its not enabled and then any MSRV would be compatible with this. In Cargo, we've been applying this model to reduce MSRV bumps where possible, mainly where there isn't a meaningful semantic difference to lose the functionality when on older versions. |
You mean people would need to add the attribute on all doctests? Doesn't sound like a good idea to me. ^^' |
Only if they care enough about MSRV and the performance gains to not wait until 2024 Edition. |
They can enable it in the CI and/or locally if they really can't wait. :) |
For me, this does not cross the threshold to be worth running nightly locally or for production tests as the bar to using nightly is high. I run nightly as a canary in CI to identify problems with my project or rustc early. |
It was renamed into |
#126245 merged support in Edition 2024 for consolidating doctests into as few binaries as possible, with an opt-out of a
standalone
attribute.In reading the code, without looking at the docs, the name's meaning is unclear. It wasn't until I saw a comment on reddit that I understood this to only mean "standalone binary" and not also "standalone process". It came up because someone else was confused on what was happening (reddit).
As shown by the confusion, there are other potential uses for this name and I am interested in exploring those (rust-lang/testing-devex-team#5), so this takes away a potential name for a workflow that could be a lot more common than the current meaning of
standalone
. The fact thatstandalone
only has a couple of uses within this repo suggests its highly specialized and shouldn't be "squatting" on a generic name.The text was updated successfully, but these errors were encountered: