You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Should the sets of library and language features be disjoint? #43089
Currently, there is a check in tidy that ensures that there is no library feature and language feature of the same name. Its presence is also mentioned in the documentation above.
This check was present since #21248, and has caused multiple additions that have both library and language components to be split up:
i128 / i128_type
inclusive_range / inclusive_range_syntax
profiler_runtime / profiler_runtime_lib
PR #40939 has challenged the status quo, by reusing the lang feature proc_macro inside libraries provided to programs. It actually added an exception to the tidy check in order to get it passing.
There has been discussion about this in the thread of #40939 and the resolution was to allow proc_macro to share the feature gate.
So my question is: which purpose does this check serve? should the check be present, or should it be abolished? Should the proc_macro feature gate be split up into a library component and a lang component?
changed the title [-]Should the sets of library and language features be disjunct?[/-][+]Should the sets of library and language features be disjoint?[/+]on Jul 6, 2017
IMO we should just kill the tidy check. For inclusive ranges we are stabilizing the lib and syntax separately, but if they had been under the same gate it would have been easy to split them up, like we are doing for const fn.
Looks like the original code allowed for a 'joint features' whitelist, so it seems like it might have just been a sanity check that any intersection was intentional. Indeed, that script actually says that it's for doing some sanity checks.
If for some reason that sanity check is still desirable, at minimum I'd be +1 to creating a joint_features whitelist rather than ad-hoc growing the if condition.
it seems like it might have just been a sanity check that any intersection was intentional
We can guard from that by doing a check for any joint features whether the tracking issue and stability status (stable or unstable) matches between lib and lang features.
Activity
[-]Should the sets of library and language features be disjunct?[/-][+]Should the sets of library and language features be disjoint?[/+]durka commentedon Jul 6, 2017
IMO we should just kill the tidy check. For inclusive ranges we are stabilizing the lib and syntax separately, but if they had been under the same gate it would have been easy to split them up, like we are doing for const fn.
nikomatsakis commentedon Jul 6, 2017
I too think we should lump things that are "the same underlying concept" under one feature gate.
aidanhs commentedon Jul 6, 2017
Looks like the original code allowed for a 'joint features' whitelist, so it seems like it might have just been a sanity check that any intersection was intentional. Indeed, that script actually says that it's for doing some sanity checks.
If for some reason that sanity check is still desirable, at minimum I'd be +1 to creating a
joint_featureswhitelist rather than ad-hoc growing the if condition.est31 commentedon Jul 6, 2017
We can guard from that by doing a check for any joint features whether the tracking issue and stability status (stable or unstable) matches between lib and lang features.
Tidy: allow common lang+lib features
Auto merge of #46250 - canndrew:rename-never-type-impl-gate, r=petroc…