The patch itself LGTM. Doug: Are you OK with this? I don't recall if you wanted to wait until 3.1 shipped or until Portland :)
On Fri, Jun 1, 2012 at 5:36 PM, Aaron Ballman <[email protected]> wrote: > Ping? > > On Mon, May 28, 2012 at 6:33 PM, Aaron Ballman <[email protected]> wrote: >> On Thu, May 24, 2012 at 10:36 AM, Aaron Ballman <[email protected]> >> wrote: >>> On Thu, May 24, 2012 at 12:50 AM, Richard Smith <[email protected]> >>> wrote: >>>> On Tue, May 22, 2012 at 6:54 PM, Aaron Ballman <[email protected]> >>>> wrote: >>>>> >>>>> When a lambda expression omits the return type information, the >>>>> standard requires the lambda statement body to be a single return >>>>> statement. However, as a language extension, we (and several other >>>>> compilers) support determining the return type if all of the >>>>> function's return types agree. >>>>> >>>>> The problem is, the wording for the warning we emit is a bit difficult >>>>> to parse. It's a semantically correct statement, but it's not >>>>> immediately obvious what the problem is or how to rectify it. >>>>> Consider: >>>>> >>>>> auto i = []() { static const int foo = 12; return &foo; }(); >>>>> >>>>> This will emit a diagnostic that says "C++11 requires lambda with >>>>> omitted result type to consist of a single return statement" -- >>>>> however, a likely initial response to this is "but I do only have a >>>>> single return statement!" >>>>> >>>>> This patch rewords the diagnostic to be a bit more clear (hopefully): >>>>> "C++11 requires a lambda expression with omitted result type to >>>>> consist solely of a return statement" >>>>> >>>>> Thoughts? >>>> >>>> >>>> I would be in favor of removing the warning entirely, now that Clang 3.1 >>>> has >>>> shipped. The C++ core working group has already agreed that this should be >>>> allowed. It's currently under consideration by the evolution working group, >>>> whom I think are unlikely to say no -- and if they do, we will have time to >>>> react before 3.2 is released. >>> >>> That would certainly work as well -- is there a general preference one >>> way or the other? >>> >>> ~Aaron >> >> Here is a patch that removes the warning entirely as per Richard's >> suggestion -- any objections? >> >> ~Aaron _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
