On Mon, Jul 21, 2014 at 3:25 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> Any advice on how to proceed here? > It seems this is genuinely not observable, but makes SCS a little bit more technically correct. I'm happy for you to commit this as a "refactoring". Or to just drop this patch. Your choice. :) Thanks! > > -- > Ehsan > <http://ehsanakhgari.org/> > > > On Mon, Jul 14, 2014 at 10:57 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> > wrote: > >> On Mon, Jul 14, 2014 at 10:39 PM, Richard Smith <rich...@metafoo.co.uk> >> wrote: >> >>> On Mon, Jul 14, 2014 at 5:15 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> >>> wrote: >>> >>>> On Sun, Jul 13, 2014 at 9:04 PM, Richard Smith <rich...@metafoo.co.uk> >>>> wrote: >>>> >>>>> The problem in PR20218 is visible in its notes: >>>>> >>>>> test.cpp(4,3) : note: candidate constructor [with X = int, Y = void ()] >>>>> pair(X&&, Y&&); >>>>> ^ >>>>> >>>>> This deduction is wrong. We should get Y = void (&)(). Presumably the >>>>> 'deduce an lvalue reference if an rvalue reference to T binds to an >>>>> lvalue' >>>>> rule isn't being applied appropriately in the case where the lvalue is an >>>>> overload set. >>>>> >>>> >>>> Thanks, Richard! Given the above, and also r212916, do we want to >>>> still take my patch here? >>>> >>> >>> Does it change the diagnostic in this case (from 'no overload [...]' to >>> 'no known conversion from 'void ()' to 'int'): >>> >>> template<typename T> void f(); >>> int g(int); >>> int k = g(f<int>); >>> >>> If so, please go ahead with that as a testcase. >>> >> >> No, both before and after, I get: >> >> $ ./bin/clang-cl -c test.cpp >> test.cpp(3,9) : error: no matching function for call to 'g' >> >> int k = g(f<int>); >> ^ >> test.cpp(2,5) : note: candidate function not viable: no overload of 'f' >> matching 'int' for 1st argument >> int g(int); >> ^ >> 1 error generated. >> >> >>> >>> -- >>>> Ehsan >>>> <http://ehsanakhgari.org/> >>>> >>>> >>>> >>>>> >>>>> On Tue, Jul 8, 2014 at 3:13 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com >>>>> > wrote: >>>>> >>>>>> On Tue, Jul 8, 2014 at 6:05 PM, Richard Smith <rich...@metafoo.co.uk> >>>>>> wrote: >>>>>> >>>>>>> On Sun, Jul 6, 2014 at 12:16 PM, Ehsan Akhgari < >>>>>>> ehsan.akhg...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi doug.gregor, >>>>>>>> >>>>>>>> If during constructing a standard conversion sequence, we resolve an >>>>>>>> overload, we need to adjust the from type in the SCS according to >>>>>>>> the >>>>>>>> resolved operator. >>>>>>>> >>>>>>>> I found this bug when debugging PR20218. It doesn't completely fix >>>>>>>> that >>>>>>>> test case though. >>>>>>>> >>>>>>> >>>>>>> The fix looks correct, but please provide some kind of test case for >>>>>>> this patch (even if it doesn't solve PR20218's test case). >>>>>>> >>>>>> >>>>>> I tried to do that, but I wasn't able to write a simpler test case >>>>>> similar to that of PR20218 which would have an observable outcome >>>>>> different >>>>>> after this patch... Any ideas how I can write a good test case for this? >>>>>> >>>>>> Thanks! >>>>>> -- >>>>>> Ehsan >>>>>> <http://ehsanakhgari.org/> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> http://reviews.llvm.org/D4402 >>>>>>>> >>>>>>>> Files: >>>>>>>> lib/Sema/SemaOverload.cpp >>>>>>>> >>>>>>>> Index: lib/Sema/SemaOverload.cpp >>>>>>>> =================================================================== >>>>>>>> --- lib/Sema/SemaOverload.cpp >>>>>>>> +++ lib/Sema/SemaOverload.cpp >>>>>>>> @@ -1462,6 +1462,7 @@ >>>>>>>> // We were able to resolve the address of the overloaded >>>>>>>> function, >>>>>>>> // so we can convert to the type of that function. >>>>>>>> FromType = Fn->getType(); >>>>>>>> + SCS.setFromType(FromType); >>>>>>>> >>>>>>>> // we can sometimes resolve &foo<int> regardless of ToType, >>>>>>>> so check >>>>>>>> // if the type matches (identity) or we are converting to >>>>>>>> bool >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cfe-commits mailing list >>>>>>>> cfe-commits@cs.uiuc.edu >>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
