@@ -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
zygoloid wrote:
I believe all the feedback has been addressed, and plan to merge in 24 hours if
there are no further comments.
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
zygoloid wrote:
In @sdkrystian's example, does the use of `A<1>::B` within `A<0>::B` cause
an implicit instantiation to take place? I would have expected that no implicit
instantiation takes place at that point because `A<1>::B` is a dependent
type. I would expect that the specialization of `A
zygoloid wrote:
@fsfod Can you update the first comment to describe the overall purpose of this
change? That seems pretty central to understanding whether we want this, and if
so, whether this looks like the right set of annotations.
https://github.com/llvm/llvm-project/pull/109702
___
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 01/15] Implement current CWG direction for string literal
compa
1 - 100 of 1375 matches
Mail list logo
