Fortify generic param default checks #144977
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @davidtwco rustbot has assigned @davidtwco. Use |
rustbot
added
A-tidy
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
fmease
commented
Aug 5, 2025
| ItemKind::Fn { .. } | ItemKind::Impl(_) => ParamDefaultPolicy::FutureCompatForbidden, | ||
| // Re. GCI, we're not bound by backward compatibility. | ||
| ItemKind::Const(..) => ParamDefaultPolicy::Forbidden, | ||
| _ => return None, |
There was a problem hiding this comment.
I could exhaustively match on item.kind if you want me to.
| // compatibility, let's hard-reject defaults on them. | ||
| Node::ForeignItem(_) => ParamDefaultPolicy::Forbidden, | ||
| Node::OpaqueTy(..) => ParamDefaultPolicy::Allowed, | ||
| _ => return None, |
There was a problem hiding this comment.
Exhaustively matching on node: hir::Node doesn't really buy us much and it would be pretty overkill.
There was a problem hiding this comment.
I've combined tests/ui/type/default_type_parameter_in_fn_or_impl.rs and tests/ui/issues/issue-26812.rs into this file.
fmease
force-pushed
the
fortify-param-default-checks
branch
from
b51eb86 to
02ea38c
Compare
fmease
removed
T-bootstrap
fmease
commented
Aug 6, 2025
| } | ||
| GenericParamKind::Const { ty: _, default, synthetic } => { | ||
| if default.is_some() { | ||
| match param_default_policy.expect("no policy for generic param default") { |
There was a problem hiding this comment.
Of course, instead of panicking we could simply default to Forbidden (on master we default to FutureCompatForbidden which I heavily dislike). Just LMK :)
compiler-errors
approved these changes
Aug 6, 2025
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Aug 6, 2025
Rollup of 15 pull requests Successful merges: - #144195 (Parser: Recover from attributes applied to types and generic args) - #144794 (Port `#[coroutine]` to the new attribute system) - #144835 (Anonymize binders in tail call sig) - #144861 (Stabilize `panic_payload_as_str` feature) - #144917 (Enforce tail call type is related to body return type in borrowck) - #144948 (we only merge candidates for trait and normalizes-to goals) - #144956 (Gate const trait syntax) - #144970 (rustdoc: fix caching of intra-doc links on reexports) - #144972 (add code example showing that file_prefix treats dotfiles as the name of a file, not an extension) - #144975 (`File::set_times`: Update documentation and example to support setting timestamps on directories) - #144977 (Fortify generic param default checks) - #144996 (simplifycfg: Mark as changed when start is modified in collapse goto chain) - #144998 (mir: Do not modify NonUse in `super_projection_elem`) - #145000 (Remove unneeded `stage` parameter when setting up stdlib Cargo) - #145008 (Fix rustdoc scrape examples crash) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Aug 7, 2025
Rollup merge of #144977 - fmease:fortify-param-default-checks, r=compiler-errors Fortify generic param default checks * Hard-reject instead of lint-reject type param defaults in generic assoc consts (GACs) (feature: `generic_const_items`). * In #113522, I explicitly handled the free const item case and forgot about the assoc const one. * This led rustc to assume the default of emitting the deny-by-default lint `invalid_type_param_default`. * GCIs are unstable, thus we're not bound by backward compat * Hard-reject instead of lint-reject type param defaults in foreign items. * We already hard-reject generic params on foreign items, so this isn't a breaking change. * There's no reason why we need to lint-reject. * Refactor the way we determine where generic param defaults are allowed: * Don't default to emitting lint `invalid_type_param_defaults` for nodes that aren't explicitly handled but instead panic. * This would've caught my GAC oversight from above much earlier via fuzzing * Prevents us from accidentally stabilizing more invalid type param defaults in the future * Streamline the phrasing of the diagnostic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
generic_const_items).invalid_type_param_default.invalid_type_param_defaultsfor nodes that aren't explicitly handled but instead panic.