This is an archive of the discontinued LLVM Phabricator instance.

[Concepts] Fix a deserialization crash.
ClosedPublic

Authored by hokein on Jul 23 2020, 12:36 PM.

Details

Summary

TemplateTypeParmDecl::hasTypeConstraint is not a safe guard for
checking TemplateTypeParmDecl::getTypeConstraint() result is null.

in somecases (e.g. implicit deduction guide templates synthesized from the
constructor), hasTypeConstraint returns true, and getTypeConstraint
returns a nullptr.

Fix https://bugs.llvm.org/show_bug.cgi?id=46790

Diff Detail

Event Timeline

hokein created this revision.Jul 23 2020, 12:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 23 2020, 12:36 PM
hokein edited the summary of this revision. (Show Details)Jul 23 2020, 12:43 PM

btw, getTypeConstraint and hasTypeConstraint APIs are quite easy to be misused (there is another similar bug in getAssociatedConstraints), I think we need to refine them (rename or so) to make them less confusing.

nridge accepted this revision.Jul 29 2020, 11:44 PM

btw, getTypeConstraint and hasTypeConstraint APIs are quite easy to be misused (there is another similar bug in getAssociatedConstraints), I think we need to refine them (rename or so) to make them less confusing.

Agreed, this seems a bit error-prone.

This revision is now accepted and ready to land.Jul 29 2020, 11:44 PM
This revision was automatically updated to reflect the committed changes.
aaronpuchert added a subscriber: aaronpuchert.EditedSep 1 2020, 5:09 PM

Do I understand correctly that this means we should have a template parameter, but haven't read it yet? In that case it would seem strange that we consider them different.

But I agree with you that hasTypeConstraint returning HasTypeConstraint and getTypeConstraint checking TypeConstraintInitialized makes the interface easy to misuse. Haven't seen anywhere in the AST a concept of having, but not having initialized a property—either it's there or not.