sam-mccall wrote:
Just wanted to say thanks - I didn't ever entirely understand how this was
used, but the build speed/complexity has been somewhat painful. Removing
features is thankless and sometimes risky, so I was expecting we'd live with
that speedbump forever.
sam-mccall wrote:
The immediate deprecation causes a few issues:
- mechanical: we build with `-Wall -Werror -Wno-deprecated-declarations
-Wno-deprecated-other-stuff` in part to catch driver misuse and fix it early.
However this warning is not actionable, so now we need `-Wno-deprecated` which
sam-mccall wrote:
All makes sense to me.
I'd point out that the only revert I was asking for was asking for was of the
deprecation of the flag to restore the old behavior, and *optionally* the
default flip.
The combination of {prominent oss library, accepted by clang-18 and gcc, now
ICE,
sam-mccall wrote:
I'm sorry that I wasn't able to more usefully reduce the failure cases. When
such regressions show up, we usually don't have any meaningful context on the
code. For our own code, we have guidelines to try to limit complexity which
makes reduction more tractable, but
sam-mccall wrote:
@mizvekov Thank you! With that patch, clang not only doesn't crash on stdexec
with `-frelaxed-template-template-args`, but in fact accepts the code.
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
sam-mccall wrote:
This commit did three things: A) changed the implementation, B) changed the
flag default, and C) deprecated the flag.
Since clang now crashes on widely-used, real-world code, can we at least revert
C, and ideally B until the crashes are fixed?
(It would also have been
sam-mccall wrote:
Here's a preprocessed file:
[repro.zip](https://github.com/llvm/llvm-project/files/15250584/repro.zip)
I tried to reduce, and got rid of most of the test code and some of the stdexec
code, but there's still a lot left.
I hit the end of my timebox on that. Maybe creduce can
sam-mccall wrote:
This patch introduced a crash on code that clang previously accepted (I'm not
sure whether the code is correct).
The code is
https://github.com/nvidia/stdexec/tree/467f4a68ee04f3bb4c35e7a5dd13a3419da160cb,
building `test/stdexec/algos/adaptors/test_stopped_as_optional.cpp`
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/89441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall approved this pull request.
Thanks, LGTM
https://github.com/llvm/llvm-project/pull/89441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1574,6 +1574,7 @@ bool HeaderSearch::ShouldEnterIncludeFile(Preprocessor
,
}
}
+ FileInfo.IsLocallyIncluded = true;
sam-mccall wrote:
I'd consider placing this at the end of HandleHeaderIncludeOrImport rather than
here:
- it looks like there
@@ -2057,9 +2065,12 @@ void ASTWriter::WriteHeaderSearch(const HeaderSearch
) {
// it as a header file (in which case HFI will be null) or if it hasn't
// changed since it was loaded. Also skip it if it's for a modular header
// from a different module; in that
@@ -237,6 +238,8 @@ GetAffectingModuleMaps(const Preprocessor , Module
*RootModule) {
CollectIncludingMapsFromAncestors(CurrentModule);
for (const Module *ImportedModule : CurrentModule->Imports)
CollectIncludingMapsFromAncestors(ImportedModule);
+for (const
@@ -187,7 +187,8 @@ GetAffectingModuleMaps(const Preprocessor , Module
*RootModule) {
continue;
const HeaderFileInfo *HFI = HS.getExistingLocalFileInfo(*File);
-if (!HFI || (HFI->isModuleHeader && !HFI->isCompilingModuleHeader))
+if (!HFI ||
@@ -0,0 +1,20 @@
+// This test checks that a module map with a textual header can be marked as
sam-mccall wrote:
This is a useful test, I think there are a couple of other affecting-ness
properties that are important to test:
- that a textual header that *is*
https://github.com/sam-mccall approved this pull request.
Thanks! This looks good, much neater than my approach.
I'm interested in whether the DirectUses change is related to this, and would
like to slap on a couple of tests.
But either way, this looks good and it would be great to have it
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/89441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1441,6 +1441,10 @@ void HeaderSearch::MarkFileModuleHeader(FileEntryRef FE,
HFI.isCompilingModuleHeader |= isCompilingModuleHeader;
}
+void HeaderSearch::EnteredTextualFile(FileEntryRef File) {
+ getFileInfo(File).isCompilingModuleHeader = true;
sam-mccall wrote:
> @sam-mccall That makes sense.
>
> I think one option we have here is to consider all module maps describing a
> textual header that got included as affecting. I'm concerned that a long
> chain of textual header includes might again be problematic.
Yeah, that's the option
https://github.com/sam-mccall created
https://github.com/llvm/llvm-project/pull/89729
Prior to this change, modulemaps describing textual headers are considered
to affect the current module whenever HeaderFileInfos for those headers exist.
This wastes creates false dependencies that (among
sam-mccall wrote:
Yes, it's approximately the same problem. Thanks & sorry for the noise!
(We have a non-clang include-scanner that computes dependencies to ensure
hermetic builds. The indirect include defeats the include scanner, so we were
accidentally relying on `` being available for some
sam-mccall wrote:
> I updated the description of this PR, hopefully it makes more sense now. I
> still need to investigate what goes wrong in
> "Modules/preprocess-decluse.cpp". It seems that it assumes `%t/b.pcm` embeds
> the information from "a.modulemap".
I think it should embed that
sam-mccall wrote:
> Is this a pre-existing issue, or did my patch change to make "each textual
> header gets a `HFI`"?
My best understanding that your patch gave textual headers`HFI`s when the
module map was loaded, rather than when the header was included. This shouldn't
have mattered, but
sam-mccall wrote:
> clang's headers all have proper modules now, are you sure you still need A?
We can't use `clang/lib/Headers/module.modulemap`, so we need something to
describe those headers.
Why can't we? In our build system, it's the **build system's** job to generate
modulemaps for
sam-mccall wrote:
Thanks for the pointer to 87848 - reverting that one locally doesn't help
though, even in combination with applying #89005 and #89428. So this change
isn't on the critical path to fixing our builds, but still much appreciated and
will take a look now.
---
Unsurprisingly,
https://github.com/sam-mccall approved this pull request.
This makes sense to me. It corresponds to our build structure and fixes the new
build failures we saw after 0cd0aa029647c8d1dba5c3d62f92325576796fa2.
Really appreciate your work on this!
https://github.com/llvm/llvm-project/pull/89441
sam-mccall wrote:
> Hmm, this will probably only work if you compile `A` into a PCM and then pass
> it to `B`. This is not how "Modules/preprocess-decluse.cpp" is set up.
In our case we always have a chain A <- B <- C.
A.modulemap can be affecting for B but should not be for C.
(Approximately,
sam-mccall wrote:
#89441 fixes our build problems, with or without this patch applied.
It's possible this patch makes things better - I haven't checked for actual
sloc usage yet, just whether the build fails.
So I'll focus on understanding that one and then return here.
(I think I'm close to
sam-mccall wrote:
I can confirm applying this allows our targets to build again! :tada:
Thank you, will take a look at the implementation now.
https://github.com/llvm/llvm-project/pull/89441
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
sam-mccall wrote:
Hmm, I locally reverted https://github.com/llvm/llvm-project/pull/87849 and
still see the same issue.
I'll patch #89428 instead, but I don't see how it could do better - it's just
putting the old and new behavior of #87849 behind a flag, right?
In any case I'll try it, and
sam-mccall wrote:
Unfortunately with this patch I'm still seeing the same
source-location-exhausted error.
I'm going to try to understand why...
https://github.com/llvm/llvm-project/pull/89005
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
sam-mccall wrote:
Ilya is out on vacation, I'm able to test this and will get started on that now
(apologies for delay & thanks for digging into this)
https://github.com/llvm/llvm-project/pull/89005
___
cfe-commits mailing list
https://github.com/sam-mccall closed
https://github.com/llvm/llvm-project/pull/88727
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall approved this pull request.
https://github.com/llvm/llvm-project/pull/88381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall approved this pull request.
https://github.com/llvm/llvm-project/pull/87611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall commented:
I'm not sold on the use of OptTable here, and think we should try some
alternatives. I don't want to be a burden, so I'm happy to try this out if you
like.
If it's just this tool then it's not that important, but I assume it's not.
There's possible
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny =?utf-8?q?Mösch?= ,
Danny
https://github.com/sam-mccall approved this pull request.
Thanks, this looks like the right fix, and cleaning up DclT while here makes
sense.
https://github.com/llvm/llvm-project/pull/88014
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -3391,7 +3391,7 @@ class Sema final : public SemaBase {
bool ConstexprSupported, bool CLinkageMayDiffer);
/// type checking declaration initializers (C99 6.7.8)
- bool CheckForConstantInitializer(Expr *e, QualType t);
+ bool CheckForConstantInitializer(Expr
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/88014
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -112,7 +112,10 @@ struct UpdateIndexCallbacks : public ParsingCallbacks {
// Index outlives TUScheduler (declared first)
FIndex(FIndex),
// shared_ptr extends lifetime
- Stdlib(Stdlib)]() mutable {
+
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/87611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall commented:
I'm iffy on whether this is semantically right or not, but we need to solve
this problem somehow, so let's try the most obvious way.
https://github.com/llvm/llvm-project/pull/87611
___
cfe-commits mailing list
https://github.com/sam-mccall created
https://github.com/llvm/llvm-project/pull/88727
The intent was that smart-pointers do not participate in completeness
checks, but we failed to capture dependent `unique_ptr`, which is not
a RecordType but a TemplateSpecializationType.
>From
https://github.com/sam-mccall closed
https://github.com/llvm/llvm-project/pull/87325
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sam-mccall wrote:
Sorry Douglas, and thanks for the revert.
(I missed including the new test file in the commit - I'll make sure to run
through CI when relanding this!)
https://github.com/llvm/llvm-project/pull/87041
___
cfe-commits mailing list
https://github.com/sam-mccall created
https://github.com/llvm/llvm-project/pull/87325
This reverts commit 28760b63bbf9e267713957105a8d17091fb0d20e.
The last commit was missing the new testcase, now fixed.
>From dfcb5dd823e2eb4614be6e34369ac703eb87312e Mon Sep 17 00:00:00 2001
From: Sam
Author: Sam McCall
Date: 2024-03-28T23:57:09+01:00
New Revision: bbbcc1d99d08855069f4501c896c43a6d4d7b598
URL:
https://github.com/llvm/llvm-project/commit/bbbcc1d99d08855069f4501c896c43a6d4d7b598
DIFF:
https://github.com/llvm/llvm-project/commit/bbbcc1d99d08855069f4501c896c43a6d4d7b598.diff
https://github.com/sam-mccall approved this pull request.
https://github.com/llvm/llvm-project/pull/85413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -156,6 +156,37 @@ void test_noexcept(int *i) {
#undef TEST_TYPE
} // end namespace test_launder
+namespace test_start_object_lifetime {
+// The builtin is non-constant.
+constexpr int test_non_constexpr(int i) { // expected-error {{constexpr
function never produces a
@@ -896,6 +896,12 @@ def Launder : Builtin {
let Prototype = "void*(void*)";
}
+def StartObjectLifeTime : Builtin {
sam-mccall wrote:
https://github.com/llvm/llvm-project/pull/86512 is the answer here, I think.
sam-mccall wrote:
This has been dormant in part while thinking about the memcpy half, I think.
Something like https://github.com/llvm/llvm-project/pull/86512 solves that well
but likely needs this change too.
> I am a bit concerned that this does not actually have the desired semantics
> at
@@ -5056,6 +5056,8 @@ static bool CheckUnaryTypeTraitTypeCompleteness(Sema ,
TypeTrait UTT,
case UTT_IsStandardLayout:
case UTT_IsPOD:
case UTT_IsLiteral:
+ // Clang extension:
sam-mccall wrote:
AFAIK these are all clang extensions (the `__`
@@ -526,6 +526,7 @@ TYPE_TRAIT_2(__is_layout_compatible, IsLayoutCompatible,
KEYCXX)
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__is_bitwise_copyable, IsBitwiseCopyable, KEYCXX)
sam-mccall wrote:
naming
@@ -2667,6 +2667,29 @@ bool QualType::isTriviallyCopyableType(const ASTContext
) const {
/*IsCopyConstructible=*/false);
}
+bool QualType::isBitwiseCopyableType(const ASTContext & Context) const {
+ QualType CanonicalType =
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+
+// Scalar types are bitwise copyable.
+static_assert(__is_bitwise_copyable(int));
+static_assert(__is_bitwise_copyable(int*));
+// array
+static_assert(__is_bitwise_copyable(int[10]));
+
+
+struct
@@ -2667,6 +2667,29 @@ bool QualType::isTriviallyCopyableType(const ASTContext
) const {
/*IsCopyConstructible=*/false);
}
+bool QualType::isBitwiseCopyableType(const ASTContext & Context) const {
+ QualType CanonicalType =
@@ -526,6 +526,7 @@ TYPE_TRAIT_2(__is_layout_compatible, IsLayoutCompatible,
KEYCXX)
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__is_bitwise_copyable, IsBitwiseCopyable, KEYCXX)
sam-mccall wrote:
naming
@@ -526,6 +526,7 @@ TYPE_TRAIT_2(__is_layout_compatible, IsLayoutCompatible,
KEYCXX)
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__is_bitwise_copyable, IsBitwiseCopyable, KEYCXX)
sam-mccall wrote:
why c++ only?
@@ -526,6 +526,7 @@ TYPE_TRAIT_2(__is_layout_compatible, IsLayoutCompatible,
KEYCXX)
#include "clang/Basic/TransformTypeTraits.def"
// Clang-only C++ Type Traits
+TYPE_TRAIT_1(__is_bitwise_copyable, IsBitwiseCopyable, KEYCXX)
sam-mccall wrote:
this new
@@ -2667,6 +2667,29 @@ bool QualType::isTriviallyCopyableType(const ASTContext
) const {
/*IsCopyConstructible=*/false);
}
+bool QualType::isBitwiseCopyableType(const ASTContext & Context) const {
+ QualType CanonicalType =
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/86512
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall commented:
I'm in favour of this, but we should have someone less-attached to it sign off
on at least the basic design.
One question this doesn't explicitly address: after memcpying, does user code
need to bless the bits somehow to start the new object's
@@ -1990,6 +1990,18 @@ void TextNodeDumper::VisitFunctionDecl(const
FunctionDecl *D) {
}
}
+void TextNodeDumper::VisitCXXDeductionGuideDecl(const CXXDeductionGuideDecl
*D) {
+ VisitFunctionDecl(D);
+ switch (D->getDeductionCandidateKind()) {
+ case
https://github.com/sam-mccall approved this pull request.
https://github.com/llvm/llvm-project/pull/84018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/84018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/85957
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4628,6 +4662,21 @@ TEST(TransferTest, DoesNotCrashOnUnionThisExpr) {
LangStandard::lang_cxx17, /*ApplyBuiltinTransfer=*/true, "operator=");
}
+TEST(TransferTest, DoesNotCrashOnNullChildren) {
+ std::string Code = (CoroutineLibrary + R"cc(
+task foo() noexcept {
https://github.com/sam-mccall approved this pull request.
https://github.com/llvm/llvm-project/pull/85957
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Sam McCall
Date: 2024-03-15T21:55:37+01:00
New Revision: ca4c4a6758d184f209cb5d88ef42ecc011b11642
URL:
https://github.com/llvm/llvm-project/commit/ca4c4a6758d184f209cb5d88ef42ecc011b11642
DIFF:
https://github.com/llvm/llvm-project/commit/ca4c4a6758d184f209cb5d88ef42ecc011b11642.diff
https://github.com/sam-mccall approved this pull request.
Thank you, and sorry for piling on extra errors...
https://github.com/llvm/llvm-project/pull/85310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/sam-mccall closed
https://github.com/llvm/llvm-project/pull/82705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From ebf37038879e6b7ea2a315f267dc1dfe10a12c41 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH 1/5] [clang][nullability] allow _Nonnull etc on nullable class
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From eccc46840e343e7ba15200cd4b81316a51c46943 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH 1/4] [clang][nullability] allow _Nonnull etc on nullable class
https://github.com/sam-mccall approved this pull request.
Very nice, thanks!
https://github.com/llvm/llvm-project/pull/85032
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall approved this pull request.
This direction looks good to me, mostly I just have nits.
The one major change I'd consider before landing is to find a way to avoid the
verbosity regression cor3ntin mentions for `Diag()` and friends. Notational
regressions within
@@ -63,17 +67,17 @@ void Sema::ActOnOpenACCConstruct(OpenACCDirectiveKind K,
// here as these constructs do not take any arguments.
break;
default:
-Diag(StartLoc, diag::warn_acc_construct_unimplemented) << K;
+SemaRef.Diag(StartLoc,
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/84184
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/84184
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,67 @@
+//===- SemaOpenACC.h - Semantic Analysis for OpenACC constructs
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
@@ -1162,6 +1162,11 @@ class Sema final {
/// CurContext - This is the current declaration context of parsing.
DeclContext *CurContext;
+ SemaOpenACC () {
sam-mccall wrote:
nit: per style guide, this should be `openACC()` (lowercase O), and it should
https://github.com/sam-mccall approved this pull request.
Makes sense to me. If this ends up applying to lots of attributes then maybe we
should hoist the text somewhere common, but agree that it doesn't seem to.
https://github.com/llvm/llvm-project/pull/82815
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From eccc46840e343e7ba15200cd4b81316a51c46943 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH 1/3] [clang][nullability] allow _Nonnull etc on nullable class
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From eccc46840e343e7ba15200cd4b81316a51c46943 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH 1/2] [clang][nullability] allow _Nonnull etc on nullable class
@@ -5955,6 +5955,20 @@ static void handleBuiltinAliasAttr(Sema , Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleNullableTypeAttr(Sema , Decl *D, const ParsedAttr ) {
+ if (AL.isUsedAsTypeAttr())
+return;
+
+ if
@@ -215,6 +215,18 @@ void Sema::inferGslOwnerPointerAttribute(CXXRecordDecl
*Record) {
inferGslPointerAttribute(Record, Record);
}
+void Sema::inferNullableClassAttribute(CXXRecordDecl *CRD) {
+ static llvm::StringSet<> Nullable{
+ "auto_ptr", "shared_ptr",
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/82705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1494,6 +1494,15 @@ void
Parser::ParseMicrosoftInheritanceClassAttributes(ParsedAttributes ) {
}
}
+void Parser::ParseNullabilityClassAttributes(ParsedAttributes ) {
+ while (Tok.is(tok::kw__Nullable)) {
sam-mccall wrote:
It's not important that we
@@ -4096,6 +4096,11 @@ non-underscored keywords. For example:
@property (assign, nullable) NSView *superview;
@property (readonly, nonnull) NSArray *subviews;
@end
+
+As well as built-in pointer types, ithe nullability attributes can be attached
+to nullable
@@ -2156,9 +2156,10 @@ def TypeNonNull : TypeAttr {
let Documentation = [TypeNonNullDocs];
}
-def TypeNullable : TypeAttr {
+def TypeNullable : DeclOrTypeAttr {
let Spellings = [CustomKeyword<"_Nullable">];
let Documentation = [TypeNullableDocs];
+// let Subjects =
sam-mccall wrote:
Thanks! (And sorry, that json::Value constructor is my fault too...)
https://github.com/llvm/llvm-project/pull/84747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall closed
https://github.com/llvm/llvm-project/pull/84747
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/82705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/82705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall edited
https://github.com/llvm/llvm-project/pull/82705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall ready_for_review
https://github.com/llvm/llvm-project/pull/82705
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From eccc46840e343e7ba15200cd4b81316a51c46943 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH] [clang][nullability] allow _Nonnull etc on nullable class
types
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From 5df9923adddce2668322f4ae356f38fc50a11764 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH] [clang][nullability] allow _Nonnull etc on nullable class
types
https://github.com/sam-mccall updated
https://github.com/llvm/llvm-project/pull/82705
>From 03fbcda73e9feef586f87e2a0a203636fa8ce172 Mon Sep 17 00:00:00 2001
From: Sam McCall
Date: Thu, 22 Feb 2024 16:00:44 +0100
Subject: [PATCH] [clang][nullability] allow _Nonnull etc on nullable class
types
1 - 100 of 1720 matches
Mail list logo
