[PATCH] D150075: Fix PR#62594 : static lambda call operator is not convertible to function pointer on win32

faisalv closed this revision. faisalv added a comment. Sorry about the delay - this patch has landed - https://github.com/llvm/llvm-project/commit/5bdd5d064d5171b2d5ff6268528cfffd2f86b8ea Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D92733: Fix PR25627 - false positive diagnostics involving implicit-captures in dependent lambda expressions.

faisalv added a comment. In D92733#4638319 , @cor3ntin wrote: > @Fznamznon This might be of interest to you > @faisalv are you still working on this? Yeah - sorry - been a little distracted with other stuff. I tried uploading an updated patch to

[PATCH] D150075: Fix PR#62594 : static lambda call operator is not convertible to function pointer on win32

faisalv created this revision. faisalv added reviewers: aaron.ballman, shafik, royjacobson. faisalv added a project: clang. Herald added a subscriber: pengfei. Herald added a project: All. faisalv requested review of this revision. Herald added a subscriber: cfe-commits. See issue

[PATCH] D92733: Fix PR25627 - false positive diagnostics involving implicit-captures in dependent lambda expressions.

faisalv added a comment. *ping* Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92733/new/ https://reviews.llvm.org/D92733 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D91821: Fix PR42049 - Crash when parsing bad decltype use within template argument list after name assumed to be a function template

faisalv updated this revision to Diff 309809. faisalv edited the summary of this revision. faisalv added a comment. Per Richard's suggestion, instead of including the cached tokens into the decltype annotation, i revert the cache to match the end of where we think the (broken) decltype

[PATCH] D92733: Fix PR25627 - false positive diagnostics involving implicit-captures in dependent lambda expressions.

faisalv created this revision. faisalv added reviewers: rsmith, aaron.ballman, wchilders, BRevzin. faisalv added a project: clang. faisalv requested review of this revision. This patch attempts to address the following bugs involving lambda-captures: 1.

[PATCH] D91651: [clang] Add a warning (à la gcc) for too small enum bitfields

faisalv added a comment. In D91651#2416423 , @thakis wrote: > Do you have any numbers on false positives / true positives uncovered by this > tweak? That's a great question - and unfortunately not only do I have no hard data to support or discourage

[PATCH] D91651: [clang] Add a warning (à la gcc) for too small enum bitfields

faisalv requested review of this revision. faisalv marked 4 inline comments as done. faisalv added a comment. *ping* Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91651/new/ https://reviews.llvm.org/D91651

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv closed this revision. faisalv added a comment. committed here: https://github.com/llvm/llvm-project/commit/9930d4dff31a130890f21a64f43d530a83ae3d0a Thank you Aaron, Richard and Wyat!! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv added a comment. *ping* Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91035/new/ https://reviews.llvm.org/D91035 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D91821: Fix PR42049 - Crash when parsing bad decltype use within template argument list after name assumed to be a function template

faisalv created this revision. faisalv added a reviewer: rsmith. faisalv added a project: clang. Herald added a subscriber: cfe-commits. faisalv requested review of this revision. https://bugs.llvm.org/show_bug.cgi?id=42049 Currently clang, in the following code, when tentatively parsing the

[PATCH] D91651: [clang] Add a warning (à la gcc) for too small enum bitfields

faisalv planned changes to this revision. faisalv marked 3 inline comments as done. faisalv added inline comments. Comment at: clang/lib/Sema/SemaDecl.cpp:16443-16446 + const unsigned BitsNeeded = + IsSignedEnum + ? std::max(ED->getNumPositiveBits() +

[PATCH] D91651: [clang] Add a warning (à la gcc) for too small enum bitfields

faisalv updated this revision to Diff 305970. faisalv added a comment. Based on Richards Feedback, this update includes the following changes: - avoids calling the fragile getZextValue() for comparing against bit-field width, and uses APSInt's comparison operator overload - suppresses/avoids

[PATCH] D91651: [clang] Add a warning (à la gcc) for too small enum bitfields

faisalv created this revision. faisalv added reviewers: aaron.ballman, wchilders, bruno, rnk, BRevzin, thakis. faisalv added a project: clang. faisalv requested review of this revision. Currently clang warns on 'assigning' to an enum bit-field that can not accommodate all its enumerators - but

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv updated this revision to Diff 305317. faisalv added a comment. This diff makes the following changes to the previous patch (based on feedback from Richard, Aaron and Wyatt): - avoid introducing an initialism (FDK) into the clang namespace and unabbreviated each corresponding use to

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv updated this revision to Diff 305020. faisalv added a comment. This revision includes the following changes to the initial patch: - revert the bit-field to unsigned from enum (so as to avoid that nettlesome gcc warning) - specified a fixed underlying type of 'unsigned char' for the enum

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv added inline comments. Comment at: clang/include/clang/Sema/DeclSpec.h:1837 /// Actually a FunctionDefinitionKind. - unsigned FunctionDefinition : 2; + FunctionDefinitionKind FunctionDefinition : 2; aaron.ballman wrote: > faisalv wrote: > >

[PATCH] D91011: [NFC, Refactor] Rename the (scoped) enum DeclaratorContext's enumerators to avoid redundancy

faisalv closed this revision. faisalv added a comment. Committed: https://github.com/llvm/llvm-project/commit/e4d27932a59fb61aaba3ff7a3ccd1b5bc9215fb9 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91011/new/ https://reviews.llvm.org/D91011

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv added a comment. In D91035#2383167 , @wchilders wrote: > Generally agree with this direction; Are there plans for migrating > https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Basic/Specifiers.h > in a similar fashion, for

[PATCH] D91035: [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum

faisalv created this revision. faisalv added reviewers: aaron.ballman, bruno, BRevzin, wchilders. faisalv added a project: clang. faisalv requested review of this revision. [NFC, Refactor] Convert FunctionDefinitionKind from DeclSpech.h to a scoped enum Repository: rG LLVM Github Monorepo

[PATCH] D91011: [NFC, Refactor] Rename the (scoped) enum DeclaratorContext enumerator's to avoid redundancy

faisalv created this revision. faisalv added reviewers: aaron.ballman, bruno. Herald added a project: clang. Herald added a subscriber: cfe-commits. faisalv requested review of this revision. Since these are scoped enumerators, they have to be prefixed by DeclaratorContext, so lets remove

[PATCH] D45194: [Sema] Defer checking constexpr lambda until after we've finished the lambda class.

faisalv added a comment. LGTM - can you commit? Thank you! Comment at: clang/lib/AST/ExprConstant.cpp:4313 +// We're in a lambda; determine the lambda capture field maps unless we're +// just constexpr checking a lambda's call operator. constexpr checking is +//

[PATCH] D45194: [Sema] Defer checking constexpr lambda until after we've finished the lambda class.

faisalv added a comment. Thanks Erik! Comment at: clang/lib/AST/ExprConstant.cpp:4312 + } else if (MD && isLambdaCallOperator(MD) + && !Info.checkingPotentialConstantExpression()) { // We're in a lambda; determine the lambda capture field maps.

[PATCH] D45194: [Sema] Defer checking constexpr lambda until after we've finished the lambda class.

faisalv added a comment. Thanks for working on this fairly embarrassing bug (let's fix this before the week is over :) Comment at: clang/lib/Sema/SemaDecl.cpp:12886 if (!IsInstantiation && FD && FD->isConstexpr() && !FD->isInvalidDecl() && +

[PATCH] D40381: Parse concept definition

faisalv added a comment. I discussed this briefly w Hubert - and i'm planning on modifying this patch slightly so that it flows through ParseDeclSpecifier and handles attributes and other invalid decl-specifiers such as static etc. more gracefully on a concept decl. I have this partially

[PATCH] D41217: [Concepts] Concept Specialization Expressions

faisalv added inline comments. Comment at: include/clang/AST/ExprCXX.h:4416 +/// According to C++2a [expr.prim.id]p3 an id-expression that denotes the +/// specialization of a concepts results in a prvalue of type bool. +class ConceptSpecializationExpr final : public Expr {

[PATCH] D41179: [Sema] Diagnose template specializations with C linkage

faisalv added a comment. In https://reviews.llvm.org/D41179#964522, @miyuki wrote: > In https://reviews.llvm.org/D41179#957992, @sepavloff wrote: > > > Classes do not have language linkage according to 10.5p1, just as > > templates, so this code is valid. > > > > It looks like defining

[PATCH] D40381: Parse concept definition

faisalv added inline comments. Comment at: lib/Parse/ParseTemplate.cpp:181 +TemplateParameterList *TPL = ParamLists[0]; +if (TPL->getLAngleLoc().getLocWithOffset(1) == TPL->getRAngleLoc()) { + Diag(TPL->getTemplateLoc(), changyu wrote: > There's one

[PATCH] D40381: Parse concept definition

faisalv added a comment. I think this looks good enough to commit - do you have commit privileges - or do you need one of us to commit it for you? thank you! https://reviews.llvm.org/D40381 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D40381: Parse concept definition

faisalv added inline comments. Comment at: lib/Sema/SemaTemplate.cpp:7735 + ActOnDocumentableDecl(NewDecl); + CurContext->addDecl(NewDecl); + return NewDecl; changyu wrote: > faisalv wrote: > > Why not use 'PushOnScopeChains' onto the enclosing scope? > >

[PATCH] D40705: Diagnose invalid decl-specifiers in non-type template parameter declarations (original author miyuki!)

faisalv closed this revision. faisalv added a comment. Added via https://reviews.llvm.org/rC321339 Repository: rC Clang https://reviews.llvm.org/D40705 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D40705: Diagnose invalid decl-specifiers in non-type template parameter declarations (original author miyuki!)

faisalv updated this revision to Diff 127828. faisalv retitled this revision from "[Parser] Diagnose storage classes in template parameter declarations" to "Diagnose invalid decl-specifiers in non-type template parameter declarations (original author miyuki!)". faisalv edited the summary of this

[PATCH] D40705: [Parser] Diagnose storage classes in template parameter declarations

faisalv added a comment. Sounds good - if I don't get this done over the next seven days - would you mind just pinging me! Thanks! https://reviews.llvm.org/D40705 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D40705: [Parser] Diagnose storage classes in template parameter declarations

faisalv requested changes to this revision. faisalv added a comment. This revision now requires changes to proceed. Hmm - I think i might make some tweaks to this patch (to be largely symmetric with the similar handling of invalid decl-specifiers on function parameters in

[PATCH] D41179: [Sema] Diagnose template specializations with C linkage

faisalv added inline comments. Comment at: lib/Sema/SemaTemplate.cpp:7029 + } + // C++ [temp.expl.spec]p2: What do you think about factoring this out into a separate function that is then called both from here and CheckTemplateDeclScope (since it is exactly

[PATCH] D40381: Parse concept definition

faisalv requested changes to this revision. faisalv added inline comments. This revision now requires changes to proceed. Comment at: lib/Sema/SemaTemplate.cpp:3899 + // constraint expressions right now. + return Template->getConstraintExpr(); +} saar.raz

[PATCH] D40705: [Parser] Diagnose storage classes in template parameter declarations

faisalv accepted this revision. faisalv added a comment. This revision is now accepted and ready to land. Otherwise, I think this looks good enough to commit. Do you have commit access? If not, let me know when you're ready for me to commit it on your behalf ... Thank you for fixing this!

[PATCH] D40381: Parse concept definition

faisalv added a comment. Thanks for working on this! :) Comment at: include/clang/AST/DeclTemplate.h:3035 + SourceRange getSourceRange() const override LLVM_READONLY { +return SourceRange(getLocation(), getLocation()); + } why not just fix it now?

[PATCH] D41217: [Concepts] Concept Specialization Expressions

faisalv added inline comments. Comment at: lib/Parse/ParseExpr.cpp:223 ExprResult Parser::ParseConstraintExpression() { - // FIXME: this may erroneously consume a function-body as the braced - // initializer list of a compound literal - // - // FIXME: this may erroneously

[PATCH] D40705: [Parser] Diagnose storage classes in template parameter declarations

faisalv added inline comments. Comment at: lib/Parse/ParseTemplate.cpp:692 + // declaration. + auto ReportStorageClass = [&](SourceLocation Loc) { +if (ParamDecl.getIdentifier()) I tend to prefer explicit captures (unless you have a good reason?) -

[PATCH] D39166: [NFC] Add some assertions to placate my paranoia about sharing a variant bit across FunctionDecl and CXXDeductionGuideDecl - should I do this?

faisalv abandoned this revision. faisalv added a comment. Just added an additional bit-field to FunctionDecl in https://reviews.llvm.org/rL317984 Comment at: include/clang/AST/InlineDeclMembers.h:35 + +#endif //LLVM_CLANG_AST_INLINEDECLMEMBERS_H +

[PATCH] D39166: [NFC] Add some assertions to placate my paranoia about sharing a variant bit across FunctionDecl and CXXDeductionGuideDecl - should I do this?

faisalv updated this revision to Diff 120346. faisalv marked 4 inline comments as done. faisalv added a comment. Incorporated Aaron's feedback (although not sure if I caugh tall the white space issues). Additionally, I was thinking of reordering the bits - and using UseSEHTry (this bit really

[PATCH] D39166: [NFC] Add some assertions to placate my paranoia about sharing a variant bit across FunctionDecl and CXXDeductionGuideDecl - should I do this?

faisalv added a comment. In https://reviews.llvm.org/D39166#903131, @lichray wrote: > Isn't it already an UB if someone set `WillHaveBody` and but later > `IsCopyDeductionCandidate` being read, vice versa? Yes that would be UB - but I'm not sure I see how that would happen w the current

[PATCH] D39166: [NFC] Add some assertions to placate my paranoia about sharing a variant bit across FunctionDecl and CXXDeductionGuideDecl - should I do this?

faisalv created this revision. faisalv added a project: clang. Herald added a subscriber: eraman. I'd like to harden my patch here: https://reviews.llvm.org/rL316292 by adding some assertions. But since the assertions in Decl,.h (FunctionDecl) require knowledge from DeclCXX.h

[PATCH] D35782: [C++2a][Preprocessor] Implement p0306 __VA_OPT__ (Comma omission and comma deletion)

faisalv abandoned this revision. faisalv marked 12 inline comments as done. faisalv added a comment. committed as r315840. https://reviews.llvm.org/rL315840 Repository: rL LLVM https://reviews.llvm.org/D35782 ___ cfe-commits mailing list

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added a comment. In https://reviews.llvm.org/D36527#854883, @faisalv wrote: > > Interestingly we don't (explicitly) visit the lambda's function parameters? This is obviously false - sorry :) https://reviews.llvm.org/D36527 ___

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added a comment. In https://reviews.llvm.org/D36527#854600, @rsmith wrote: > This patch appears to be missing some necessary changes in the following > places: > > - lib/Serialization -- round-trip the new information through PCH / modules Shouldn't the explicit template parameter

[PATCH] D36915: [Sema] Diagnose local variables and parameters captured by lambda and block expressions in a default argument

faisalv added a comment. In https://reviews.llvm.org/D36915#854317, @ahatanak wrote: > In https://reviews.llvm.org/D36915#849622, @faisalv wrote: > > > I don't think this approach is entirely correct for at least the following > > reasons: > > > > 1. in the lambda case the machinery that

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/AST/ExprCXX.cpp:979 +SourceRange LambdaExpr::getExplicitTemplateParameterListRange() const { + TemplateParameterList *List = getTemplateParameterList(); hamzasood wrote: > faisalv wrote: > > I think this should

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added a comment. OK - I'll commit this on sunday if no one blocks it by then. (I'll add the fixme's). Nice Work! https://reviews.llvm.org/D36527 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/AST/ExprCXX.cpp:979 +SourceRange LambdaExpr::getExplicitTemplateParameterListRange() const { + TemplateParameterList *List = getTemplateParameterList(); I think this should return an invalid range if

[PATCH] D36915: [Sema] Diagnose local variables and parameters captured by lambda and block expressions in a default argument

faisalv added a comment. I don't think this approach is entirely correct for at least the following reasons: 1. in the lambda case the machinery that diagnoses capture failures should be the machinery erroring on the lambda (when the parameter is odr-used) 2. in the unevaluated case, once you

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/Parse/ParseExprCXX.cpp:1116 + if (HasExplicitTemplateParams) { +SmallVector TemplateParams; +SourceLocation LAngleLoc, RAngleLoc; hamzasood wrote: > faisalv wrote: > > hamzasood wrote: > > >

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/Sema/SemaLambda.cpp:858 +KnownDependent = CurScope->getTemplateParamParent() != nullptr; + } hamzasood wrote: > faisalv wrote: > > Hmm - now that you drew my attention to this ;) - I'm pretty sure this is >

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/Parse/ParseExprCXX.cpp:1116 + if (HasExplicitTemplateParams) { +SmallVector TemplateParams; +SourceLocation LAngleLoc, RAngleLoc; hamzasood wrote: > faisalv wrote: > > Why not Just use/pass

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added a comment. In regards to representing this in the AST - I think (based on precedence) that the number of explicit template parameters should be stored in LambdaDefinitionData - and the interface exposed through LambdaExpr (where the source information of the template parameter

[PATCH] D35782: [C++2a][Preprocessor] Implement p0306 __VA_OPT__ (Comma omission and comma deletion)

faisalv added a comment. *ping* Repository: rL LLVM https://reviews.llvm.org/D35782 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/Parse/ParseExprCXX.cpp:1090 + TemplateParameterDepthRAII CurTemplateDepthTracker(TemplateParameterDepth); + Actions.RecordParsingTemplateParameterDepth(TemplateParameterDepth); + hamzasood wrote: > faisalv wrote:

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added a comment. In regards to that failing test (that was added since review began) - could you fix that test pls (i.e. rename the nested ttp 'U' to something else) and move it into the function 'f' as requested by the author? Might want to include a similar (but not same) example of

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: include/clang/Sema/ScopeInfo.h:774 + /// \brief The number of parameters in the template parameter list that were + /// explicitely specified by the user, as opposed to being invented by use + /// of an auto parameter.

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

faisalv closed this revision. faisalv added a comment. Committed as r311224, on behalf of Hamza. https://reviews.llvm.org/rL311224 https://reviews.llvm.org/D36572 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: lib/Parse/ParseExprCXX.cpp:1112 + ParseScope TemplateParamScope(this, Scope::TemplateParamScope); + if (getLangOpts().CPlusPlus2a && Tok.is(tok::less)) { hamzasood wrote: > faisalv wrote: > > We always create a

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added inline comments. Comment at: include/clang/Sema/Sema.h:5466 + /// ActOnLambdaTemplateParameterList - This is called after parsing + /// the explicit template parameter list (if it exists) in C++2a. Avoid listing the name of the function:

[PATCH] D36527: Implemented P0428R2 - Familiar template syntax for generic lambdas

faisalv added a comment. I'll try and get you some feedback on this over the next couple of days (unless someone else jumps in). Thanks for working on this! https://reviews.llvm.org/D36527 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

faisalv accepted this revision. faisalv added a comment. This revision is now accepted and ready to land. OK - looks good enough to me. I say we give the rest of the reviewers until friday to chime in, and if no one blocks it, can you commit then? nice work - thanks!

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

faisalv added inline comments. Comment at: lib/Sema/SemaLambda.cpp:959 + ? diag::ext_equals_this_lambda_capture_cxx2a + : diag::warn_cxx1z_compat_equals_this_lambda_capture); Shouldn't we try and hit the

[PATCH] D35782: [C++2a][Preprocessor] Implement p0306 __VA_OPT__ (Comma omission and comma deletion)

faisalv updated this revision to Diff 109883. faisalv marked 7 inline comments as done. faisalv added a comment. Hi Richard, This patch attempts to incorporate all the changes you requested. You asked for some consideration on the rationale for sticking with my approach (as opposed to the

[PATCH] D35782: [C++2a][Preprocessor] Implement p0306 __VA_OPT__ (Comma omission and comma deletion)

faisalv created this revision. faisalv added a project: clang. This patch implements an extension to the preprocessor: __VA_OPT__ which expands into its contents if variadic arguments are supplied, or behaves as an empty token if none. - currently it is only enabled for C++2a (we could always

[PATCH] D35454: [c++2a] Add option -std=c++2a to enable support for potential/transitional C++2a features

faisalv closed this revision. faisalv marked an inline comment as done. faisalv added a comment. Committed here https://reviews.llvm.org/rL308118 Thanks! https://reviews.llvm.org/D35454 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D35454: [c++2a] Add option -std=c++2a to enable support for potential/transitional C++2a features

faisalv added a comment. Hmm - good point - not sure about the best way to confirm that... I'm fairly sure Jason said something during a discussion with me (about the additional template syntax to lambdas) in which he referred to gcc as already having a "C++2a feature" - and so i just inferred

[PATCH] D35454: [c++2a] Add option -std=c++2a to enable support for potential/transitional C++2a features

faisalv updated this revision to Diff 106777. faisalv added a comment. Remove some erroneously included fragments (patches to Sema) of a future potential patch. https://reviews.llvm.org/D35454 Files: include/clang/Basic/LangOptions.def include/clang/Frontend/LangStandard.h

[PATCH] D35454: [c++2a] Add option -std=c++2a to enable support for potential/transitional C++2a features

faisalv created this revision. faisalv added a project: clang. At the optimistic least, I'm hoping to get around to adding support for familiar template syntax to lambdas and vaopt to the preprocessor, under it. Repository: rL LLVM https://reviews.llvm.org/D35454 Files:

[PATCH] D31414: [NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjects

faisalv added a comment. *ping* https://reviews.llvm.org/D31414 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv closed this revision. faisalv added a comment. Committed here : https://reviews.llvm.org/rL303492 https://reviews.llvm.org/D31588 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D29748: [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.

faisalv closed this revision. faisalv added a comment. Closed by commit https://reviews.llvm.org/rL295279 https://reviews.llvm.org/D29748 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv accepted this revision. faisalv added a comment. This revision is now accepted and ready to land. Modified and committed as: http://llvm.org/viewvc/llvm-project?view=revision=303492 https://reviews.llvm.org/D31588 ___ cfe-commits mailing

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv added a comment. *ping* *ping* https://reviews.llvm.org/D31588 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv added a comment. *ping* https://reviews.llvm.org/D31588 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv updated this revision to Diff 96861. faisalv added a comment. Fixed a regression test that should have passed without emitting error diagnostics - and now does. https://reviews.llvm.org/D31588 Files: include/clang/Parse/Parser.h lib/Parse/ParseExpr.cpp

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv updated this revision to Diff 96858. faisalv marked 3 inline comments as done. faisalv added a comment. Updated the patch following Richard's feedback: - teach ParseConstantExpression to create its own ExpressionEvaluationContext only if asked to. https://reviews.llvm.org/D31588

[PATCH] D31588: Fix PR25627: Certain constant local variables must be usable as template arguments (without being odr-used)

faisalv created this revision. This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments, as if they were truly constant-expressions. Currently, trunk correctly disambiguates, and identifies the

[PATCH] D31414: [NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjects

faisalv updated this revision to Diff 93207. faisalv added a comment. Don't forget to destroy the trailing objects. https://reviews.llvm.org/D31414 Files: include/clang/Basic/TemplateKinds.h include/clang/Sema/ParsedTemplate.h lib/Parse/ParseExprCXX.cpp lib/Parse/ParseTemplate.cpp

[PATCH] D31414: [NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjects

faisalv created this revision. faisalv added a project: clang-c. Refactor TemplateIdAnnotation to use TrailingObjects and add assorted comments. Repository: rL LLVM https://reviews.llvm.org/D31414 Files: include/clang/Basic/TemplateKinds.h include/clang/Sema/ParsedTemplate.h

[PATCH] D29748: [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.

faisalv added inline comments. Comment at: lib/AST/ExprConstant.cpp:5061 + APValue RVal; + // FIXME: We need to make sure we're passing the right type that + // maintains cv-qualifiers. rsmith wrote: > faisalv wrote: > > I don't think

[PATCH] D29748: [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.

faisalv updated this revision to Diff 87943. faisalv marked 6 inline comments as done. faisalv added a comment. Incorporated Richard's feedback and added comments. https://reviews.llvm.org/D29748 Files: lib/AST/ExprConstant.cpp test/SemaCXX/cxx1z-constexpr-lambdas.cpp Index:

[PATCH] D29748: [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.

faisalv added inline comments. Comment at: lib/AST/ExprConstant.cpp:5061 + APValue RVal; + // FIXME: We need to make sure we're passing the right type that + // maintains cv-qualifiers. I don't think we need this fixme - the type of

[PATCH] D29748: [cxx1z-constexpr-lambda] Implement captures - thus completing implementation of constexpr lambdas.

faisalv created this revision. faisalv added a project: clang-c. Herald added a subscriber: EricWF. This patch attempts to enable evaluation of all forms of captures (however deeply nested) within constexpr lambdas. Appreciate the feedback. Thanks! Repository: rL LLVM

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

faisalv updated this revision to Diff 85927. faisalv added a comment. I tried a different approach, not because I was convinced it was better, but because it seemed (at the time) a simpler tweak - I'm not sure it is robust enough - but would appreciate your thoughts on it. The approach is

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

faisalv added a comment. In https://reviews.llvm.org/D28510#653794, @rsmith wrote: > I don't think it's possible to check this in the way you're doing so here. In > general, there's no way to know whether a constant expression will be part of > a `typedef` declaration or function declaration

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

faisalv updated this revision to Diff 84476. faisalv added a comment. The updated patch adds two additional enumerators to ExpressionEvaluationContext: ConstantEvaluatedInTemplateArgument and ConstantEvaluatedInFunctionSignature and sets them appropriately (as opposed to our previous approach

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

faisalv added inline comments. Comment at: include/clang/Sema/Sema.h:894-895 +/// \brief Whether lambda expressions are forbidden here. +bool IsLambdaExprForbidden; + rsmith wrote: > Rather than adding a flag, how about we have two different kinds of

[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

faisalv added a comment. Yes - I'll modify the patch to reflect that approach. Any thoughts on whether they should also be forbidden in Lamda parameter declaration clauses? Thanks! Repository: rL LLVM https://reviews.llvm.org/D28510 ___

[PATCH] D18510: [cxx1z-constexpr-lambda] Make conversion function constexpr

faisalv abandoned this revision. faisalv added a comment. See richard's comment for why this attempt at implementing a compatibility warning for the constexpr conversion operator for lambda's is being abandoned. https://reviews.llvm.org/D18510 ___

[PATCH] D22997: [cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the expression-evaluator to evaluate the static-invoker.

faisalv accepted this revision. faisalv added a reviewer: faisalv. faisalv added a comment. This revision is now accepted and ready to land. committed as https://reviews.llvm.org/rL291397 https://reviews.llvm.org/D22997 ___ cfe-commits mailing list

[PATCH] D22997: [cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the expression-evaluator to evaluate the static-invoker.

faisalv closed this revision. faisalv added a comment. Committed as https://reviews.llvm.org/rL291397 https://reviews.llvm.org/D22997 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits