Xazax-hun wrote:
> This expression is indeed error-prone, but the problem is not the use of isa
> but the use of the method getMemorySpace()
My bad! You are right, it is not the `isa`. :)
> this error-prone situation will be resolved soon in a follow-up commit
I think it would be nice if w
Xazax-hun wrote:
> Do you mean moving away from a class hierarchy definition for memspaces and
> towards something else, maybe a enum Kind definition, or maybe just try to
> hide all the casting behind a different API?
I think it would be nice to do the latter in this patch so using `isa` dire
@@ -0,0 +1,72 @@
+//===-- MemSpaces.cpp -*- C++
-*--//
+//
+// 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: Apa
https://github.com/Xazax-hun commented:
I like the direction of this PR but at the same time it makes memspaces a bit
more error prone to use. Do you think we could find a way to prevent using
`isa` on memspaces?
https://github.com/llvm/llvm-project/pull/123003
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/123003
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/122516
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/122516
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -19493,7 +19493,11 @@ void Sema::ActOnFields(Scope *S, SourceLocation
RecLoc, Decl *EnclosingDecl,
CDecl->setIvarRBraceLoc(RBrac);
}
}
- ProcessAPINotes(Record);
+
+ // If this is a class template instantiation, its API Notes attributes were
+ // added to the
@@ -406,7 +406,7 @@ void use() {
strings.insert(strings.begin(), std::string());
std::vector pointers;
- pointers.push_back(getLifetimeBoundPointer(std::string())); //
expected-warning {{object whose reference is captured by 'pointers' will be
destroyed at the end of th
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/122088
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/122240
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/122167
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
> this requires dataflow analysis to get a low false-positive rate
I think it might be possible to have low false positive rates without dataflow
analysis. Currently, it looks like the check is looking for syntactically
identical subexpressions. Those tend to overlap in most
@@ -0,0 +1,86 @@
+// RUN: %check_clang_tidy %s bugprone-sprintf-argument-overlap %t
+
+using size_t = decltype(sizeof(int));
+
+extern "C" int sprintf(char *s, const char *format, ...);
+extern "C" int snprintf(char *s, size_t n, const char *format, ...);
+
+namespace std {
+ int
https://github.com/Xazax-hun approved this pull request.
I am OK with this change. Having more stable analysis results is valuable.
That being said, do we know how exactly the unstable addresses result in
unstable results?
https://github.com/llvm/llvm-project/pull/121551
__
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/120981
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
Do you expect any changes for less obvious ways of looping?
* Recursion
* `while(true) if (cond) break;`
* Like above but with gotos
?
Would be nice to have some tests for those as well.
https://github.com/llvm/llvm-project/pull/119388
___
@@ -71,10 +73,28 @@ template class CachedConstAccessorsLattice
: public Base {
/// Requirements:
///
/// - `CE` should return a location (GLValue or a record type).
+ ///
+ /// DEPRECATED: switch users to the below overload which takes Callee and
Type
+ /// directl
@@ -555,24 +557,26 @@ void handleConstMemberCall(const CallExpr *CE,
LatticeTransferState &State) {
// If the const method returns an optional or reference to an optional.
if (RecordLoc != nullptr && isSupportedOptionalType(CE->getType())) {
-
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/120702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
OK, the dependency argument is fair. I am with this as is.
https://github.com/llvm/llvm-project/pull/120435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
I see that `unsafeConstructor` is used in the follow-up PRs. I'd move the
addition of that function to the first PR that is using it.
https://github.com/llvm/llvm-project/pull/120435
___
cfe-commits mailing list
cfe-commits@lists.llv
https://github.com/Xazax-hun approved this pull request.
I would remove the `unsafeConstructor` unless we absolutely need it. Otherwise
LGTM!
https://github.com/llvm/llvm-project/pull/120435
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
@@ -0,0 +1,64 @@
+//== APSIntPtr.h - Wrapper for APSInt objects owned separately -*- C++ -*--==//
+//
+// 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: Apach
@@ -0,0 +1,64 @@
+//== APSIntPtr.h - Wrapper for APSInt objects owned separately -*- C++ -*--==//
+//
+// 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: Apach
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/115051
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
I think the ideal solution would be something like using the
[analyzer_noreturn](https://clang.llvm.org/docs/AttributeReference.html#analyzer-noreturn)
attribute in GTest to mark branches that should not be taken by static
analyzers because some invariants failed and every fur
https://github.com/Xazax-hun approved this pull request.
https://github.com/llvm/llvm-project/pull/120233
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath
&Path, Expr *Call,
// Temp().ptr; // Here ptr might not dangle.
if (isa(Arg->IgnoreImpCasts()))
return;
+// Avoid false positives when the object is constructed from a conditional
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath
&Path, Expr *Call,
// Temp().ptr; // Here ptr might not dangle.
if (isa(Arg->IgnoreImpCasts()))
return;
+// Avoid false positives when the object is constructed from a conditional
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath
&Path, Expr *Call,
// Temp().ptr; // Here ptr might not dangle.
if (isa(Arg->IgnoreImpCasts()))
return;
+// Avoid false positives when the object is constructed from a conditional
@@ -0,0 +1,134 @@
+#include "clang/Analysis/FlowSensitive/SmartPointerAccessorCaching.h"
+
+#include "clang/AST/CanonicalType.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Basic/OperatorKinds.h"
+
+namespace clang::dataflow {
+
+na
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath
&Path, Expr *Call,
// Temp().ptr; // Here ptr might not dangle.
if (isa(Arg->IgnoreImpCasts()))
return;
+// Avoid false positives when the object is constructed from a conditional
@@ -582,6 +582,15 @@ static void visitFunctionCallArguments(IndirectLocalPath
&Path, Expr *Call,
// Temp().ptr; // Here ptr might not dangle.
if (isa(Arg->IgnoreImpCasts()))
return;
+// Avoid false positives when the object is constructed from a conditional
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/120233
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,134 @@
+#include "clang/Analysis/FlowSensitive/SmartPointerAccessorCaching.h"
+
+#include "clang/AST/CanonicalType.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Basic/OperatorKinds.h"
+
+namespace clang::dataflow {
+
+na
https://github.com/Xazax-hun approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/119685
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -511,6 +511,10 @@ static void ProcessAPINotes(Sema &S, FunctionOrMethod
AnyFunc,
AnyTypeChanged = true;
}
+ // returns_(un)retained
+ if (!Info.SwiftReturnOwnership.empty())
Xazax-hun wrote:
There are other places where we do not validate string
@@ -511,6 +511,10 @@ static void ProcessAPINotes(Sema &S, FunctionOrMethod
AnyFunc,
AnyTypeChanged = true;
}
+ // returns_(un)retained
+ if (!Info.SwiftReturnOwnership.empty())
Xazax-hun wrote:
I don't think this is a good idea. This lets the users
@@ -542,6 +542,9 @@ class FunctionInfo : public CommonEntityInfo {
/// The result type of this function, as a C type.
std::string ResultType;
+ /// Swift name of this entity.
+ std::string SwiftReturnOwnership;
Xazax-hun wrote:
We talked about this with
@@ -1093,6 +1093,7 @@ unsigned getFunctionInfoSize(const FunctionInfo &FI) {
for (const auto &P : FI.Params)
size += getParamInfoSize(P);
size += sizeof(uint16_t) + FI.ResultType.size();
+ size += FI.SwiftReturnOwnership.size();
Xazax-hun wrote:
Is th
@@ -542,6 +542,9 @@ class FunctionInfo : public CommonEntityInfo {
/// The result type of this function, as a C type.
std::string ResultType;
+ /// Swift name of this entity.
Xazax-hun wrote:
Nit: this comment might be a remnant of a copy and paste.
htt
@@ -542,6 +542,9 @@ class FunctionInfo : public CommonEntityInfo {
/// The result type of this function, as a C type.
std::string ResultType;
+ /// Swift name of this entity.
+ std::string SwiftReturnOwnership;
Xazax-hun wrote:
Do we need a string to re
https://github.com/Xazax-hun requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/118938
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
> If that's the intended meaning, should we restrict this to structs that have
> pointer fields?
Yeah, that is the intended meaning. I am on the fence about restricting to
structs with pointers though, mostly to more ergonomically support use cases
like:
```
struct Sometimes
Xazax-hun wrote:
> Why should this live upstream if it basically only benefits a single
> downstream?
This is a fair question, my intuition was that if the need came up multiple
times independently, it might be worth to have it upstream. But it is also fair
to wait until there is an actual up
Xazax-hun wrote:
> What is it that consumes this?
We are planning to consume this downstream in the Swift compiler for C++
interop. Swift has non-escapable types, like Swift's `Span` type. The interop
layer cannot bridge a C++ `std::span` as Swift's `Span` without this additional
information
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/117344
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Xazax-hun wrote:
> I'd like to see a test that validates this changes with these types.
Sorry, I missed the part in CodeGen. So `noescape` is used to emit the
`nocapute` parameter attribute in the LLVM IR. This parameter attribute is only
valid for pointers and we currently do not seem to hav
https://github.com/Xazax-hun updated
https://github.com/llvm/llvm-project/pull/117344
From d48e28d43473b317a74bd8fe3b2f62e8f99ed3c8 Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Fri, 22 Nov 2024 16:19:35 +
Subject: [PATCH] [Clang] Permit noescape on non-pointer types
In modern C++ we
https://github.com/Xazax-hun updated
https://github.com/llvm/llvm-project/pull/117344
From f6bb3c5d93ea7847499f801190026ac46fdc Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Fri, 22 Nov 2024 16:19:35 +
Subject: [PATCH] [Clang] Permit noescape on non-pointer types
In modern C++ we
https://github.com/Xazax-hun updated
https://github.com/llvm/llvm-project/pull/117344
From 12a608aa8e6844a171200849e30eedd79cdfb4d8 Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Fri, 22 Nov 2024 16:19:35 +
Subject: [PATCH] [Clang] Permit noescape on non-pointer types
In modern C++ we
https://github.com/Xazax-hun updated
https://github.com/llvm/llvm-project/pull/117344
From bd733eec17fdd76a1154d7881f47de2f30b41243 Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Fri, 22 Nov 2024 16:19:35 +
Subject: [PATCH] [Clang] Permit noescape on non-pointer types
In modern C++ we
Xazax-hun wrote:
> I want to see something that shows that the attribute is actually DOING
> something on non-pointer types.
I added a test to make sure the attribute is actually applied to the AST.
Admittedly, there is not a lot that this can be used for as of now (other than
documenting the
@@ -1,7 +1,12 @@
// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
template
void test1(T __attribute__((noescape)) arr, int size);
-// expected-warning@+1 {{'noescape' attribute only applies to pointer
arguments}}
-void test2(int __attribute__((noes
Xazax-hun wrote:
Sorry, I might have been a bit unclear.
> We should never have reference typed value regions wrapped by subregions.
I think my question is what makes the "wrapped by subregions" part special? Why
not just "never have reference typed value regions"?
https://github.com/llvm/llv
https://github.com/Xazax-hun approved this pull request.
The change itself looks good to me, but I wonder what is the reason that we
only want to do this canonicalization when we access fields?
https://github.com/llvm/llvm-project/pull/118096
___
cfe-
https://github.com/Xazax-hun approved this pull request.
LGTM! Did you run it over a couple of open source projects to check if there is
any difference in the diagnostics?
https://github.com/llvm/llvm-project/pull/117898
___
cfe-commits mailing list
c
https://github.com/Xazax-hun approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -278,7 +278,9 @@ class ExplodedNode : public llvm::FoldingSetNode {
/// Useful for explaining control flow that follows the current node.
/// If the statement belongs to a body-farmed definition, retrieve the
/// call site for that definition.
- const Stmt *getNextStm
https://github.com/Xazax-hun commented:
Great fix! I have one question inline.
https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -347,8 +347,11 @@ const Stmt *ExplodedNode::getStmtForDiagnostics() const {
return nullptr;
}
-const Stmt *ExplodedNode::getNextStmtForDiagnostics() const {
+const Stmt *ExplodedNode::getNextStmtForDiagnostics(bool skipPurge) const {
for (const ExplodedNode *N = getFir
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/117863
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -278,7 +278,9 @@ class ExplodedNode : public llvm::FoldingSetNode {
/// Useful for explaining control flow that follows the current node.
/// If the statement belongs to a body-farmed definition, retrieve the
/// call site for that definition.
- const Stmt *getNextStm
https://github.com/Xazax-hun approved this pull request.
LGTM, could you add a summary of the change to the commit message? I know the
context is available in the linked issue, but I'd like the gist of it to be
preserved in the commit history directly.
https://github.com/llvm/llvm-project/pul
https://github.com/Xazax-hun created
https://github.com/llvm/llvm-project/pull/117344
In modern C++ we often use span, string_view or other view objects instead of
raw pointers. This PR opens the door to mark those noescape. This can be useful
to document the API contracts, for interop with me
@@ -7,3 +7,106 @@ struct S {
};
// CHECK: CXXMethodDecl {{.*}}clang::lifetime_capture_by(a, b, global)
+
+//
+// Infer annotation for STL container methods.
+// ***
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/117122
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun approved this pull request.
Once @hokein's comments are addressed, it looks good to me.
https://github.com/llvm/llvm-project/pull/117122
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
https://github.com/Xazax-hun created
https://github.com/llvm/llvm-project/pull/117194
In case a method already is lifetimebound annotated we should not add a second
annotation to the type.
From 9980bec9888d1356fbf330dc4355ba8be24955cf Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Thu, 21
@@ -268,6 +268,40 @@ void Sema::inferLifetimeBoundAttribute(FunctionDecl *FD) {
}
}
+static bool IsPointerLikeType(QualType QT) {
+ QT = QT.getNonReferenceType();
+ if (QT->isPointerType())
+return true;
+ auto *RD = QT->getAsCXXRecordDecl();
+ if (!RD)
+return f
https://github.com/Xazax-hun approved this pull request.
Thanks for the update, the latest version LGTM.
https://github.com/llvm/llvm-project/pull/114044
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
https://github.com/Xazax-hun approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/115921
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -793,3 +793,108 @@ void test13() {
}
} // namespace GH100526
+
+namespace lifetime_capture_by {
+struct S {
+ const int *x;
+ void captureInt(const int&x [[clang::lifetime_capture_by(this)]]) { this->x
= &x; }
+ void captureSV(std::string_view sv [[clang::lifetime_captu
@@ -249,9 +254,10 @@ static void
visitLocalsRetainedByReferenceBinding(IndirectLocalPath &Path,
LocalVisitor Visit);
template static bool isRecordWithAttr(QualType Type) {
- if (auto *RD = Type->getAsCXXRecordDecl())
-re
https://github.com/Xazax-hun closed
https://github.com/llvm/llvm-project/pull/115866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1266,11 +1266,11 @@ class CommonTypeTableInfo
class TagTableInfo : public CommonTypeTableInfo {
public:
unsigned getUnversionedInfoSize(const TagInfo &TI) {
-return 2 + (TI.SwiftImportAs ? TI.SwiftImportAs->size() : 0) +
- 2 + (TI.SwiftRetainOp ? TI.SwiftRet
https://github.com/Xazax-hun updated
https://github.com/llvm/llvm-project/pull/115866
From cdb2a965d3aae112f6661ea80b62fdc25a7d3837 Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Tue, 12 Nov 2024 13:07:01 +
Subject: [PATCH] [clang][APINotes] Add support for the SwiftEscapable
attribute
@@ -3919,7 +3919,24 @@ static void HandleLifetimeCaptureByAttr(Sema &S, Decl *D,
void Sema::LazyProcessLifetimeCaptureByParams(FunctionDecl *FD) {
bool HasImplicitThisParam = isInstanceMethod(FD);
-
+ SmallVector Attrs;
+ for (ParmVarDecl *PVD : FD->parameters())
+if (
https://github.com/Xazax-hun created
https://github.com/llvm/llvm-project/pull/115866
This is similar to SwiftCopyable. Also fix missing SwiftCopyable dump for
TagInfo.
From 70ebdd0a63397130e45b79b3c6096c1847c07110 Mon Sep 17 00:00:00 2001
From: Gabor Horvath
Date: Tue, 12 Nov 2024 13:07:01 +
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/111499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3967,6 +3967,69 @@ Attribute ``trivial_abi`` has no effect in the following
cases:
}];
}
+
+def LifetimeCaptureByDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+The ``lifetime_capture_by(X)`` attribute on a function parameter or
implic
@@ -3967,6 +3967,69 @@ Attribute ``trivial_abi`` has no effect in the following
cases:
}];
}
+
+def LifetimeCaptureByDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+The ``lifetime_capture_by(X)`` attribute on a function parameter or
implic
@@ -3967,6 +3967,69 @@ Attribute ``trivial_abi`` has no effect in the following
cases:
}];
}
+
+def LifetimeCaptureByDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+The ``lifetime_capture_by(X)`` attribute on a function parameter or
implic
@@ -1889,6 +1889,40 @@ def LifetimeBound : DeclOrTypeAttr {
let SimpleHandler = 1;
}
+def LifetimeCaptureBy : DeclOrTypeAttr {
+ let Spellings = [Clang<"lifetime_capture_by", 0>];
+ let Subjects = SubjectList<[ParmVar, ImplicitObjectParameter], ErrorDiag>;
+ let Args = [V
@@ -3867,6 +3868,105 @@ static void handleCallbackAttr(Sema &S, Decl *D, const
ParsedAttr &AL) {
S.Context, AL, EncodingIndices.data(), EncodingIndices.size()));
}
+LifetimeCaptureByAttr *Sema::ParseLifetimeCaptureByAttr(const ParsedAttr &AL,
+
@@ -3967,6 +3967,69 @@ Attribute ``trivial_abi`` has no effect in the following
cases:
}];
}
+
+def LifetimeCaptureByDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+The ``lifetime_capture_by(X)`` attribute on a function parameter or
implic
https://github.com/Xazax-hun approved this pull request.
Some nits inline, but overall looks good for me.
https://github.com/llvm/llvm-project/pull/111499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/Xazax-hun edited
https://github.com/llvm/llvm-project/pull/111499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1199,6 +1213,17 @@ static void checkExprLifetimeImpl(Sema &SemaRef,
break;
}
+case LK_LifetimeCapture: {
+ if (!MTE)
Xazax-hun wrote:
Ah, makes sense. I guess there is only one case when we could potentially get
away with this, when `a
https://github.com/Xazax-hun closed
https://github.com/llvm/llvm-project/pull/115482
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Xazax-hun created
https://github.com/llvm/llvm-project/pull/115482
Lifetimebound annotations can help diagnose common cases of dangling including
escaping the address of a stack variable from a function. This is useful in all
C family languages, restricting these diagnostics
1 - 100 of 779 matches
Mail list logo
