@@ -951,28 +959,124 @@ Sema::ActOnDecompositionDeclarator(Scope *S, Declarator
&D,
return New;
}
+// CheckBindingsCount
+// - Checks the arity of the structured bindings
+// - Creates the resolved pack expr if there is
+//one
+static bool CheckBindingsCount(Sema &S, D
@@ -1099,6 +1099,13 @@ def err_lambda_capture_misplaced_ellipsis : Error<
"the name of the capture">;
def err_lambda_capture_multiple_ellipses : Error<
"multiple ellipses in pack capture">;
+def err_binding_multiple_ellipses : Error<
+ "multiple ellipses in structured bind
@@ -5321,6 +5321,59 @@ class BuiltinBitCastExpr final
}
};
+// Represents an unexpanded pack where the list of expressions are
+// known. These are used when structured bindings introduce a pack.
+class ResolvedUnexpandedPackExpr final
zygoloid wrote:
This
zygoloid wrote:
Oh, I see, you're suggesting we remove the `getStdNamespace` check from this
PR. Yeah, I think that's reasonable.
But I'd somewhat question whether this PR and warning really has anything to do
with the attribute names being "reserved" at that point -- we're not checking
wheth
@@ -2855,6 +2855,11 @@ class CXXDestructorDecl : public CXXMethodDecl {
return getCanonicalDecl()->OperatorDeleteThisArg;
}
+ /// Will this destructor ever be called when considering which deallocation
+ /// function is associated with the destructor? Can optionally be
https://github.com/zygoloid approved this pull request.
LG other than the function name.
https://github.com/llvm/llvm-project/pull/118800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/118800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
New flag name LGTM.
https://github.com/llvm/llvm-project/pull/11
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -412,6 +412,20 @@ New Compiler Flags
only for thread-local variables, and none (which corresponds to the
existing ``-fno-c++-static-destructors`` flag) skips all static
destructors registration.
+- The ``-fextend-variable-liveness`` flag has been added to allow for imp
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/11
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1200,21 +1200,35 @@ CanThrowResult Sema::canThrow(const Stmt *S) {
case Expr::CXXDeleteExprClass: {
auto *DE = cast(S);
-CanThrowResult CT;
+CanThrowResult CT = CT_Cannot;
QualType DTy = DE->getDestroyedType();
if (DTy.isNull() || DTy->isDependentTy
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/118800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/118800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
Did you mean a different issue than #119101? It's not clear to me what
connection this PR has to that issue.
It's not clear to me that there's an issue to be solved here. Under
`-pedantic-errors`, clang [already produces an
error](https://godbolt.org/z/h6oKarex9) on examples l
https://github.com/zygoloid approved this pull request.
LGTM too. I do wonder if we can make tablegen generate the data directly in the
desired format here (perhaps with some additional `.td` files to define exactly
which files we want to include in which targets and to define the placeholder
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/118800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3768,6 +3768,28 @@ Sema::ActOnCXXDelete(SourceLocation StartLoc, bool
UseGlobal,
DeclarationName DeleteName = Context.DeclarationNames.getCXXOperatorName(
ArrayForm ? OO_Array_Delete : OO_Delete);
+// C++20 [expr.delete]p6: If
zygoloid wrote:
As I just noted in #118687, I think we also need similar treatment for
`noexcept(delete p)`.
https://github.com/llvm/llvm-project/pull/118800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
zygoloid wrote:
Hm, the issue raised in #118800 is relevant here too, isn't it? If the
destructor is virtual, we want to look at its exception specification, not the
one on the destroying operator delete, because `delete p` actually invokes the
virtual deleting destructor, not the statically s
@@ -3768,6 +3768,28 @@ Sema::ActOnCXXDelete(SourceLocation StartLoc, bool
UseGlobal,
DeclarationName DeleteName = Context.DeclarationNames.getCXXOperatorName(
ArrayForm ? OO_Array_Delete : OO_Delete);
+// C++20 [expr.delete]p6: If
@@ -1206,15 +1206,16 @@ CanThrowResult Sema::canThrow(const Stmt *S) {
CT = CT_Dependent;
} else {
const FunctionDecl *OperatorDelete = DE->getOperatorDelete();
- CT = canCalleeThrow(*this, DE, OperatorDelete);
- if (const RecordType *RT = DTy->getAs()
@@ -1205,11 +1205,12 @@ CanThrowResult Sema::canThrow(const Stmt *S) {
if (DTy.isNull() || DTy->isDependentType()) {
CT = CT_Dependent;
} else {
- CT = canCalleeThrow(*this, DE, DE->getOperatorDelete());
+ const FunctionDecl *OperatorDelete = DE->getOper
@@ -654,6 +654,9 @@ Bug Fixes in This Version
- Fixed a crash when GNU statement expression contains invalid statement
(#GH113468).
- Fixed a failed assertion when using ``__attribute__((noderef))`` on an
``_Atomic``-qualified type (#GH116124).
+- No longer return ``false``
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/11
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
Looks like the tests in #110102 are named `extend-liveness-*.cpp`. Perhaps
`-fextend-liveness` would be a good name for this flag?
https://github.com/llvm/llvm-project/pull/11
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/zygoloid commented:
I think this flag name is going to be extremely confusing. "lifetime" is a
notion defined formally by the C++ language standard, and "lifetime extension"
is again a process defined in C++ with a specific meaning. Those meanings have
nothing to do with wha
Timm =?utf-8?q?Bäder?=
Message-ID:
In-Reply-To:
@@ -14548,8 +14548,21 @@ bool IntExprEvaluator::VisitBinaryOperator(const
BinaryOperator *E) {
return Error(E);
const Expr *LHSExpr = LHSValue.Base.dyn_cast();
const Expr *RHSExpr = RHSValue.Base.dyn_cast()
@@ -91,11 +91,15 @@ def note_constexpr_pointer_subtraction_zero_size : Note<
"subtraction of pointers to type %0 of zero size">;
def note_constexpr_pointer_comparison_unspecified : Note<
"comparison between '%0' and '%1' has unspecified value">;
+def note_constexpr_pointer_
@@ -14548,8 +14548,21 @@ bool IntExprEvaluator::VisitBinaryOperator(const
BinaryOperator *E) {
return Error(E);
const Expr *LHSExpr = LHSValue.Base.dyn_cast();
const Expr *RHSExpr = RHSValue.Base.dyn_cast();
- if (!LHSExpr || !RHSExpr)
-return
@@ -14548,8 +14548,21 @@ bool IntExprEvaluator::VisitBinaryOperator(const
BinaryOperator *E) {
return Error(E);
const Expr *LHSExpr = LHSValue.Base.dyn_cast();
const Expr *RHSExpr = RHSValue.Base.dyn_cast();
- if (!LHSExpr || !RHSExpr)
-return
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/118475
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -91,11 +91,15 @@ def note_constexpr_pointer_subtraction_zero_size : Note<
"subtraction of pointers to type %0 of zero size">;
def note_constexpr_pointer_comparison_unspecified : Note<
"comparison between '%0' and '%1' has unspecified value">;
+def note_constexpr_pointer_
https://github.com/zygoloid commented:
Thanks! I think this is an improvement as-is, but while we're looking at this
it'd be useful to make the existing diagnostics (and the new ones that are
mirroring them) a little bit more precise about what the problem is.
https://github.com/llvm/llvm-proj
zygoloid wrote:
> @zygoloid would it be correct to say that you want the Standard to leave
> idempotency of functions with side effects up to implementations, and,
> consequently, you want the model of how side effects are integrated into
> constant evaluation to work for both idempotent and n
zygoloid wrote:
> Hey Richard - We added idempotency to `define_aggregate` in response to
> concern from Clang maintainers that it could interact poorly with
> `clang-repl`. The argument was that idempotency would provide a better
> experience for a user that wanted to re-evaluate an expressio
zygoloid wrote:
> I initially was of the same opinion as you, but I think we would have to
> modify most call sites
It seems to me that we'd need to modify those call sites that want to perform
an evaluation of a "plainly constant-evaluated expression". Aren't those
exactly the call sites we
zygoloid wrote:
> I think there's a contradiction between what `define_aggregate` needs and
> that hypothetical `write_char_to_file` needs from the same language construct
> (which is currently called _plainly constant-evaluated expression_). If we
> say that we're not going to guarantee idemp
zygoloid wrote:
> > the special "the language rules say this is manifestly constant evaluated"
> > cases that should be able to perform AST mutations, that we need to be
> > extremely careful to invoke at exactly the right times and in exactly the
> > right cases and to invoke only once
>
> C
zygoloid wrote:
> 1. Asking users to pass additional parameter to every `Eval*()` function
> makes a bad transition story for users that wish to upgrade to a version of
> Clang that has changed the interface in this way.
External callers of the `Eval*` functions in almost all cases should not
zygoloid wrote:
If we do end up needing this (and it's looking increasingly likely that we
will), I think the general approach of having a set of callbacks that gets
passed into the constant evaluator is the right approach.
I think the older approach in this PR (a callback object that is expli
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/117364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far");
Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth()));
- Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool
@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far");
Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth()));
- Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/114865
___
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/114865
___
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.
LG, thank you!
https://github.com/llvm/llvm-project/pull/113885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
As mentioned in the comment thread, I'd prefer to see this addressed by
reversing the order in which we call `addDecl` versus add an offset. While it's
a corner case, I think this change would cause us to start rejecting things
like [this example](https://godbolt.org/z/5Pae6Ghd
https://github.com/zygoloid commented:
Please can you also add a test that we allow combining
`-fsanitize=implicit-conversion` and `-fsanitize-minimal-runtime` so that this
doesn't regress in a similar way in future?
(It'd be great if the test covered all the sanitizer groups that are currentl
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/116100
___
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/116100
Fixes #116096.
>From 885c95fcf03f9ab89b7d445ee758c69c77333567 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 13 Nov 2024 12:09:01 -0800
Subject: [PATCH] Document that the lifetime of the caller-side `
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/114857
___
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/114857
None
>From 25047a9f9b8b961451bef0d0c526944d17ffe9d7 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Mon, 4 Nov 2024 11:27:46 -0800
Subject: [PATCH 1/2] Don't redundantly specify the default template argumen
@@ -1703,7 +1703,7 @@ namespace {
bool checkNullPointerDiagnosingWith(const GenDiagType &GenDiag) {
if (Designator.Invalid)
return false;
- if (IsNullPtr) {
+ if (getLValueBase().isNull()) {
zygoloid wrote:
Oh, I see. We're adjustin
@@ -1703,7 +1703,7 @@ namespace {
bool checkNullPointerDiagnosingWith(const GenDiagType &GenDiag) {
if (Designator.Invalid)
return false;
- if (IsNullPtr) {
+ if (getLValueBase().isNull()) {
zygoloid wrote:
Why was the old check not
zygoloid wrote:
> Doesn't it change ABI, though?
Only on platforms where it didn't work at all before.
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
zygoloid wrote:
I've been pondering this. On the one hand, people switching from the
`cl.exe`-compatible driver to the GCC-compatible driver might want the MSVC
interpretation of the path flags. On the other hand, people enabling
`-fms-compatibility` to accept code written against MSVC in a di
zygoloid wrote:
Closing in favour of #112927.
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -326,45 +328,65 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ static constexpr size_t DataSize = std::max(sizeof(uint64_t), sizeof(T *))
https://github.com/zygoloid approved this pull request.
One style nit, otherwise looks good, thanks!
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
zygoloid wrote:
> But yes, the short answer is that the code as written should work on Morello
> and CHERI-RISC-V.
Great, thanks.
> > > The std::launder may be unnecessary
> >
> >
> > Formally I think it's correct and necessary for the pointer and integer
> > case because an array element a
zygoloid wrote:
> How about:
> [...]
Yeah, I think that fixes it. For me that looks a lot less simple than using a
union, but it is nice to have only a single implementation. I'd be fine with
going in that direction.
For CHERI, can we assume that the least-significant byte of the pointer
rep
zygoloid wrote:
> > > #112806 should address this without narrowing the field to 32 bits.
> >
> >
> > As does [#111995
> > (comment)](https://github.com/llvm/llvm-project/pull/111995#discussion_r1805329590),
> > with less code and more generality
>
> I prefer this solution too.
That solutio
zygoloid wrote:
> > This violates aliasing rules and doesn't work at all on big-endian 64-bit
> > systems where the pointer is stored in the second four bytes of the
> > uint64_t.
>
> Your sizes aren't correct in the description here. This issue occurs on big
> endian 32-bit systems,
Yeah, s
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -321,50 +322,87 @@ class ExternalASTSource : public
RefCountedBase {
/// external AST source itself.
template
struct LazyOffsetPtr {
- /// Either a pointer to an AST node or the offset within the
- /// external AST source where the AST node can be found.
- ///
- /// If
zygoloid wrote:
#112806 should address this without narrowing the field to 32 bits.
https://github.com/llvm/llvm-project/pull/111995
___
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/112806
Don't try to read the `uint64_t` stored in `LazyOffsetPtr` as a `T*` via
`getAddressOfPointer`. This violates aliasing rules and doesn't work at all on
big-endian 64-bit systems where the pointer is stored in th
zygoloid wrote:
This choice seems like a question of how the driver's command line is
interpreted, rather than a language mode, so I wonder if it makes sense for it
to consider `-fms-compatibility` at all or whether this should just be based on
the driver mode. Do you have rationale for this a
zygoloid wrote:
> > Can we remove `getAddressOfPointer` instead?. Where is it being used?
>
> It is used in `VarDecl::getInitAddress()` in Decl.cpp. It looks like it is
> used indirectly by the StmtIterator
And that in turn is used in `StmtIterator`, and indeed we can end up *storing
through*
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/112047
___
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.
Thanks, looks good to me too.
https://github.com/llvm/llvm-project/pull/112047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Can we remove `getAddressOfPointer` instead?. Where is it being used?
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
zygoloid wrote:
> I expect that won't be caught, and you'll need to make a similar change to
> `visitLocalsRetainedByInitializer` to handle it.
Actually, maybe the best thing would be to change `visitFunctionCallArguments`
to step over `CXXDefaultArgExpr` in `Args`. That should cover both case
https://github.com/zygoloid commented:
Please can you also add tests for the case where the default argument is a
pointer, eg:
```c++
using T = int[];
int *f([[clang::lifetimebound]] int *p = T{1, 2, 3});
int *p = f();
```
I expect that won't be caught, and you'll need to make a similar change t
@@ -532,6 +533,11 @@ static void
visitLocalsRetainedByReferenceBinding(IndirectLocalPath &Path,
}
} while (Init != Old);
+ if (auto *DAE = dyn_cast(Init)) {
+Path.push_back({IndirectLocalPathEntry::DefaultArg, DAE, DAE->getParam()});
+Init = DAE->getExpr();
+
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/112047
___
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, this seems reasonable.
https://github.com/llvm/llvm-project/pull/112047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -19,8 +19,10 @@ namespace usage_invalid {
namespace usage_ok {
struct IntRef { int *target; };
+ const int *defaultparam(const int &def1 [[clang::lifetimebound]] = 0); //
#def1
int &refparam(int ¶m [[clang::lifetimebound]]);
int &classparam(IntRef param [[clang::l
zygoloid wrote:
@luxufan I think we may need changes on the LLVM side before we can make
progress here -- either to clarify what `unnamed_addr` is intended to mean, or
perhaps to split it into separate attributes for cloning and merging.
But before we go down that path, this PR doesn't describ
zygoloid wrote:
> unnamed_addr doesn't allow cloning; there's no way to make it work in a
> reasonable way even if we wanted it. See, for example, #32127 .
OK. The LangRef is very vague on its semantics, would be nice to get that
clarified by someone who knows the intent.
Is the same true for
@@ -4097,6 +4096,7 @@ llvm::Constant *ItaniumRTTIBuilder::BuildTypeInfo(
// And the name.
llvm::GlobalVariable *TypeName = GetAddrOfTypeName(Ty, Linkage);
llvm::Constant *TypeNameField;
+ llvm::GlobalValue::UnnamedAddr Scope;
zygoloid wrote:
`Scope` isn
https://github.com/zygoloid commented:
Hmm. Looking at https://reviews.llvm.org/D20348 it seems like `unnamed_addr`
and `local_unnamed_addr` don't just permit merging, but also cloning of the
global (so that the same global could have different addresses in different
modules). Cloning wouldn't
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/111343
___
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.
Thanks!
https://github.com/llvm/llvm-project/pull/111446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
> But, I have a question: now that it has ensured the uniqueness of typeinfo's
> address, why does the implementation still compare the type equality by the
> address of type name string?
The uniqueness of the address of the `type_info` object itself is not
guaranteed. The rea
@@ -119,6 +119,16 @@ namespace cwg109 { // cwg109: yes
};
}
+namespace cwg110 { // cwg110: 2.8
+template
+void f();
+
+class f;
+
+template
+void f(int);
+} // namespace cwg110
zygoloid wrote:
It'd be nice to also check that `class f` works here, and that
zygoloid wrote:
Specifically: we do perform address comparisons between these strings, so the
address is significant. And we can have identical string content but different
types:
- for types whose name involves anything with internal linkage
- for types with hidden visibility
- when loading a
zygoloid wrote:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-rtti and
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#typeid in the ABI require
the type name string to be globally unique, and some `std::type_info`
implementations rely on that. You might be able to do this for so
@@ -693,7 +693,7 @@ ItaniumMangleContextImpl::getEffectiveDeclContext(const
Decl *D) {
if (VD->isExternC())
return getASTContext().getTranslationUnitDecl();
- if (const auto *FD = D->getAsFunction()) {
+ if (const auto *FD = dyn_cast(D)) {
zygoloi
@@ -704,6 +704,15 @@ ItaniumMangleContextImpl::getEffectiveDeclContext(const
Decl *D) {
return D->getLexicalDeclContext()->getRedeclContext();
}
+ if (const auto *FTD = dyn_cast(D)) {
+// Member-like constrained friends are mangled as if they were members of
+
zygoloid wrote:
Should this have `-fclang-abi-compat` support?
https://github.com/llvm/llvm-project/pull/110247
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
I've filed a fmtlib bug: https://github.com/fmtlib/fmt/issues/4177
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
I found this:
https://fuchsia.googlesource.com/third_party/github.com/fmtlib/fmt/+/refs/heads/upstream/main/include/fmt/base.h#2664
Note that this is passing `s` separately both to `parse_format_string` and to
`checker`. Here, `s` is a lambda that implicitly converts to a strin
zygoloid wrote:
That backtrace doesn't match the fmtlib code available from their official
repository. Where can I find the code you're building?
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
zygoloid wrote:
> Do we need an ABI flag guarding against the change as well?
Yeah, I think this change should respect `-fclang-abi-compat`.
https://github.com/llvm/llvm-project/pull/109970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
@@ -1214,3 +1216,25 @@ namespace test61 {
// CHECK-LABEL: @_ZN6test611fINS_1XEEEvNT_1Y1aENS3_1bE
template void f(int, int);
}
+
+namespace test62 {
+namespace A {
+
+class VBase {
+ public:
+ virtual ~VBase() {};
+};
+
+struct Wrap {};
+
+template
+class Impl : public vir
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 1379 matches
Mail list logo
