Trait aliases: Also imply default trait bounds on type params other than Self#152688
Conversation
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
[WIP] Trait aliases: Imply default trait bounds
This comment has been minimized.
This comment has been minimized.
eff5e38 to
fdb25e1
Compare
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (ffd787c): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 0.2%, secondary 2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 482.657s -> 481.709s (-0.20%) |
Self
7269e75 to
f61aed1
Compare
SelfSelf
There was a problem hiding this comment.
My change only affects trait aliases since implied_predicates_with_filter is only ever called with filter PredicateFilter::All for trait aliases (namely in explicit_implied_predicates_of). Consequently, my PR won't affect stable behavior.
| ) -> Vec<(ty::Clause<'tcx>, Span)> { | ||
| let mut bounds = Vec::new(); | ||
|
|
||
| if let PredicateFilter::All = filter { |
There was a problem hiding this comment.
Predicates where the bounded type is a HIR type param obviously never qualify for PredicateFilter::{SelfOnly, SelfTraitThatDefines, SelfAndAssociatedTypeBounds, SelfConstIfConst}.
Regarding PredicateFilter::{SelfConstIfConst, ConstIfConst}, (1) these shouldn't be collected here anyway (const conditions are gathered elsewhere), (2) we don't have any default const or const-if-const trait bounds at the time of writing. Sure, we might have const Sized and const MetaSized in the future (open RFC 3729 | Sized Hierarchy) but then that should be dealt with when that part gets implemented imo.
As a result, PredicateFilter::All is the only filter that makes sense.
| trait B1<T: ?Sized> =; // has a default `T: MetaSized` bound | ||
| fn g1<T: std::marker::PointeeSized>() where (): B1<T> {} | ||
|
|
||
| // For completeness, let's also check default trait bounds on `Self`. |
There was a problem hiding this comment.
We do have tests that exercise add_implicit_sizedness_bounds in implied_predicates_with_filter, namely tests/ui/sized-hierarchy/bound-on-assoc-type-projection.rs and
tests/ui/sized-hierarchy/elaboration-simple.rs. However a trait alias specific one doesn't hurt imo.
|
r? types |
SelfSelf
|
@jackh726 Friendly ping, it's been 7 weeks and 3 days. The changes are trivial btw. |
There was a problem hiding this comment.
Apologies for the late review. I've been constantly trying to catch up on these.
So. do you know what PR added this implied behavior? I...almost think it's simpler/better to not imply default or explicit bounds on trait alias parameters. Perhaps, it's okay by me to land this, but I'd like to have a note of this behavior somewhere to ensure it gets revisited whenever we actually move towards trait alias stabilization.
Other, this looks good. Agreed that adding a test of the negative behavior here is good.
|
|
||
| #![feature(trait_alias, more_maybe_bounds, lang_items, auto_traits)] | ||
|
|
||
| #[lang = "default_trait1"] |
There was a problem hiding this comment.
Ha, this is funny that this exists.
I do agree that it's odd and surprising that parameter bounds get implied but I didn't feel like submitting a PR that drastically altered the semantics of trait aliases either, esp. since they're in limbo design-wise. However, if we were to stop implying parameter bounds, I think we should stop implying any predicates whose self type isn't
No, I haven't checked yet, I might do so later. Of course, the behavior is perfectly consistent right now (apart from default bounds) since it's very intentional I'm pretty sure that given e.g., (I do wonder though if trait aliases used to behave differently wrt. parameter bounds when they were first added. Maybe (I remember Niko expressing his disappointment in some trait alias RFC thread regarding the fact that in Rust we're syntactically conflating |
f61aed1 to
dce0935
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
dce0935 to
9d627dd
Compare
|
Thanks! @bors r+ |
|
@bors rollup |
Rollup of 5 pull requests Successful merges: - #149357 (Implement `-Z allow-partial-mitigations` (RFC 3855)) - #154939 (Refactor: simplify report_selection_error) - #152688 (Trait aliases: Also imply default trait bounds on type params other than `Self`) - #154352 (rustdoc: dep-info for standalone markdown inputs) - #155195 (tidy: handle `#[cfg_attr(bootstrap, doc = "...")]` in `compiler/` comments)
Rollup merge of #152688 - fmease:implied-preds-default-bounds, r=jackh726 Trait aliases: Also imply default trait bounds on type params other than `Self` Trait aliases already correctly imply default trait bounds on `Self` type params. However, due to an oversight, they didn't do that for normal type params. Fixes #152687.
View all comments
Trait aliases already correctly imply default trait bounds on
Selftype params. However, due to an oversight, they didn't do that for normal type params.Fixes #152687.