@@ -103,3 +103,46 @@ static_assert(_Generic(typeof(overload_func(&ptr0)), int :
1, default : 0));
static_assert(_Generic(typeof(overload_func(&valid0)), float : 1, default :
0));
void func(int array[__ptrauth(VALID_DATA_KEY) 10]); // expected-error
{{'__ptrauth' qualifier o
https://github.com/zmodem edited
https://github.com/llvm/llvm-project/pull/136783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem commented:
Looks reasonable to my non-expert eyes
https://github.com/llvm/llvm-project/pull/136783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -95,6 +95,8 @@ struct CopiedTypeVisitor {
return asDerived().visitARCWeak(FT, std::forward(Args)...);
case QualType::PCK_Struct:
return asDerived().visitStruct(FT, std::forward(Args)...);
+case QualType::PCK_PtrAuth:
zmodem wrote:
style
zmodem wrote:
I too had trouble understanding this change based on the description. Could you
give a concrete example of how mingw and msvc disagree on where to put the
attribute, and explain how this pr changes things?
Taking a step back, how will this simplify libc++'s visibility annotations
Author: Hans Wennborg
Date: 2025-04-22T11:11:33+02:00
New Revision: e12681ae733e8341c161534d4d4de2611573b616
URL:
https://github.com/llvm/llvm-project/commit/e12681ae733e8341c161534d4d4de2611573b616
DIFF:
https://github.com/llvm/llvm-project/commit/e12681ae733e8341c161534d4d4de2611573b616.diff
zmodem wrote:
Thanks! I'll go ahead and push the button. Hope you feel better soon!
https://github.com/llvm/llvm-project/pull/135611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/135611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> This causes the whole libc++ CI to fail, since we're not building against a
> compiler built from current trunk.
Can you provide an example, such as a link to a failing build, or an
explanation of the failure? I found
https://buildkite.com/llvm-project/libcxx-ci/builds?created
zmodem wrote:
> Thanks! Unfortunately it looks like the fix introduced a regression of
> #134265 on Windows. Repro:
(For reference, this is https://crbug.com/41261 on our side.)
The "deleted operator delete[]" is coming from here:
https://source.chromium.org/chromium/chromium/src/+/main:v
zmodem wrote:
Smaller repro:
```
$ cat /tmp/a.ii
class Trans_NS_cppgc_GarbageCollected {
void operator delete[](void *);
};
struct ScriptWrappable : Trans_NS_cppgc_GarbageCollected {
virtual ~ScriptWrappable();
};
struct __declspec(dllexport) ContentIndexEvent : ScriptWrappable {
Content
zmodem wrote:
We're seeing crashes that bisect to this change. Here is a reproducer:
https://crbug.com/410001969#comment3
I'll see if I can get something more reduced as well.
https://github.com/llvm/llvm-project/pull/134357
___
cfe-commits mailing l
zmodem wrote:
> I think moving it to -Wextra may be a more palatable approach. What do others
> think?
Sounds good to me, and I think James makes a good argument.
Does that actually help LLVM and libc++ though? I think at least LLVM does
enable -Wextra.
https://github.com/llvm/llvm-project/p
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/133265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem approved this pull request.
I didn't look at the original patch, but the fix and test update lgtm.
https://github.com/llvm/llvm-project/pull/133451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/133265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7976,6 +7976,8 @@ void
CodeGenModule::requireVectorDestructorDefinition(const CXXRecordDecl *RD) {
auto *NewFn = llvm::Function::Create(
cast(VDEntry->getValueType()),
llvm::Function::ExternalLinkage, VDName, &getModule());
+SetFunctionAttributes(Ve
@@ -689,7 +689,7 @@ if ( LLVM_COMPILER_IS_GCC_COMPATIBLE OR
CMAKE_CXX_COMPILER_ID MATCHES "XL" )
endif( LLVM_COMPILER_IS_GCC_COMPATIBLE OR CMAKE_CXX_COMPILER_ID MATCHES "XL" )
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
- append("-Werror=unguarded-availability-new" CMAKE_C_FL
zmodem wrote:
A few notes from looking today.
Reduced main a bit further:
```
int main(int argc, const char** argv) {
volatile auto p = &FilteredBreakIteratorBuilder::createEmptyInstance;
icu::UnicodeString* St = new icu::UnicodeString("abacabadabacab", 15);
delete St;
printf("OKAY\n");
https://github.com/zmodem created
https://github.com/llvm/llvm-project/pull/133092
None
>From 7a874d12661de2fe93ac5eba8e68edf25053f462 Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Wed, 26 Mar 2025 15:24:44 +0100
Subject: [PATCH] [clang-cl] Accept the --warning-suppression-mappi
zmodem wrote:
> but, that is still not a great reproducer for a reverted patch. Especially if
> the link issue is due to a missing support in linker. I would appreciate if
> you could maybe point to how exactly UnicodeString is used in failing
> scenario.
I'm sorry that we didn't catch this p
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/131188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wunnecessary-virtual-specifier %s
+
+struct Foo final {
+ Foo() = default;
+ virtual ~Foo() = default; // expected-warning {{virtual
method}}
+ virtual Foo& operator=(Foo& other) = default; // ex
zmodem wrote:
> What do you think about implementing the suggestion about checking if virtual
> methods actually get overridden or not?
Since we could only do it for classes with internal linkage, I think it's
probably not very valuable.
Warning about virtual functions that are not overriding
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wunnecessary-virtual-specifier %s
+
+struct Foo final {
+ Foo() = default;
+ virtual ~Foo() = default; // expected-warning {{virtual
method}}
+ virtual Foo& operator=(Foo& other) = default; // ex
https://github.com/zmodem commented:
Code and test lgtm, but I think we should consider enabling it by default.
https://github.com/llvm/llvm-project/pull/131188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/zmodem edited
https://github.com/llvm/llvm-project/pull/131188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2706,6 +2706,9 @@ def warn_final_dtor_non_final_class : Warning<
InGroup;
def note_final_dtor_non_final_class_silence : Note<
"mark %0 as '%select{final|sealed}1' to silence this warning">;
+def warn_unnecessary_virtual_specifier : Warning<
+ "virtual method %0 is insi
zmodem wrote:
> It turns out another issue (https://crbug.com/402425841) also bisected to
> this PR. That one is a run-time problem, so it may be trickier to figure out,
> but I will look into it next.
The bugs seem related by both involving the ICU library, and if squinting a bit
it seems th
https://github.com/zmodem approved this pull request.
> We use existing support for the Microsoft extension type `__int128` which has
> been there for a long time. I feel like we should have appropriate coverage
> already
Sounds good to me.
lgtm with the i128 test that Fznamznon suggested, an
https://github.com/zmodem commented:
> Take the opportunity to tighten up the code slightly by ensuring that we do
> not access out-of-bounds characters when lexing the token.
That's a nice touch :-)
Do we already have tests somewhere checking that we can codegen this, or do we
need to add th
zmodem wrote:
I've put lld-link repro tarballs before and after the llvm change here:
https://issues.chromium.org/u/1/issues/402354446#comment8
https://github.com/llvm/llvm-project/pull/126240
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
zmodem wrote:
Yes, I'm prioritizing this today. I had hoped filteredbrk.obj was enough, but
I'm working on uploading full linker repros.
It turns out another issue (https://crbug.com/402425841) also bisected to this
PR. That one is a run-time problem, so it may be trickier to figure out, but I
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/131036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Hans Wennborg
Date: 2025-03-12T16:26:00+01:00
New Revision: e11ede5e90ee193dde179fe1a9ac9af718ede3db
URL:
https://github.com/llvm/llvm-project/commit/e11ede5e90ee193dde179fe1a9ac9af718ede3db
DIFF:
https://github.com/llvm/llvm-project/commit/e11ede5e90ee193dde179fe1a9ac9af718ede3db.diff
zmodem wrote:
We're hitting link errors after this change when building with sanitizer
coverage enabled:
```
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by obj/third_party/icu/icuuc_private/filteredbrk.obj:(.SCOVP$M)
>>> referenced by obj/third_party/ic
Author: Hans Wennborg
Date: 2025-03-12T12:31:37+01:00
New Revision: 76cf895717e9eba4d2a158d5bc3e48f2f7794181
URL:
https://github.com/llvm/llvm-project/commit/76cf895717e9eba4d2a158d5bc3e48f2f7794181
DIFF:
https://github.com/llvm/llvm-project/commit/76cf895717e9eba4d2a158d5bc3e48f2f7794181.diff
zmodem wrote:
This broke our builds. Here's a small repro:
```
$ cat /tmp/a.cc
#include
__m256i parens;
int f() {
return ((__v32qi)parens)[31];
}
$ build/bin/clang -c /tmp/a.cc
/tmp/a.cc:4:20: error: vector element index 31 is out of bounds
4 | return ((__v32qi)parens)[31];
|
Author: Hans Wennborg
Date: 2025-03-10T16:35:03+01:00
New Revision: c40f0fe4348bb9304b95bd317665bf1cb2bdcc85
URL:
https://github.com/llvm/llvm-project/commit/c40f0fe4348bb9304b95bd317665bf1cb2bdcc85
DIFF:
https://github.com/llvm/llvm-project/commit/c40f0fe4348bb9304b95bd317665bf1cb2bdcc85.diff
zmodem wrote:
This broke code using `modff` on 32-bit x86 Windows, where the runtime library
doesn't provide any `modff` symbol, rather it's implemented inline in `math.h`
(which calls `modf`):
```
>type \src\temp\a.c
#include
#include
float foo(float f) {
float i;
return modff(f, &i);
Author: Hans Wennborg
Date: 2025-03-10T14:02:04+01:00
New Revision: 28fa1fcf55b973e13018ac115fcbb357b4c0baad
URL:
https://github.com/llvm/llvm-project/commit/28fa1fcf55b973e13018ac115fcbb357b4c0baad
DIFF:
https://github.com/llvm/llvm-project/commit/28fa1fcf55b973e13018ac115fcbb357b4c0baad.diff
zmodem wrote:
We're seeing new -Wunguarded-availability warnings after this. A reduced
example:
```
$ cat /tmp/x.cc
template struct remove_cv { typedef T type; };
struct __attribute__((__availability__(android, introduced = 29)))
AAudioStreamWrapper { };
template struct Foo {
T *p;
};
te
zmodem wrote:
Ping?
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/129255
>From c1fe663ceacd31064b2758e43de1afc3f51d3f2c Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Fri, 28 Feb 2025 11:55:06 +0100
Subject: [PATCH 1/2] [Coroutines] Replace coro.outside.frame metadata with
zmodem wrote:
(sorry, wrong button)
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem reopened
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
This is a follow-up to the discussion on the previous PR:
- I think that discussion ended with the conclusion that we need an explicit
mechanism for marking out-of-frame allocas.
- We agree it should not be metadata
- I think an intrinsic may be better than a flag directly on the
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/129120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/129120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -855,6 +855,16 @@ void CodeGenFunction::EmitCoroutineBody(const
CoroutineBodyStmt &S) {
// Create parameter copies. We do it before creating a promise, since an
// evolution of coroutine TS may allow promise constructor to observe
// parameter copies.
+for (
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/127653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/8] [Coroutines] Mark parameter allocas with
coro.outside.fr
zmodem wrote:
The discussion seems to be stalling. I'll try to summarize.
There seem to be two major questions:
1. Whether the front-end should explicitly mark some allocas as not belonging
in the coroutine frame, or whether we should enhance CoroSplit to infer it
automatically.
I think e
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/7] [Coroutines] Mark parameter allocas with
coro.outside.fr
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
@@ -14,3 +14,11 @@
//--- test.pcm
// CPP20WARNING-NOT: clang-cl: warning: argument unused during compilation:
'/std:c++20' [-Wunused-command-line-argument]
+
+// test whether the following outputs %Hello.bmi
+// RUN: %clang_cl /std:c++20 --precompile -x c++-module
-fmodule-o
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -std=c++17 -Wno-all -Wunsafe-buffer-usage \
+// RUN:-verify %s
+
+// Previously we had a bug where we would diagnose *no* unsafe buffer warnings
+// if the warning was disabled by pragma and left disabled until end-of-TU.
+// This i
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -std=c++17 -Wno-all -Wunsafe-buffer-usage \
zmodem wrote:
nit: No need for the line break?
https://github.com/llvm/llvm-project/pull/128603
___
cfe-commits mailing list
cfe-commits@
https://github.com/zmodem approved this pull request.
https://github.com/llvm/llvm-project/pull/128603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> Re: sroa/mem2reg, that's a valid concern with Hans's intrinsic approach.
Is it still a concern in the latest version, which makes mem2reg aware of the
intrinsic?
I don't have a good feel for whether putting a flag on `AllocaInst` or using an
intrinsic is less disruptive. Happy
zmodem wrote:
> > > My instinct reaction is, it may block some optimizations to optimize the
> > > alloca out.
> >
> >
> > The intrinsic gets dropped by CoroSplit, so after that it's not a problem.
> > Before that, I'm not sure much interesting optimization can happen to
> > allocas anyway?
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/6] [Coroutines] Mark parameter allocas with
coro.outside.fr
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/127843
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> In the issue (#127499) you pointed out that this issue applies to the MSVC
> ABI where all parameters are destroyed in the callee. Is it reasonable to
> construct the analogous test case in that environment?
Yes, in fact the reproducer on that issue will trigger use-after-free
zmodem wrote:
> this is a high-risk change to keep in mind if any Windows-specific issues
> arise.
Thanks for the heads up!
https://github.com/llvm/llvm-project/pull/126240
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.or
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/4] [Coroutines] Mark parameter allocas with
coro.outside.fr
zmodem wrote:
> @zmodem Could you please check whether the clang build on windows works with
> the patch at #128020?
I'm afraid I get the same crashes with that one.
https://github.com/llvm/llvm-project/pull/125880
___
cfe-commits mailing list
cfe-co
https://github.com/zmodem approved this pull request.
LGTM with a nit.
I'll wait a day before merging in case anyone else wants to review as well.
https://github.com/llvm/llvm-project/pull/127843
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -13440,6 +13440,23 @@ bool
Sema::GloballyUniqueObjectMightBeAccidentallyDuplicated(
return true;
}
+// Determine whether the object seems mutable for the purpose of diagnosing
+// possible unique object duplication, i.e. non-const-qualified, and
+// not an always-constan
https://github.com/zmodem edited
https://github.com/llvm/llvm-project/pull/127843
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
I pushed a sketch of what using an intrinsic instead would look like. What do
you think?
https://github.com/llvm/llvm-project/pull/127653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/3] [Coroutines] Mark parameter allocas with
coro.outside.fr
zmodem wrote:
> This is relevant for clang modules, as they are imported into the AST, but
> are actually part of a different TU.
I'm not a modules or matcher expert, but this doesn't match my (perhaps
uninformed) understanding. I thought that when we import a module, it *is* part
of our TU,
zmodem wrote:
+cc @haoNoQ and @ivanaivanovska for -Wunsafe-buffer-usage
https://github.com/llvm/llvm-project/pull/127161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> Adding metadata to an instruction should never be required for correctness
I figured the existing use and the fact that it only needs to survive until
CoroSplit made it good enough. But you're right, we should do better.
I do think we need an explicit way to tell CoroSplit whet
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/2] [Coroutines] Mark parameter allocas with
coro.outside.fr
zmodem wrote:
I think this is a better fix than #127524. Please take a look.
https://github.com/llvm/llvm-project/pull/127653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
be part of the frame, use metadata to make
it so.
Fixes #127499
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH] [Coroutines] Mark parameter allocas with coro.outside.frame
metadata
Parameters t
zmodem wrote:
We're hitting test failures on Windows as well after the re-land
(7e3735d1a1b85cea48feb45cb7c2b5d8eaa216ae). It seems to only reproduce on
Windows with ThinLTO, and causes some libclang and clangd lit tests to crash.
(Our bug: https://crbug.com/397252105).
https://github.com/llv
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/125902
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem approved this pull request.
lgtm
I'll wait a day or so before merging in case other reviewers want to chime in.
https://github.com/llvm/llvm-project/pull/125902
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
@@ -3669,6 +3669,7 @@ class Sema final : public SemaBase {
/// cause problems if the variable is mutable, its initialization is
/// effectful, or its address is taken.
bool GloballyUniqueObjectMightBeAccidentallyDuplicated(const VarDecl *Dcl);
+ void DiagnoseDangerousUni
https://github.com/zmodem commented:
Seems reasonable to me. Just a few very minor nits.
https://github.com/llvm/llvm-project/pull/125902
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/zmodem edited
https://github.com/llvm/llvm-project/pull/125902
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3669,6 +3669,7 @@ class Sema final : public SemaBase {
/// cause problems if the variable is mutable, its initialization is
/// effectful, or its address is taken.
bool GloballyUniqueObjectMightBeAccidentallyDuplicated(const VarDecl *Dcl);
+ void DiagnoseDangerousUni
@@ -154,4 +154,89 @@ namespace GlobalTest {
};
inline float Test::disallowedStaticMember2 = 2.3; // hidden-warning
{{'disallowedStaticMember2' may be duplicated when built into a shared library:
it is mutable, has hidden visibility, and external linkage}}
-} // namespace
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/124022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
@@ -14,3 +14,11 @@
//--- test.pcm
// CPP20WARNING-NOT: clang-cl: warning: argument unused during compilation:
'/std:c++20' [-Wunused-command-line-argument]
+
+// test whether the following outputs %Hello.bmi
+// RUN: %clang_cl /std:c++20 --precompile -x c++-module
-fmodule-o
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
https://github.com/zmodem approved this pull request.
lg
> Previously: #120787
That one landed before the 20 branch point, and this will land after. Maybe we
should ask to have it back-ported.
https://github.com/llvm/llvm-project/pull/126512
___
cfe
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/126139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
@ziqingluo-90 can you take a look?
https://github.com/llvm/llvm-project/pull/124022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Hans Wennborg
Date: 2025-02-04T11:19:20+01:00
New Revision: 83ff9d4a34b1e579dd809759d13b70b8837f0cde
URL:
https://github.com/llvm/llvm-project/commit/83ff9d4a34b1e579dd809759d13b70b8837f0cde
DIFF:
https://github.com/llvm/llvm-project/commit/83ff9d4a34b1e579dd809759d13b70b8837f0cde.diff
zmodem wrote:
The build is still broken (e.g.
https://lab.llvm.org/buildbot/#/builders/63/builds/3861). I'll back it out.
https://github.com/llvm/llvm-project/pull/115099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
zmodem wrote:
creduce'd reproducer:
```
$ cat /tmp/a.cc
class Location {
public:
static Location Current(int = __builtin_LINE());
};
class DOMMatrix;
class BasicMember {
public:
BasicMember(DOMMatrix *);
};
template using Member = BasicMember;
class ExceptionState {
public:
ExceptionState
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/125526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem approved this pull request.
https://github.com/llvm/llvm-project/pull/125526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 1575 matches
Mail list logo
