Feature gate defaulted type parameters appearing outside of types #30724
Conversation
nikomatsakis
added
the
relnotes
| let future_incompat_lints = &lints.lint_groups[builtin::FUTURE_INCOMPATIBLE]; | ||
| let this_id = LintId::of(lint); | ||
| if future_incompat_lints.0.iter().any(|&id| id == this_id) { | ||
| let msg = "this lint will become a HARD ERROR in a future release!"; |
There was a problem hiding this comment.
ah cool, good to CSE this messaging in one place.
|
🙀 |
|
(graar i hate githubs presentation of the commit series) |
|
@bors r=pnkfelix |
|
📌 Commit 6dd3f61 has been approved by |
…eters, r=pnkfelix It was recently realized that we accept defaulted type parameters everywhere, without feature gate, even though the only place that we really *intended* to accept them were on types. This PR adds a lint warning unless the "type-parameter-defaults" feature is enabled. This should eventually become a hard error. This is a [breaking-change] in that new feature gates are required (or simply removing the defaults, which is probably a better choice as they have little effect at this time). Results of a [crater run][crater] suggest that approximately 5-15 crates are affected. I didn't do the measurement quite right so that run cannot distinguish "true" regressions from "non-root" regressions, but even the upper bound of 15 affected crates seems relatively minimal. [crater]: https://gist.github.com/nikomatsakis/760c6a67698bd24253bf cc @rust-lang/lang r? @pnkfelix
pnkfelix
added
the
beta-nominated
|
(I suspect we should not actually take any special effort to backport this to beta. But I'll leave the nominated tag to ensure that the team discusses it.) |
pnkfelix
added
the
T-lang
nikomatsakis
removed
the
beta-nominated
|
@nikomatsakis I object to removing defaults in Something like the following is working fine for me today. It also allows backwards compatible addition of type parameters just like for structs. trait IndexRange<T=usize> { fn start(&self) -> Option<T> }
fn index<R: IndexRange>(r: R) { ... } |
|
@bluss |
|
@petrochenkov Ok, that's great. Some of the messages need updating for that. |
|
Some functional programming with generics would benefit from having the default type parameters, provided that Since it is not yet enabled by default I will follow the recommendation and remove these defaults from Chomp. |
|
type parameter defaults seem to be going rather than coming to rust, what it looks like now, @m4rw3r |
…nt, r=brson
There is now more structure to the report, so that you can specify e.g. an RFC/PR/issue number and other explanatory details.
Example message:
```
type-parameter-invalid-lint.rs:14:8: 14:9 error: defaults for type parameters are only allowed on type definitions, like `struct` or `enum`
type-parameter-invalid-lint.rs:14 fn avg<T=i32>(_: T) {}
^
type-parameter-invalid-lint.rs:14:8: 14:9 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
type-parameter-invalid-lint.rs:14:8: 14:9 note: for more information, see PR 30742 <rust-lang#30724>
type-parameter-invalid-lint.rs:11:9: 11:28 note: lint level defined here
type-parameter-invalid-lint.rs:11 #![deny(future_incompatible)]
^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
```
r? @brson
I would really like feedback also on the specific messages!
Fixes rust-lang#30746
|
This should link to the tracking issue for default type parameter fallback: #27336 (now it does) |
Introduced in PR rust-lang#30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions Introduced in PR #30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions Introduced in PR rust-lang#30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Fix type parameter default error to mention type and trait definitions Introduced in PR rust-lang#30724, needs to mention that type parameter defaults are legal in trait and type definitions too.
Closes PistonDevelopers#996 - Removed draw_state dependency - Fixed [PR 30742](rust-lang/rust#30724) (default generic parameters will become a hard error)
Allow the [un]signed functions to return integers smaller than [iu]64 and also use the standard `byteorder` definitions of endianness rather than implementing our own enum type. Unfortunately, Rust functions are no longer allowed to have default type arguments (see PR 30724, rust-lang/rust#30724), so we still have to specify the endianness explicitly every time we use one of these functions. The may require wrapping inside a type...
It was recently realized that we accept defaulted type parameters everywhere, without feature gate, even though the only place that we really intended to accept them were on types. This PR adds a lint warning unless the "type-parameter-defaults" feature is enabled. This should eventually become a hard error.
This is a [breaking-change] in that new feature gates are required (or simply removing the defaults, which is probably a better choice as they have little effect at this time). Results of a crater run suggest that approximately 5-15 crates are affected. I didn't do the measurement quite right so that run cannot distinguish "true" regressions from "non-root" regressions, but even the upper bound of 15 affected crates seems relatively minimal.
cc @rust-lang/lang
r? @pnkfelix