-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
Specialization does not work correctly during constant evaluation. #66901
Copy link
Copy link
Closed
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)A-specializationArea: Trait impl specializationArea: Trait impl specializationC-bugCategory: This is a bug.Category: This is a bug.F-specialization`#![feature(specialization)]``#![feature(specialization)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.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-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)Area: Constant evaluation, covers all const contexts (static, const fn, ...)A-specializationArea: Trait impl specializationArea: Trait impl specializationC-bugCategory: This is a bug.Category: This is a bug.F-specialization`#![feature(specialization)]``#![feature(specialization)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.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.
A crate using specialization I've been working on seems to have broken sometime between
nightly-2019-11-19andnightly-2019-11-20. After a bit of debugging, it seems the issue is that specialization doesn't always work correctly in const contexts.This code, for example, returns the following:
On earlier versions, this would have returned the following:
This bug does not happen when the
-Z mir-opt-level=0flag is set, and it behaves the same as prior versions.