Commit Graph

16 Commits

Author SHA1 Message Date
Fangrui Song c79e6007ed Revert D119136 "[clang] Implement Change scope of lambda trailing-return-type" and its follow-up
This reverts commit 69dd89fdcb.
This reverts commit 04000c2f92.

The current states breaks libstdc++ usage (https://reviews.llvm.org/D119136#3455423).
The fixup has been reverted as it caused other valid code to be disallowed.
I think we should start from the clean state by reverting all relevant commits.
2022-04-20 10:57:12 -07:00
Corentin Jabot 69dd89fdcb [Clang] Fix references to captured variables in dependant context.
D119136 changed how captures are handled in a lambda call operator
declaration, but did not properly handled dependant context,
which led to crash when refering to init-captures in
a trailing return type.

We fix that bug by making transformations more symetric with parsing,
ie. we first create the call operator, then transform the capture,
then compute the type of the lambda call operaror.

This ensures captures exist and have the right type when
we parse a trailing requires-clause / return type.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D124012
2022-04-20 15:35:20 +02:00
David Blaikie aee4925507 Recommit: Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on
2bd8493847 with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4d5

Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-21 11:34:43 -07:00
David Blaikie f9ad1d1c77 Revert "Compress formatting of array type names (int [4] -> int[4])"
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)

This reverts commit 277623f4d5.
2021-10-14 14:49:25 -07:00
David Blaikie 277623f4d5 Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on
2bd8493847 with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).
2021-10-14 14:23:32 -07:00
Richard Smith 5a0e50cd87 DR1048: drop top-level cv-qualifiers when deducing the return type of a
lambda-expression in C++11, to match the C++14 rules.

llvm-svn: 224620
2014-12-19 22:10:51 +00:00
Faisal Vali 2b391ab708 Implement a rudimentary form of generic lambdas.
Specifically, the following features are not included in this commit:
  - any sort of capturing within generic lambdas 
  - generic lambdas within template functions and nested 
    within other generic lambdas
  - conversion operator for captureless lambdas
  - ensuring all visitors are generic lambda aware
  (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit)

As an example of what compiles through this commit:

template <class F1, class F2>
struct overload : F1, F2 {
    using F1::operator();
    using F2::operator();
    overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
  };

  auto Recursive = [](auto Self, auto h, auto ... rest) {
    return 1 + Self(Self, rest...);
  };
  auto Base = [](auto Self, auto h) {
      return 1;
  };
  overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
  int num_params =  O(O, 5, 3, "abc", 3.14, 'a');

Please see attached tests for more examples.

This patch has been reviewed by Doug and Richard.  Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). 



Some implementation notes:

  - Add a new Declarator context => LambdaExprParameterContext to 
    clang::Declarator to allow the use of 'auto' in declaring generic
    lambda parameters
      
  - Add various helpers to CXXRecordDecl to facilitate identifying
    and querying a closure class
  
  - LambdaScopeInfo (which maintains the current lambda's Sema state)
    was augmented to house the current depth of the template being
    parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
    so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately 
    generate a template-parameter-type when 'auto' is parsed in a generic
    lambda parameter context.  (i.e we do NOT use AutoType deduced to 
    a template parameter type - Richard seemed ok with this approach).  
    We encode that this template type was generated from an auto by simply
    adding $auto to the name which can be used for better diagnostics if needed.

  - SemaLambda.h was added to hold some common lambda utility
    functions (this file is likely to grow ...)
    
  - Teach Sema::ActOnStartOfFunctionDef to check whether it
    is being called to instantiate a generic lambda's call
    operator, and if so, push an appropriately prepared
    LambdaScopeInfo object on the stack.
    
  - various tests were added - but much more will be needed.

There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) 
have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData
in a future patch which is forthcoming.

A greatful thanks to all reviewers including Eli Friedman, James Dennett, 
and especially the two gracious wizards (Richard Smith and Doug Gregor) 
who spent hours providing feedback (in person in Chicago and on the mailing lists).  
And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified!

Thanks!

llvm-svn: 191453
2013-09-26 19:54:12 +00:00
Manuel Klimek 2fdbea2819 Revert "Implement a rudimentary form of generic lambdas."
This reverts commit 606f5d7a99b11957e057e4cd1f55f931f66a42c7.

llvm-svn: 189004
2013-08-22 12:12:24 +00:00
Faisal Vali fd5277c063 Implement a rudimentary form of generic lambdas.
Specifically, the following features are not included in this commit:
  - any sort of capturing within generic lambdas 
  - nested lambdas
  - conversion operator for captureless lambdas
  - ensuring all visitors are generic lambda aware


As an example of what compiles:

template <class F1, class F2>
struct overload : F1, F2 {
    using F1::operator();
    using F2::operator();
    overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
  };

  auto Recursive = [](auto Self, auto h, auto ... rest) {
    return 1 + Self(Self, rest...);
  };
  auto Base = [](auto Self, auto h) {
      return 1;
  };
  overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
  int num_params =  O(O, 5, 3, "abc", 3.14, 'a');

Please see attached tests for more examples.

Some implementation notes:

  - Add a new Declarator context => LambdaExprParameterContext to 
    clang::Declarator to allow the use of 'auto' in declaring generic
    lambda parameters
    
  - Augment AutoType's constructor (similar to how variadic 
    template-type-parameters ala TemplateTypeParmDecl are implemented) to 
    accept an IsParameterPack to encode a generic lambda parameter pack.
  
  - Add various helpers to CXXRecordDecl to facilitate identifying
    and querying a closure class
  
  - LambdaScopeInfo (which maintains the current lambda's Sema state)
    was augmented to house the current depth of the template being
    parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
    so that Sema::ActOnLambdaAutoParameter may use it to create the 
    appropriate list of corresponding TemplateTypeParmDecl for each
    auto parameter identified within the generic lambda (also stored
    within the current LambdaScopeInfo).  Additionally, 
    a TemplateParameterList data-member was added to hold the invented
    TemplateParameterList AST node which will be much more useful
    once we teach TreeTransform how to transform generic lambdas.
    
  - SemaLambda.h was added to hold some common lambda utility
    functions (this file is likely to grow ...)
    
  - Teach Sema::ActOnStartOfFunctionDef to check whether it
    is being called to instantiate a generic lambda's call
    operator, and if so, push an appropriately prepared
    LambdaScopeInfo object on the stack.
    
  - Teach Sema::ActOnStartOfLambdaDefinition to set the
    return type of a lambda without a trailing return type
    to 'auto' in C++1y mode, and teach the return type
    deduction machinery in SemaStmt.cpp to process either
    C++11 and C++14 lambda's correctly depending on the flag.    

  - various tests were added - but much more will be needed.

A greatful thanks to all reviewers including Eli Friedman,  
James Dennett and the ever illuminating Richard Smith.  And 
yet I am certain that I have allowed unidentified bugs to creep in; 
bugs, that I will do my best to slay, once identified!

Thanks!

llvm-svn: 188977
2013-08-22 01:49:11 +00:00
Richard Smith 1836e60023 Handle a difference in lambda return type deduction between C++11 and C++1y: if
no return type is specified, C++11 will deduce a cv-qualified return type in
some cases, but C++1y never will.

llvm-svn: 187275
2013-07-26 23:45:07 +00:00
Richard Smith 9155be1e54 C++1y: provide full 'auto' return type deduction for lambda expressions. This
completes the implementation of N3638.

llvm-svn: 181669
2013-05-12 03:09:35 +00:00
Aaron Ballman 8d4688718b Fixes some test cases that should have come along with r157943.
llvm-svn: 157947
2012-06-04 20:07:46 +00:00
Douglas Gregor b9e38f19f7 Specialize the diagnostic complaining about conflicting types of
return statements within a lambda; this diagnostic previously referred
to blocks.

llvm-svn: 150584
2012-02-15 15:57:22 +00:00
Douglas Gregor 621003e7b9 Check the return type of lambda expressions.
llvm-svn: 150503
2012-02-14 21:20:44 +00:00
Douglas Gregor 940a550f0d Don't allow deduction of a lambda result type from an initializer
list; it is not an expression.

llvm-svn: 150194
2012-02-09 18:40:39 +00:00
Douglas Gregor 7345626a5b Implement return type deduction for lambdas per C++11
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.

llvm-svn: 150168
2012-02-09 10:18:50 +00:00