riccibruno added a comment. In D60573#1463777 <https://reviews.llvm.org/D60573#1463777>, @rjmccall wrote:
> In D60573#1463641 <https://reviews.llvm.org/D60573#1463641>, @riccibruno > wrote: > > > In D60573#1463569 <https://reviews.llvm.org/D60573#1463569>, @rjmccall > > wrote: > > > > > Hmm. Does this never impact code that's just using a locally-defined > > > type within its scope? I guess if ADL is involved, unqualified lookup > > > must have reached the scope of the innermost namespace, and so it would > > > be searching that namespace anyway. > > > > > > In that case, I think I'm mollified that the source-compatibility risk is > > > low and we should just unconditionally apply the new rule. LGTM. > > > > > > I am not sure about what you mean. It is certainly possible to construct a > > piece of C++11 code which breaks with this patch. > > > Yes, but these examples are contrived, so it's easy to rationalize that the > source impact is low. The typical use-pattern of a local type is that you > only use it locally, so the most important question would be whether it is > possible to change the semantics of, say, > > void test() { > struct A { ... }; > foo(A{}); > } > > > But I think the answer is "no", for the reasons I explained. I can't imagine a way to change the result of the lookup for `foo` in an example like this without escaping the local type from the function. Thanks for the review ! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60573/new/ https://reviews.llvm.org/D60573 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
