https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/78103
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/78836
This patch prevents tests for unresolved issues to report availability (e.g.
`no` or `18`) on `cxx_dr_status.html` page. But it still checks whether
specified status matches status on the official list, preventi
Endilll wrote:
@cor3ntin During our offline discussion with @AaronBallman, points "we don't
want to read tea leaves" and "CWG can change their opinion" were repeated so
often, that I thought we have consensus on using only official source on
information, i.e. issue list. I also don't see why i
Endilll wrote:
> I have reviewed the tests for libclang and it appears that there are already
> tests for the rewriter, which are more extensive than the ones I wrote.
> Therefore, I have decided to mirror the tests from libclang in the Python
> binding. Please let me know if this approach is
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/77269
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/78793
>From f6a599d6e662121f19529f59ffa44cc6177c0835 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sat, 20 Jan 2024 00:58:06 +0300
Subject: [PATCH] [clang] Remove `CXXNewInitializationStyle::Implicit`
This i
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/78898
Fixes #10518
Fixes #67914
Fixes #78388
Also addresses the second example in #49103
This patch is based on suggestion from @cor3ntin in
https://github.com/llvm/llvm-project/issues/67914#issuecomment-1896011898
>
Endilll wrote:
I decided to not include tests, because our testing infrastructure is not ready
to test that Clang doesn't crash without overspecifying the tests using
`-verify` mode.
https://github.com/llvm/llvm-project/pull/78898
___
cfe-commits mai
https://github.com/Endilll approved this pull request.
LGTM
PR description is going to become a commit message after merging. Let me know
when it's ready.
https://github.com/llvm/llvm-project/pull/77269
___
cfe-commits mailing list
cfe-commits@lists.l
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/78338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/78793
>From f6a599d6e662121f19529f59ffa44cc6177c0835 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sat, 20 Jan 2024 00:58:06 +0300
Subject: [PATCH] [clang] Remove `CXXNewInitializationStyle::Implicit`
This i
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/78793
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
@linux4life798 Nice catch! I see that so far only `CompilationDatabase` and
`CompletionChunk` expose functions in camelCase. It would be nice to change
them, too, but those are decade-old APIs that _I think_ we promise stability
for, so it might not be possible.
https://github.
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/78095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/78095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
> Could you elaborate a bit more on that? What is the exact problem with the
> testing infrastructure? Can we just add a separate test with the cases from
> the issues, perhaps without -verify at all?
1) I think that the most reliable way to detect a crash would be to leverage
Endilll wrote:
> So, there is no way to consistently check on all platforms that we didn't
> crash when an error diagnostic was issued (does clang return non-zero when
> there is error diagnostic?), is that a right understanding?
Yes. On Linux and Windows `1` is returned if error diagnostic wa
Endilll wrote:
> why can't we add -verify test? Yes, it will be checking errors that the patch
> didn't touch, but it is what mostly people do when adding clang tests and it
> will be +N test cases in a regular test base which not only ensure your
> change is correct, but the future ones too.
Endilll wrote:
So my takeaways here are:
1. Tests that ensure we don't crash anymore are important for us.
2. `-verify` is an acceptable way to write such tests.
Is this correct?
https://github.com/llvm/llvm-project/pull/78898
___
cfe-commits mailing
Endilll wrote:
@linux4life798 Do you mind filing issues for the points you highlighted? Feel
free to skip this step if you (or someone else) plan to submit PRs that address
them.
https://github.com/llvm/llvm-project/pull/77269
___
cfe-commits mailing
Endilll wrote:
@erichkeane I guess you'd be pretty happy if our enums were declared the
following way:
```cpp
enum E : unsigned _BitInt(4) {
e0 = 16,
};
```
Then you'd be warned on the spot if you have more values than bits can hold,
and bit-fields side check would be trivial to implement:
``
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 1/4] [clang] Add clang::debug_info_type attribute
---
clang
@@ -107,6 +107,10 @@ def NonBitField : SubsetSubjectisBitField()}],
"non-bit-field non-static data members">;
+def BitField : SubsetSubjectisBitField()}],
+ "bit-field non-static data members">;
Endill
@@ -7219,6 +7219,18 @@ its underlying representation to be a WebAssembly
``funcref``.
}];
}
+def DebugInfoTypeDocumentation : Documentation {
+ let Category = DocCatField;
+ let Content = [{
+This attribute allows to alter type of a bitfield in debug information.
+Such a
@@ -7219,6 +7219,18 @@ its underlying representation to be a WebAssembly
``funcref``.
}];
}
+def DebugInfoTypeDocumentation : Documentation {
+ let Category = DocCatField;
+ let Content = [{
+This attribute allows to alter type of a bitfield in debug information.
+Such a
@@ -3153,6 +3153,8 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_unde
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
@@ -0,0 +1,14 @@
+// RUN: %clang -target x86_64-linux -g -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -verify -DMISMATCH %s
Endilll wrote:
Tests are split now. `const` case is now checked and working as expected
(qualifiers are ignored).
https://git
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
@@ -5910,6 +5910,28 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 1/5] [clang] Add clang::debug_info_type attribute
---
clang
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -verify %s
+
+struct A {
+ enum E : unsigned {};
+ [[clang::preferred_type(E)]] unsigned b : 2;
+ [[clang::preferred_type(E)]] int b2 : 2;
+ // expected-warning@-1 {{underlying type 'unsigned int' of enumeration 'E'
doesn't match bit-field
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/69104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -5910,6 +5910,28 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
Endilll wrote:
>>@erichkeane I guess you'd be pretty happy if our enums were declared the
>> following way:
>Not really? That doesn't gain us the 'we must change where this is stored'
>situation like a preferred_type attribute would/could. We MIGHT be able to get
>away with a comment on t
Endilll wrote:
Taking the example above, I think it would have to look the following way to
fully complement a check for bit-field width in `preferred_type`:
```cpp
enum StoredNameKind : unsigned _BitInt(3) {
StoredIdentifier = 0,
StoredObjCZeroArgSelector = Selector::ZeroArg,
Store
Endilll wrote:
> See how on the assignment to a bitfield we check to make sure the largest
> value of the enum will fit in the bitfield? I'm saying I want us to do this
> EARLIER, on declaration with this attribute.
I totally do. Thank you for pointing out to `-Wbitfield-enum-conversion`! But
Endilll wrote:
> when does someone have an enum value that they don't intend to ever be in the
> enum
In my previous comments
(https://github.com/llvm/llvm-project/pull/69104#issuecomment-1771167758,
https://github.com/llvm/llvm-project/pull/69104#issuecomment-1771204043) I
provided an examp
Endilll wrote:
> which brings up an additional concern/thing to deal with for the non_storable
> attribute (that is, do we apply it to assignments? how about
> exact-assignments like you've done there?).
Conservative approach would be to issue diagnostics based on `non_storable`
only when LHS
Endilll wrote:
> There's some danger here. _BitInt is a C23 feature as are enumerations with a
> fixed underlying type. Enumerations with a fixed underlying type explicitly
> disallow using a bit-precise integer type as the underlying type. See C23
> 6.7.2.2p4, which says in part, "For all the
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 1/6] [clang] Add clang::debug_info_type attribute
---
clang
@@ -5910,6 +5910,28 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 1/7] [clang] Add clang::debug_info_type attribute
---
clang
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
Endilll wrote:
I'm ignoring signed/unsigned mismatch as @erichkeane and @AaronBallman
suggested. The only outstanding aspect is the following diagnostic I added
today and haven't received feedback on:
```cpp
[[clang::preferred_type(bool)]] unsigned b4 : 1;
[[clang::preferred_type(bool)]] un
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 1/8] [clang] Add clang::debug_info_type attribute
---
clang
Endilll wrote:
> While I think that warning is accurate, I somewhat question the value of the
> 'bool' as working on this type
I'm not sure what you mean by "working" here, but I'd like to highlight that we
have hundreds of single-bit bit-fields across Clang that would benefit from
`[[clang::
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 1/9] [clang] Add clang::debug_info_type attribute
---
clang
@@ -5910,6 +5910,51 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handlePreferredTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
Endilll wrote:
> However, will this actually work in practice in the debugger? If not, perhaps
> we should limit to just integer and enumeration types for now, leaving the
> extension for the future.
I composed an example of that:
```cpp
struct A {
short a1;
short a2;
};
struct B {
[[cl
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_und
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 01/10] [clang] Add clang::debug_info_type attribute
---
cla
@@ -5910,6 +5910,51 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handlePreferredTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 01/11] [clang] Add clang::debug_info_type attribute
---
cla
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_und
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 01/12] [clang] Add clang::debug_info_type attribute
---
cla
Endilll wrote:
> but I also see "you got what you asked for!" as being a reasonable defense to
> that.
That's my thinking indeed, and the reason why I opposed to Aaron's proposal to
implicitly mark 1-bit bit-fields as `preferred_type(bool)`.
https://github.com/llvm/llvm-project/pull/69104
___
https://github.com/Endilll approved this pull request.
LGTM, but you should wait for other reviewers before merging.
https://github.com/llvm/llvm-project/pull/67213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/67213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1488,6 +1491,8 @@ markup::Document HoverInfo::present() const {
llvm::formatv(" (+{0} padding)", formatSize(*Padding)).str());
}
}
+ if (Align)
+Output.addParagraph().appendText("Align: " + formatSize(*Align));
Endilll wrote:
My prefer
Endilll wrote:
On the topic of ABI, Itanium and Microsoft type layouts are not compatible,
even for standard-layout (POD) types. For
[example](https://godbolt.org/z/zxfvMa9nE), bit-fields are
[allowed](http://eel.is/c++draft/class.prop#3) in standard-layout types, but
only Microsoft ABI manda
@@ -1488,6 +1491,8 @@ markup::Document HoverInfo::present() const {
llvm::formatv(" (+{0} padding)", formatSize(*Padding)).str());
}
}
+ if (Align)
+Output.addParagraph().appendText("Align: " + formatSize(*Align));
Endilll wrote:
That woul
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/67213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/69916
Refactor `uintptr_t` inside of `clang::Selector` that holds a pointer to
`IdentifierInfo` or `MultiKeywordSelector` and `IdentifierInfoFlag` enum into
`PointerIntPair`. This is a part of `PointerIntPair` migrati
@@ -5910,6 +5910,30 @@ static void handleBuiltinAliasAttr(Sema &S, Decl *D,
D->addAttr(::new (S.Context) BuiltinAliasAttr(S.Context, AL, Ident));
}
+static void handleDebugInfoTypeAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+ if (!AL.hasParsedType()) {
+S.Diag(AL.get
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69104
>From 976aa5c8f3d936a15e7123069a49d97ad3bf7a05 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Sun, 15 Oct 2023 13:14:55 +0300
Subject: [PATCH 01/14] [clang] Add clang::debug_info_type attribute
---
cla
@@ -7219,6 +7219,31 @@ its underlying representation to be a WebAssembly
``funcref``.
}];
}
+def PreferredTypeDocumentation : Documentation {
+ let Category = DocCatField;
+ let Content = [{
+This attribute allows adjusting the type of a bit-field in debug information.
+T
@@ -7219,6 +7219,31 @@ its underlying representation to be a WebAssembly
``funcref``.
}];
}
+def PreferredTypeDocumentation : Documentation {
+ let Category = DocCatField;
+ let Content = [{
+This attribute allows adjusting the type of a bit-field in debug information.
+T
Endilll wrote:
Thank you @AaronBallman for writing even more documentation!
https://github.com/llvm/llvm-project/pull/69104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/69104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -809,43 +927,42 @@ class Selector {
enum IdentifierInfoFlag {
// Empty selector = 0. Note that these enumeration values must
// correspond to the enumeration values of DeclarationName::StoredNameKind
-ZeroArg = 0x01,
-OneArg = 0x02,
+ZeroArg = 0x01,
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69916
>From 58ebdda4e44b3fa2547d85a6cc9d5b0aa913b22a Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Mon, 23 Oct 2023 13:55:46 +0300
Subject: [PATCH 1/2] [clang][NFC] Refactor `Selector` to use `PointerIntPair`
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/69916
>From 58ebdda4e44b3fa2547d85a6cc9d5b0aa913b22a Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Mon, 23 Oct 2023 13:55:46 +0300
Subject: [PATCH 1/3] [clang][NFC] Refactor `Selector` to use `PointerIntPair`
https://github.com/Endilll approved this pull request.
DR test part of this PR looks fine to me.
https://github.com/llvm/llvm-project/pull/70018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
@@ -809,43 +927,42 @@ class Selector {
enum IdentifierInfoFlag {
// Empty selector = 0. Note that these enumeration values must
// correspond to the enumeration values of DeclarationName::StoredNameKind
-ZeroArg = 0x01,
-OneArg = 0x02,
+ZeroArg = 0x01,
@@ -809,43 +927,42 @@ class Selector {
enum IdentifierInfoFlag {
// Empty selector = 0. Note that these enumeration values must
// correspond to the enumeration values of DeclarationName::StoredNameKind
-ZeroArg = 0x01,
-OneArg = 0x02,
+ZeroArg = 0x01,
@@ -809,43 +927,42 @@ class Selector {
enum IdentifierInfoFlag {
// Empty selector = 0. Note that these enumeration values must
// correspond to the enumeration values of DeclarationName::StoredNameKind
-ZeroArg = 0x01,
-OneArg = 0x02,
+ZeroArg = 0x01,
@@ -809,43 +927,42 @@ class Selector {
enum IdentifierInfoFlag {
// Empty selector = 0. Note that these enumeration values must
// correspond to the enumeration values of DeclarationName::StoredNameKind
-ZeroArg = 0x01,
-OneArg = 0x02,
+ZeroArg = 0x01,
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/69916
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/70296
This patch refactor said enums to hold total size of a bit-field, and not just
non-inherited bits. This brings `Type` and `DeclContext` in line with `Comment`
and `Stmt`. It also makes it unnecessary to list all
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/70296
>From 9a20b9609c5d4c18772907e82af4995411c42da6 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Thu, 26 Oct 2023 09:04:22 +0300
Subject: [PATCH 1/2] [clang][NFC] Refactor enums that hold size of Type and
@@ -1819,10 +1812,10 @@ class DeclContext {
SourceLocation AtStart;
};
- /// Number of non-inherited bits in ObjCContainerDeclBitfields.
+ /// Number of inherited and non-inherited bits in ObjCContainerDeclBitfields.
/// Note that here we rely on the fact that Sourc
@@ -1739,10 +1734,8 @@ class DeclContext {
uint64_t IsSimpleExplicit : 1;
};
- /// Number of non-inherited bits in CXXConstructorDeclBitfields.
- enum {
-NumCXXConstructorDeclBits = 64 - NumDeclContextBits - NumFunctionDeclBits
- };
+ /// Number of inherited and
@@ -1663,11 +1663,12 @@ class alignas(TypeAlignment) Type : public
ExtQualsTypeCommonBase {
/// Actually an ArrayType::ArraySizeModifier.
unsigned SizeModifier : 3;
};
+ enum { NumArrayTypeBits = NumTypeBits + 3 + 3 };
Endilll wrote:
Applied.
http
https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/70296
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/70349
This patch adds `clang::preferred_type` annotations to Type-related bit-fields
where possible. Notable exception are bit-fields that hold values of types that
are incomplete at bit-field declaration. This is a l
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/70349
>From 7329f68092d5f8f5a5978e5a6cbad6ada87d4fe8 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Thu, 26 Oct 2023 16:09:25 +0300
Subject: [PATCH 1/3] [clang][NFC] Annotate `Type` bit-fields with
`clang::pr
https://github.com/Endilll created
https://github.com/llvm/llvm-project/pull/70360
This patch addresses some example of bad formatting in Clang. The following
commit contains only changes suggested by clang-format:
https://github.com/llvm/llvm-project/pull/70349/commits/21689b56d1fc1db0b2263e8
Endilll wrote:
Formatting is good. I created a PR against `clang-format` to convince the tool:
https://github.com/llvm/llvm-project/pull/70360
https://github.com/llvm/llvm-project/pull/70349
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/70360
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
[Mozilla](https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html),
[WebKit](https://webkit.org/code-style-guidelines/),
[GCC](https://gcc.gnu.org/codingconventions.html#Cxx_Conventions),
[Microsoft](https://learn.microsoft.com/en-us/dotnet/csharp
@@ -49,7 +49,7 @@ struct ExprDependenceScope {
using ExprDependence = ExprDependenceScope::ExprDependence;
struct TypeDependenceScope {
- enum TypeDependence : uint8_t {
+ enum TypeDependence : unsigned {
Endilll wrote:
The only place this enum is stored is
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/70349
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -49,7 +49,7 @@ struct ExprDependenceScope {
using ExprDependence = ExprDependenceScope::ExprDependence;
struct TypeDependenceScope {
- enum TypeDependence : uint8_t {
+ enum TypeDependence : unsigned {
Endilll wrote:
In this particular case, width of bit
@@ -20,7 +20,7 @@ namespace clang {
/// Describes the different kinds of linkage
/// (C++ [basic.link], C99 6.2.2) that an entity may have.
-enum Linkage : unsigned char {
+enum Linkage : unsigned {
Endilll wrote:
This case is similar to `TypeDependence` we d
Endilll wrote:
@tbaederr As highlighted in https://github.com/llvm/llvm-project/pull/69104,
this attribute doesn't change semantics of the program, so it's safe to ignore.
https://github.com/llvm/llvm-project/pull/70349
___
cfe-commits mailing list
cf
Endilll wrote:
That's a good point. I'm not opposed to wrap this attribute if we must. I'd
like to hear from @AaronBallman on this matter.
https://github.com/llvm/llvm-project/pull/70349
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
601 - 700 of 2136 matches
Mail list logo
