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).
Details
Diff Detail
Event Timeline
Just a drive-by nit. Thanks for the patch!
lib/Sema/SemaOverload.cpp | ||
---|---|---|
12996 | Is there a reason this isn't a SmallVector instead? |
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) |
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 |
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.
Agreed. |
lib/Sema/SemaOverload.cpp | ||
---|---|---|
12996 |
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. |
Is there a reason this isn't a SmallVector instead?