https://github.com/zygoloid commented:
Changes to the algorithm for selecting the most constrained function look
correct. It's not clear to me whether it's correct to stop calling
`CheckMemberSpecialization` for member templates, though -- do we still do the
necessary checks somewhere else?
@@ -7964,8 +7964,9 @@ NamedDecl *Sema::ActOnVariableDeclarator(
D.setRedeclaration(CheckVariableDeclaration(NewVD, Previous));
} else {
// If this is an explicit specialization of a static data member, check it.
-if (IsMemberSpecialization &&
@@ -10465,7 +10466,7 @@ Sema::ActOnFunctionDeclarator(Scope *S, Declarator ,
DeclContext *DC,
Previous))
NewFD->setInvalidDecl();
}
-} else if (isMemberSpecialization && isa(NewFD)) {
+} else if
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/101721
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1779,6 +1779,42 @@ void Parser::checkPotentialAngleBracket(ExprResult
) {
Priority);
}
+bool Parser::isMissingTemplateKeywordBeforeScope(bool AnnotateInvalid) {
+ assert(Tok.is(tok::coloncolon));
+ Sema::DisableTypoCorrectionRAII DTC(Actions);
+
zygoloid wrote:
> Please also update the documentation for the attribute and the release notes.
It looks like you may have overlooked the request to add release notes for this
new feature.
https://github.com/llvm/llvm-project/pull/100637
___
@@ -1779,6 +1779,42 @@ void Parser::checkPotentialAngleBracket(ExprResult
) {
Priority);
}
+bool Parser::isMissingTemplateKeywordBeforeScope(bool AnnotateInvalid) {
+ assert(Tok.is(tok::coloncolon));
+ Sema::DisableTypoCorrectionRAII DTC(Actions);
+
@@ -1779,6 +1779,42 @@ void Parser::checkPotentialAngleBracket(ExprResult
) {
Priority);
}
+bool Parser::isMissingTemplateKeywordBeforeScope(bool AnnotateInvalid) {
+ assert(Tok.is(tok::coloncolon));
+ Sema::DisableTypoCorrectionRAII DTC(Actions);
+
zygoloid wrote:
I think `__attribute__((cleanup))` on a variable should disable NRVO on that
variable, in both C and in C++. [GCC's
behavior](https://godbolt.org/z/Psbbr83ET) is to ignore the `cleanup` attribute
entirely if NRVO is applied to the variable, which seems like a flawed
approach,
zygoloid wrote:
> Typically, the absence of a statement must be interpreted as a lack of a
> guarantee. In this case, however, I would argue it is more plausible to infer
> that the ABI authors did not consider the possibility of passing a pointer to
> aliased memory for the return value, and
zygoloid wrote:
> Richard, I'm sorry to contradict you, but Aaron is correct to guess that this
> is ABI-affecting: ABIs should and sometimes do specify whether an indirect
> return address is allowed to be aliased.
My claim was narrowly that the choice to perform or not perform NRVO for an
zygoloid wrote:
NRVO vs not-NRVO is not an ABI difference, just a behavior difference -- it
doesn't change the calling convention, and different choices here are
link-compatible (in C++ we can make different choices for different emissions
of the same inline function even).
This is also not
@@ -5399,11 +5434,85 @@ static QualType
GetImplicitObjectParameterType(ASTContext ,
return Context.getLValueReferenceType(RawType);
}
+static TemplateDeductionResult FinishTemplateArgumentDeduction(
+Sema , FunctionTemplateDecl *FTD, int ArgIdx, QualType P, QualType A,
@@ -30,98 +30,27 @@ class basic_string_view {
constexpr basic_string_view =(const basic_string_view &) {}
};
-template
-constexpr bool operator<(basic_string_view, basic_string_view) {
- return {};
-}
-template
-constexpr bool operator<(type_identity_t>,
-
@@ -5399,11 +5434,85 @@ static QualType
GetImplicitObjectParameterType(ASTContext ,
return Context.getLValueReferenceType(RawType);
}
+static TemplateDeductionResult FinishTemplateArgumentDeduction(
+Sema , FunctionTemplateDecl *FTD, int ArgIdx, QualType P, QualType A,
@@ -859,8 +861,10 @@ class PackDeductionScope {
// by this pack expansion, then clear out the deduction.
DeducedFromEarlierParameter = !Deduced[Index].isNull();
DeducedPack Pack(Index);
-Pack.Saved = Deduced[Index];
-Deduced[Index] = TemplateArgument();
+
@@ -5399,11 +5434,85 @@ static QualType
GetImplicitObjectParameterType(ASTContext ,
return Context.getLValueReferenceType(RawType);
}
+static TemplateDeductionResult FinishTemplateArgumentDeduction(
+Sema , FunctionTemplateDecl *FTD, int ArgIdx, QualType P, QualType A,
@@ -5346,7 +5346,6 @@ static EvalStmtResult EvaluateStmt(StmtResult ,
EvalInfo ,
const Expr *RetExpr = cast(S)->getRetValue();
FullExpressionRAII Scope(Info);
if (RetExpr && RetExpr->isValueDependent()) {
- EvaluateDependentExpr(RetExpr, Info);
@@ -5425,34 +5534,112 @@ static bool isAtLeastAsSpecializedAs(Sema ,
SourceLocation Loc,
// the partial ordering is done:
TemplateDeductionInfo Info(Loc);
switch (TPOC) {
- case TPOC_Call:
+ case TPOC_Call: {
if (DeduceTemplateArguments(S, TemplateParams,
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Thanks!
https://github.com/llvm/llvm-project/pull/100692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6848,6 +6848,14 @@ CXXRecordMembersNamed(StringRef Name, Sema , QualType
Ty) {
return Results;
}
+QualType Sema::getTypeMember(QualType Type, StringRef Name) {
+ auto Results = CXXRecordMembersNamed(Name, *this, Type);
+ assert(Results.size() <= 1);
+ if
@@ -3058,6 +3058,133 @@ void Sema::NoteAllFoundTemplates(TemplateName Name) {
}
}
+static QualType commonTypeImpl(Sema , TemplateName BaseTemplate,
+ SourceLocation TemplateLoc,
+ ArrayRef Ts) {
+ auto
https://github.com/zygoloid commented:
How much of a performance difference are you measuring with this change?
https://github.com/llvm/llvm-project/pull/99473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/99473
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Seems logical and useful to me.
This PR will need more tests: specifically, please make sure you have test
coverage for the diagnostic, and for LLVM IR generation for both convergent
calls and convergent inline asm.
Please also update the documentation
zygoloid wrote:
It looks like this is working for all other kinds of structured binding because
`EmitDeclare(BindingDecl*, ...)` emits a proper `DILocalVariable` for them. But
it skips `BindingDecl`s that have a holding variable for some reason. Perhaps a
cleaner approach would be to make it
@@ -5824,12 +5824,23 @@ FunctionDecl
*Sema::getMoreConstrainedFunction(FunctionDecl *FD1,
FunctionDecl *FD2) {
assert(!FD1->getDescribedTemplate() && !FD2->getDescribedTemplate() &&
"not for function templates");
-
zygoloid wrote:
Hmm. See https://lists.isocpp.org/core/2024/06/15952.php -- I think we should
never be comparing constraints between functions whose signatures aren't
otherwise the same, and in particular we should never compare the constraints
of a conversion function template against the
@@ -10339,24 +10339,53 @@ Sema::CheckMemberSpecialization(NamedDecl *Member,
LookupResult ) {
if (Previous.empty()) {
// Nowhere to look anyway.
} else if (FunctionDecl *Function = dyn_cast(Member)) {
+SmallVector Candidates;
+bool Ambiguous = false;
for
zygoloid wrote:
Are we also missing the test coverage that would have caught the regression?
https://github.com/llvm/llvm-project/pull/100438
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -49,7 +48,24 @@
#define __need_rsize_t
#endif
#define __need_wchar_t
+#if !defined(__STDDEF_H) || __has_feature(modules)
+/*
+ * __stddef_null.h is special when building without modules: if __need_NULL is
+ * set, then it will unconditionally redefine NULL. To avoid
@@ -49,7 +48,24 @@
#define __need_rsize_t
#endif
#define __need_wchar_t
+#if !defined(__STDDEF_H) || __has_feature(modules)
+/*
+ * __stddef_null.h is special when building without modules: if __need_NULL is
+ * set, then it will unconditionally redefine NULL. To avoid
@@ -49,7 +48,24 @@
#define __need_rsize_t
#endif
#define __need_wchar_t
+#if !defined(__STDDEF_H) || __has_feature(modules)
+/*
+ * __stddef_null.h is special when building without modules: if __need_NULL is
+ * set, then it will unconditionally redefine NULL. To avoid
@@ -49,7 +48,25 @@
#define __need_rsize_t
#endif
#define __need_wchar_t
+#if !defined(__STDDEF_H) && !__building_module(_Builtin_stddef)
zygoloid wrote:
I'm not sure that the second condition here makes any difference: I'd think the
only way we could get
zygoloid wrote:
As noted in one of the inline comments, it doesn't seem good to be losing a
diagnostic for ill-formed code. But this all makes sense to me as a step to
make our behavior more consistent. I wonder if it'd make sense to make our
folding behavior stricter by default as a
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/99579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2849,19 +2849,23 @@ static bool handleIntIntBinOp(EvalInfo , const
BinaryOperator *E,
if (SA != RHS) {
Info.CCEDiag(E, diag::note_constexpr_large_shift)
<< RHS << E->getType() << LHS.getBitWidth();
+ if (!Info.noteUndefinedBehavior())
+
@@ -200,14 +200,7 @@ namespace LongInt {
};
enum shiftof {
-X = (1<<-29), // all-error {{expression is not an integral constant
expression}} \
- // all-note {{negative shift count -29}}
-
-X2 = (-1<<29), // cxx17-error {{expression is not an integral
@@ -142,7 +142,7 @@ constexpr int arb(int n) { // expected-note {{declared
here}}
expected-note {{function parameter 'n' with unknown value
cannot be used in a constant expression}}
}
constexpr long Overflow[(1 << 30) << 2]{}; // expected-warning {{requires 34
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/97425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/97128
The mangling compatibility being tested here changed between Clang 17 and 18,
not between 16 and 17, so change the "old" version to 17.
As requested by @ahatanak in [post-commit
zygoloid wrote:
> Discussion on the WG14 reflectors suggested that the qualifiers should still
> be stripped from the type of the controlling expression; the standard should
> be corrected to make this more clear.
Does WG14 think we're right to produce a qualified rvalue in this case? Another
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/96573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
> I have a question about the "sub-object" part. Do we attempt to discover the
> sub-object past any casting?
Good question. I'm going to merge this PR, so I've filed #96737 for this
ongoing discussion.
https://github.com/llvm/llvm-project/pull/96573
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
@@ -1392,7 +1392,8 @@ class CXXRecordDecl : public RecordDecl {
bool allowConstDefaultInit() const {
return !data().HasUninitializedFields ||
!(data().HasDefaultedDefaultConstructor ||
- needsImplicitDefaultConstructor());
+
@@ -4772,7 +4772,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// Build all the stores needed to initialize an aggregate at Dest with the
/// value Val.
zygoloid wrote:
This comment looks out of date.
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/96573
>From 3394d999888087535db9ede87668829eddc33ac7 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Mon, 24 Jun 2024 15:52:18 -0700
Subject: [PATCH 1/2] Add documentation for `__builtin_object_size`.
Explicitly
@@ -5368,16 +5368,85 @@ The ``#pragma comment(lib, ...)`` directive is
supported on all ELF targets.
The second parameter is the library name (without the traditional Unix prefix
of
``lib``). This allows you to provide an implicit link of dependent libraries.
-Evaluating
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/96573
Explicitly describe how the Clang builtin works, given that it's not exactly
the same as GCC's builtin of the same name -- but is drop-in compatible.
Fixes #95635.
>From
@@ -1392,7 +1392,8 @@ class CXXRecordDecl : public RecordDecl {
bool allowConstDefaultInit() const {
return !data().HasUninitializedFields ||
!(data().HasDefaultedDefaultConstructor ||
- needsImplicitDefaultConstructor());
+
@@ -141,3 +141,15 @@ namespace r360308_regression {
return a == b;
}
}
+
+namespace GH95598 {
+template
+struct __is_pointer {};
+// expected-warning@-1 {{keyword '__is_pointer' will be made available as an
identifier for the remainder of the translation unit}}
@@ -141,3 +141,15 @@ namespace r360308_regression {
return a == b;
}
}
+
+namespace GH95598 {
+template
+struct __is_pointer {};
+// expected-warning@-1 {{keyword '__is_pointer' will be made available as an
identifier for the remainder of the translation unit}}
@@ -141,3 +141,15 @@ namespace r360308_regression {
return a == b;
}
}
+
+namespace GH95598 {
+template
+struct __is_pointer {};
+// expected-warning@-1 {{keyword '__is_pointer' will be made available as an
identifier for the remainder of the translation unit}}
zygoloid wrote:
Perhaps we can start by supplying `CheckForModifiableLvalue` with extra
information about *why* we're doing the check. The current diagnostic we get
for incrementing a non-modifiable lvalue:
```console
:2:3: error: cannot assign to variable 'n' with const-qualified type
'const
@@ -13273,6 +13273,23 @@ enum {
ConstUnknown, // Keep as last element
};
+static void MaybeSuggestDerefFixIt(Sema , const Expr *E, SourceLocation Loc)
{
+ ExprResult Deref;
+ Expr *TE = const_cast(E);
+ {
+Sema::TentativeAnalysisScope Trap(S);
+Deref =
@@ -65,8 +65,10 @@ void test4(void) {
void test5(int *X, float *P) {
(float*)X = P; // expected-error {{assignment to cast is illegal, lvalue
casts are not supported}}
+ // expected-note@-1 {{add '*' to dereference it}}
zygoloid wrote:
This is a
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 -std=c++23 -fsyntax-only -verify %s
+
+struct S {
+ void f() {
+++this; // expected-error {{expression is not assignable}}
+// expected-note@-1 {{add '*' to dereference it}}
+ }
+
+ void g() const {
+++this; // expected-error
@@ -13273,6 +13273,23 @@ enum {
ConstUnknown, // Keep as last element
};
+static void MaybeSuggestDerefFixIt(Sema , const Expr *E, SourceLocation Loc)
{
+ ExprResult Deref;
+ Expr *TE = const_cast(E);
+ {
+Sema::TentativeAnalysisScope Trap(S);
+Deref =
@@ -65,8 +65,10 @@ void test4(void) {
void test5(int *X, float *P) {
(float*)X = P; // expected-error {{assignment to cast is illegal, lvalue
casts are not supported}}
+ // expected-note@-1 {{add '*' to dereference it}}
#define FOO ((float*) X)
FOO = P; //
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 -std=c++23 -fsyntax-only -verify %s
+
+struct S {
+ void f() {
+++this; // expected-error {{expression is not assignable}}
+// expected-note@-1 {{add '*' to dereference it}}
zygoloid wrote:
This is a bad diagnostic
https://github.com/zygoloid commented:
I have some significant concerns about the approach of this PR. It seems to be
producing notes that in a lot of cases suggest doing something that doesn't
make sense or won't compile, and tentatively building a `*p` expression is
unsafe.
Can we revert
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/94159
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2261,8 +2261,17 @@ bool Lexer::LexRawStringLiteral(Token , const
char *CurPtr,
unsigned PrefixLen = 0;
- while (PrefixLen != 16 && isRawStringDelimBody(CurPtr[PrefixLen]))
+ while (PrefixLen != 16 && isRawStringDelimBody(CurPtr[PrefixLen])) {
++PrefixLen;
+
zygoloid wrote:
> > I guess the general question is - is it acceptable to have the Scanner
> > operating in a language standard different than the passed in language mode
> > and different than the compiler language standard?
>
> I think that is acceptable. It is kinda hacky, but the lexer
@@ -77,3 +77,38 @@ namespace use_self {
int fib(int n) { return FibTree{n}.v; }
}
+
+namespace nested_union {
+ union Test1 {
+union {
+ int inner { 42 };
+};
+int outer;
+ };
+ static_assert(Test1{}.inner == 42, "");
+ struct Test2 {
+union {
+
https://github.com/zygoloid approved this pull request.
Looks good to me too.
https://github.com/llvm/llvm-project/pull/91692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -77,3 +77,38 @@ namespace use_self {
int fib(int n) { return FibTree{n}.v; }
}
+
+namespace nested_union {
+ union Test1 {
+union {
+ int inner { 42 };
+};
+int outer;
+ };
+ static_assert(Test1{}.inner == 42, "");
+ struct Test2 {
+union {
+
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/91692
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -152,16 +151,17 @@ LLVM_READONLY inline bool isHexDigit(unsigned char c) {
/// Note that '_' is both a punctuation character and an identifier character!
LLVM_READONLY inline bool isPunctuation(unsigned char c) {
using namespace charinfo;
- return (InfoTable[c] &
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/90303
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid approved this pull request.
Looks good. Do we also need to worry about overwriting tail padding here?
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/zygoloid approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/78060
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
I think we should go ahead with this. The behavior here is subtle but I think
it does make sense, and we're in the process of proposing this change to WG21.
https://github.com/llvm/llvm-project/pull/90820
___
zygoloid wrote:
> The immediate deprecation causes a few issues
On the one hand: waiting to deprecate something that we know we're going to
deprecate usually doesn't help anyone. We delay getting the message out to our
users, we sometimes forget to do it for the next release, and at best it
@@ -14,13 +14,18 @@ void __builtin_va_copy(double d);
// expected-error@+2 {{cannot redeclare builtin function '__builtin_va_end'}}
// expected-note@+1 {{'__builtin_va_end' is a builtin with type}}
void __builtin_va_end(__builtin_va_list);
-// RUN: %clang_cc1 %s -fsyntax-only
https://github.com/zygoloid approved this pull request.
Nothing further on my side, LGTM
https://github.com/llvm/llvm-project/pull/90842
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
zygoloid wrote:
> I'd like to proposal a separate PR for static analyzer. #91879 WDYT?
That sounds good to me.
https://github.com/llvm/llvm-project/pull/87933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -2433,6 +2429,30 @@ CFGBlock *CFGBuilder::VisitChildren(Stmt *S) {
return B;
}
+CFGBlock *CFGBuilder::VisitCXXDefaultArgExpr(CXXDefaultArgExpr *Arg,
+ AddStmtChoice asc) {
+ if (Arg->hasRewrittenInit()) {
+if
@@ -2433,6 +2429,30 @@ CFGBlock *CFGBuilder::VisitChildren(Stmt *S) {
return B;
}
+CFGBlock *CFGBuilder::VisitCXXDefaultArgExpr(CXXDefaultArgExpr *Arg,
+ AddStmtChoice asc) {
+ if (Arg->hasRewrittenInit()) {
+if
https://github.com/zygoloid approved this pull request.
Looks great!
I think it'd be good to understand what's happening with the static analyzer
test, and update the comment to explain. But given that this is fixing a
conformance / wrong code bug, I don't think we should block this PR on
@@ -711,6 +711,26 @@ void InitListChecker::FillInEmptyInitForField(unsigned
Init, FieldDecl *Field,
if (VerifyOnly)
return;
+ // Enter a lifetime extension context, then we can support lifetime
+ // extension of temporary created by aggregate
@@ -206,13 +206,10 @@ namespace cwg1814 { // cwg1814: yes
#endif
}
-namespace cwg1815 { // cwg1815: no
+namespace cwg1815 { // cwg1815: yes
zygoloid wrote:
A test for constant evaluation would be nice here too. Maybe:
```c++
struct C { const int = 0; };
@@ -10698,7 +10698,7 @@ C++ defect report implementation
status
https://cplusplus.github.io/CWG/issues/1815.html;>1815
CD4
Lifetime extension in aggregate initialization
-No
+Clang 19
zygoloid wrote:
```suggestion
Clang 19
```
We use
@@ -122,7 +122,7 @@ void aggregateWithReferences() {
clang_analyzer_dump(viaReference.ry); // expected-warning-re
{{_extended_object{Composite, viaReference, S{{[0-9]+}}} }}
// clang does not currently implement extending lifetime of object bound to
reference members of
@@ -269,6 +269,26 @@ void init_capture_init_list() {
// CHECK: }
}
+void check_dr1815() { // dr1815: yes
+#if __cplusplus >= 201402L
+
+ struct A {
+int & = 0;
+~A() {}
+ };
+
+ struct B {
+A & = A{};
+~B() {}
+ };
+
+ // CHECK: void
@@ -8194,25 +8216,18 @@ void Sema::checkInitializerLifetime(const
InitializedEntity ,
}
switch (shouldLifetimeExtendThroughPath(Path)) {
+ case PathLifetimeKind::ShouldExtend:
zygoloid wrote:
Do we need separate `ShouldExtend` and `Extend`
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/87933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Thanks for working on this.
https://github.com/llvm/llvm-project/pull/87933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Another possibility to consider: when [transforming a member
access](https://github.com/llvm/llvm-project/blob/ff210b94d449de8ebe1f32cf0d7763ba63b27b39/clang/lib/Sema/TreeTransform.h#L11950),
strip off any implicit member accesses from the base expression
zygoloid wrote:
> Note that the AST for the expression `T{}` looks like:
>
> ```
> // using T = int;
> CXXFunctionalCastExpr 'T':'int' functional cast to T
> `-InitListExpr 'T':'int'
> // using T = const int;
> CXXFunctionalCastExpr 'int' functional cast to T
> `-InitListExpr 'int'
> // using
@@ -8343,58 +8343,52 @@ bool
Sema::CheckTemplateTemplateArgument(TemplateTemplateParmDecl *Param,
// C++1z [temp.arg.template]p3: (DR 150)
// A template-argument matches a template template-parameter P when P
// is at least as specialized as the template-argument A.
zygoloid wrote:
> Unfortunately with this patch I'm still seeing the same
> source-location-exhausted error.
Can you try applying #89428 as well? I think we would need both in order to
prune the module map from the serialized SLocEntries.
https://github.com/llvm/llvm-project/pull/89005
https://github.com/zygoloid approved this pull request.
Thank you!
https://github.com/llvm/llvm-project/pull/89428
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1313,6 +1313,14 @@ OptionalFileEntryRef
HeaderSearch::LookupSubframeworkHeader(
// File Info Management.
//===--===//
+static bool
+headerFileInfoModuleBitsMatchRole(const HeaderFileInfo *HFI,
+
@@ -1313,6 +1313,14 @@ OptionalFileEntryRef
HeaderSearch::LookupSubframeworkHeader(
// File Info Management.
//===--===//
+static bool
+headerFileInfoModuleBitsMatchRole(const HeaderFileInfo *HFI,
+
1 - 100 of 3796 matches
Mail list logo
