This is an archive of the discontinued LLVM Phabricator instance.

Support the overloadable attribute with _Generic expressions
ClosedPublic

Authored by aaron.ballman on Sep 1 2016, 12:37 PM.

Details

Summary

Currently, using a generic selection expression whose resulting associated expression is a function with the overloadable attribute crashes Clang. This patch supports properly resolving the overloaded function, which fixes PR30201 (https://llvm.org/bugs/show_bug.cgi?id=30201).

Diff Detail

Event Timeline

aaron.ballman retitled this revision from to Support the overloadable attribute with _Generic expressions.
aaron.ballman updated this object.
aaron.ballman added reviewers: rsmith, dblaikie.
aaron.ballman added subscribers: cfe-commits, nemanjai.

Just a drive-by nit. Thanks for the patch!

lib/Sema/SemaOverload.cpp
12996

Is there a reason this isn't a SmallVector instead?

rsmith edited edge metadata.Sep 1 2016, 8:31 PM

Lgtm other than George's nit.

aaron.ballman accepted this revision.Sep 2 2016, 6:54 AM
aaron.ballman added a reviewer: aaron.ballman.

Richard accepted, so claiming this as accepted so I can close it.

This revision is now accepted and ready to land.Sep 2 2016, 6:54 AM
aaron.ballman closed this revision.Sep 2 2016, 6:55 AM

Commit in r280483.

dblaikie added inline comments.Sep 2 2016, 7:44 AM
lib/Sema/SemaOverload.cpp
12996

Another note on this - we should generally prefer copy init over direct init (less power, less responsibility/easier to read):

std::vector<Expr*> AssocExprs = GSE->getAssocExprs().vec();

(& as for George's question: since ArrayRef::vec returns std::vector, it's cheaper to store in a std::vector (by move) than to make a copy into a SmallVector)

aaron.ballman added inline comments.Sep 2 2016, 7:47 AM
lib/Sema/SemaOverload.cpp
12996

Yeah, I originally used std::vector<> because of ArrayRef's interface. I am happy to go either route, depending on preference, as I doubt this will wind up on the hot path with any regularity.

lib/Sema/SemaOverload.cpp
12996

as for George's question: since ArrayRef::vec returns std::vector, it's cheaper to store in a std::vector (by move) than to make a copy into a SmallVector

I was thinking that we would end up using the SmallVector(begin(), end()) ctor instead, so the vector temp wouldn't be needed. :)

Regardless, it was just a nit, so I'm perfectly happy if it stays a vector.

I doubt this will wind up on the hot path with any regularity

Agreed.

aaron.ballman added inline comments.Sep 2 2016, 10:57 AM
lib/Sema/SemaOverload.cpp
12996

I was thinking that we would end up using the SmallVector(begin(), end()) ctor instead, so the vector temp wouldn't be needed. :)

I went that route, but didn't like requiring a local ArrayRef<Expr *> to prevent calling GSE->getAssocExprs() twice. There really is no convenient way to get a SmallVector from an ArrayRef, so perhaps another option would be to have a SmallVector constructor that accepts an ArrayRef, or have a way to get all of the elements as an llvm::iterator_range directly from an ArrayRef.