-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
turn invalid_type_param_default
into a FutureReleaseErrorReportInDeps
#127655
Conversation
r? @davidtwco rustbot has assigned @davidtwco. Use |
@@ -230,6 +230,7 @@ pub(super) fn generics_of(tcx: TyCtxt<'_>, def_id: LocalDefId) -> ty::Generics { | |||
enum Defaults { | |||
Allowed, | |||
// See #36887 | |||
#[allow(dead_code)] // FIXME remove if the PR moves forward | |||
FutureCompatDisallowed, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW this makes the default_type_parameter_fallback
feature gate a NOP, since all the feature gate seems to do is silence the future-incompat warning. If the feature gate should be preserved I can rename the enum variant to FeatureGated
or so. Otherwise I can also remove the feature gate entirely.
@bors try |
… r=<try> WIP: make invalid_type_param_default a hard error Cc rust-lang#36887 `@rust-lang/types` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. This should be cratered. (But I can also make it `FutureReleaseErrorReportInDeps` first if you prefer.)
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
I'm in favor of this change, and I think we should make this into a hard error (or bump it to deny, if there's significant fallback). Furthermore, I feel like we should go ahead and mark |
@craterbot check @compiler-errors is there code inside the type/trait system that becomes dead when |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
did a quick look through the code, it does not seem like it. just removing the feature should be good enough |
🎉 Experiment
|
Ah, it's our old friend |
@RalfJung: You should still be able to remove the feature gate and clean up the fallout. Do you still want to do that? Otherwise I can. And I still think we can bump this to deny/FCW/some other lint class. |
4282f48
to
ffb3f27
Compare
I have made the PR just bump up the lint to something that shows up in future-compat reports.
Ah, because the feature just silences the lint? Sure, can do. |
ffb3f27
to
a0c7739
Compare
Okay, should be done. :) |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
I doubt anyone cares enough to sway this FCP, but function type parameter defaults act the same as ADT type parameters defaults as far as I know. They're worse off mainly because you can't name function item types. |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Thanks for the info @QuineDot, but I don't really think users should really be using of default type params on functions anyways. If this is heavily requested, I think we can add this feature gate back with a proper lang team experiment to investigate supporting default params the right way (i.e. in a more ergonomic way). @bors r+ |
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` `@rust-lang/types` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#127655 (turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`) - rust-lang#127974 (force compiling std from source if modified) - rust-lang#128026 (std::thread: available_parallelism implementation for vxWorks proposal.) - rust-lang#128362 (add test for symbol visibility of `#[naked]` functions) - rust-lang#128500 (Add test for updating enum discriminant through pointer) - rust-lang#128630 (docs(resolve): more explain about `target`) - rust-lang#128638 (run-make: enable msvc for `link-dedup`) r? `@ghost` `@rustbot` modify labels: rollup
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` ``@rust-lang/types`` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#127655 (turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`) - rust-lang#127974 (force compiling std from source if modified) - rust-lang#128026 (std::thread: available_parallelism implementation for vxWorks proposal.) - rust-lang#128309 (Implement cursors for `BTreeSet`) - rust-lang#128500 (Add test for updating enum discriminant through pointer) - rust-lang#128630 (docs(resolve): more explain about `target`) - rust-lang#128631 (handle crates when they are not specified for std docs) - rust-lang#128638 (run-make: enable msvc for `link-dedup`) r? `@ghost` `@rustbot` modify labels: rollup
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` ```@rust-lang/types``` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#127655 (turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`) - rust-lang#127974 (force compiling std from source if modified) - rust-lang#128026 (std::thread: available_parallelism implementation for vxWorks proposal.) - rust-lang#128309 (Implement cursors for `BTreeSet`) - rust-lang#128500 (Add test for updating enum discriminant through pointer) - rust-lang#128630 (docs(resolve): more explain about `target`) - rust-lang#128638 (run-make: enable msvc for `link-dedup`) r? `@ghost` `@rustbot` modify labels: rollup
…t, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` ````@rust-lang/types```` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#127655 (turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps`) - rust-lang#127907 (built-in derive: remove BYTE_SLICE_IN_PACKED_STRUCT_WITH_DERIVE hack and lint) - rust-lang#127974 (force compiling std from source if modified) - rust-lang#128309 (Implement cursors for `BTreeSet`) - rust-lang#128500 (Add test for updating enum discriminant through pointer) - rust-lang#128623 (Do not fire unhandled attribute assertion on multi-segment `AttributeType::Normal` attributes with builtin attribute as first segment) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#127655 - RalfJung:invalid_type_param_default, r=compiler-errors turn `invalid_type_param_default` into a `FutureReleaseErrorReportInDeps` `````@rust-lang/types````` I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error. However, turns out that outright removing it right now would lead to [tons of crater regressions](rust-lang#127655 (comment)), so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this. Fixes rust-lang#27336 by removing the feature gate (so there's no way to silence the lint even on nightly) CC rust-lang#36887
@rust-lang/types I assume the plan is still to disallow this? It has been a future-compat lint for a long time, seems ripe to go for hard error.
However, turns out that outright removing it right now would lead to tons of crater regressions, so for now this PR just makes this future-compat lint show up in cargo's reports, so people are warned when they use a dependency that is affected by this.
Fixes #27336 by removing the feature gate (so there's no way to silence the lint even on nightly)
CC #36887