-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
Regression in associated type checking for default impls #73818
Copy link
Copy link
Closed
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)C-bugCategory: This is a bug.Category: This is a bug.F-specialization`#![feature(specialization)]``#![feature(specialization)]`requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Metadata
Metadata
Assignees
Labels
A-associated-itemsArea: Associated items (types, constants & functions)Area: Associated items (types, constants & functions)C-bugCategory: This is a bug.Category: This is a bug.F-specialization`#![feature(specialization)]``#![feature(specialization)]`requires-nightlyThis issue requires a nightly compiler in some way. When possible, use a F-* label instead.This issue requires a nightly compiler in some way. When possible, use a F-* label instead.
Type
Fields
Give feedbackNo fields configured for issues without a type.
So I had a trait system in my (nightly) code for a while now that utilized specialization, but it no longer seems to be working after a recent update:
Now, I haven't been following the development of the specialization feature too closely, so it is possible that this is somehow actually intended and I am missing something. However, given that this previously compiled and ran just fine a couple weeks ago and given that the specialization incomplete warning was only added recently, I am inclined to think that it is probably a regression of some sort.
Meta things
compiler version: