jdoerfert added a comment. In D71241#1787652 <https://reviews.llvm.org/D71241#1787652>, @hfinkel wrote:
> In D71241#1787571 <https://reviews.llvm.org/D71241#1787571>, @ABataev wrote: > > > In D71241#1787265 <https://reviews.llvm.org/D71241#1787265>, @hfinkel wrote: > > > > > In D71241#1786959 <https://reviews.llvm.org/D71241#1786959>, @jdoerfert > > > wrote: > > > > > > > In D71241#1786530 <https://reviews.llvm.org/D71241#1786530>, @ABataev > > > > wrote: > > > > > > > > > Most probably, we can use this solution without adding a new > > > > > expression. `DeclRefExpr` class can contain 2 decls: FoundDecl and > > > > > the Decl being used. You can use FoundDecl to point to the original > > > > > function and used decl to point to the function being called in this > > > > > context. But at first, we need to be sure that we can handle all > > > > > corner cases correctly. > > > > > > > > > > > > What new expression are you talking about? > > > > > > > > > To be clear, I believe he's talking about the new expression that I > > > proposed we add in order to represent this kind of call. If that's not > > > needed, and we can use the FoundDecl/Decl pair for that purpose, that > > > should also be considered. > > > > > > > This solution already does point to both declarations, as shown here: > > > > https://reviews.llvm.org/D71241#1782504 > > > > > > Exactly. We need to check if the `MemberRefExpr` can do this too to handle > > member functions correctly. > > And need to wait for opinion from Richard Smith about the design. We need > > to be sure that it won't break compatibility with C/C++ in some corner > > cases. Design bugs are very hard to solve and I want to be sure that we > > don't miss anything. And we provide full compatibility with both C and C++. > > > We do need to be careful here. For cases with FoundDecl != Decl, I think that > the typo-correction cases look like they probably work, but there are a few > places where we make semantic decisions based on the mismatch, such as: > > In SemaTemplate.cpp below line 512, we have (this is in C++03-specific code): > > } else if (!Found.isSuppressingDiagnostics()) { > // - if the name found is a class template, it must refer to the same > // entity as the one found in the class of the object expression, > // otherwise the program is ill-formed. > if (!Found.isSingleResult() || > getAsTemplateNameDecl(Found.getFoundDecl())->getCanonicalDecl() != > OuterTemplate->getCanonicalDecl()) { > Diag(Found.getNameLoc(), > diag::ext_nested_name_member_ref_lookup_ambiguous) > > > and in SemaExpr.cpp near line 2783, we have: > > // If we actually found the member through a using declaration, cast > // down to the using declaration's type. > // > // Pointer equality is fine here because only one declaration of a > // class ever has member declarations. > if (FoundDecl->getDeclContext() != Member->getDeclContext()) { > assert(isa<UsingShadowDecl>(FoundDecl)); > QualType URecordType = Context.getTypeDeclType( > cast<CXXRecordDecl>(FoundDecl->getDeclContext())); Could you specify what behavior you expect, or what the test casees would look like? For the record: OpenMP basically says, if you have a call to a (base)function that has variants with contexts that match at the call site, call the variant with the highest score. The variants are specified by a //variant-func-id//, which is a base language identifier or C++ //template-id//. For C++, the variant declaration is identified by *performing the base language lookup rules on the //variant-func-id// with arguments that correspond to the base function argument types*. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D71241/new/ https://reviews.llvm.org/D71241 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
