|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
665da187 |
| 15-Jun-2022 |
Martin Boehme <[email protected]> |
[Clang] Add the `annotate_type` attribute
This is an analog to the `annotate` attribute but for types. The intent is to allow adding arbitrary annotations to types for use in static analysis tools.
[Clang] Add the `annotate_type` attribute
This is an analog to the `annotate` attribute but for types. The intent is to allow adding arbitrary annotations to types for use in static analysis tools.
For details, see this RFC:
https://discourse.llvm.org/t/rfc-new-attribute-annotate-type-iteration-2/61378
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D111548
show more ...
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
671eb7dc |
| 29-May-2022 |
Matheus Izvekov <[email protected]> |
[clang] AST/Print: honor AlwaysIncludeTypeForTemplateArgument policy
This redoes D103040 in a way that `AlwaysIncludeTypeForTemplateArgument = false` policy is honored for printing template speciali
[clang] AST/Print: honor AlwaysIncludeTypeForTemplateArgument policy
This redoes D103040 in a way that `AlwaysIncludeTypeForTemplateArgument = false` policy is honored for printing template specialization types. This can be seen for example when printing a canonicalized dependent TemplateSpecializationType which has integral arguments.
Signed-off-by: Matheus Izvekov <[email protected]>
Reviewed By: v.g.vassilev
Differential Revision: https://reviews.llvm.org/D126620
show more ...
|
|
Revision tags: llvmorg-14.0.4 |
|
| #
83c431fb |
| 20-May-2022 |
Jon Chesterfield <[email protected]> |
[amdgpu] Add amdgpu_kernel calling conv attribute to clang
Allows emitting define amdgpu_kernel void @func() IR from C or C++.
This replaces the current workflow which is to write a stub in opencl
[amdgpu] Add amdgpu_kernel calling conv attribute to clang
Allows emitting define amdgpu_kernel void @func() IR from C or C++.
This replaces the current workflow which is to write a stub in opencl that calls an external C function implemented in C++ combined through llvm-link.
Calling the resulting function still requires a manual implementation of the ABI from the host side. The primary application is for more rapid debugging of the amdgpu backend by permuting a C or C++ test file instead of manually updating an IR file.
Implementation closely follows D54425. Non-amd reviewers from there.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D125970
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
75bb8152 |
| 29-Mar-2022 |
Matt Devereau <[email protected]> |
[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang
Enable function attribute aarch64_sve_pcs at the C level, which correspondes to aarch64_sve_vector_pcs at the LLVM IR level.
This requirement w
[AArch64][SVE] Add aarch64_sve_pcs attribute to Clang
Enable function attribute aarch64_sve_pcs at the C level, which correspondes to aarch64_sve_vector_pcs at the LLVM IR level.
This requirement was created by this addition to the ARM C Language Extension: https://github.com/ARM-software/acle/pull/194
Differential Revision: https://reviews.llvm.org/D124998
show more ...
|
| #
b6572ad5 |
| 10-May-2022 |
Erich Keane <[email protected]> |
[NFC] Add missing 'break' in a switch case
|
| #
225b91e6 |
| 22-Apr-2022 |
Tom Eccles <[email protected]> |
Fix crash getting name of a template decl
NamedDecl::getIdentifier can return a nullptr when DeclarationName::isIdentifier is false, which leads to a null pointer dereference when TypePrinter::print
Fix crash getting name of a template decl
NamedDecl::getIdentifier can return a nullptr when DeclarationName::isIdentifier is false, which leads to a null pointer dereference when TypePrinter::printTemplateId calls ->getName().
NamedDecl::getName does the same thing in the successful case and returns an empty string in the failure case.
This crash affects the llvm 14 packages on llvm.org.
show more ...
|
| #
cfb81690 |
| 20-Apr-2022 |
Nathan James <[email protected]> |
[clang] Add a raw_ostream operator<< overload for QualType
Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostrea
[clang] Add a raw_ostream operator<< overload for QualType
Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostream.
Also cleaned up all the call sites where this occurs.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123926
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
3251ba2d |
| 04-Mar-2022 |
Yonghong Song <[email protected]> |
[Attr] Fix a btf_type_tag AST generation
Current ASTContext.getAttributedType() takes attribute kind, ModifiedType and EquivType as the hash to decide whether an AST node has been generated or note.
[Attr] Fix a btf_type_tag AST generation
Current ASTContext.getAttributedType() takes attribute kind, ModifiedType and EquivType as the hash to decide whether an AST node has been generated or note. But this is not enough for btf_type_tag as the attribute might have the same ModifiedType and EquivType, but still have different string associated with attribute.
For example, for a data structure like below, struct map_value { int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a; int __attribute__((btf_type_tag("tag2"))) __attribute__((btf_type_tag("tag4"))) *b; }; The current ASTContext.getAttributedType() will produce an AST similar to below: struct map_value { int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *a; int __attribute__((btf_type_tag("tag1"))) __attribute__((btf_type_tag("tag3"))) *b; }; and this is incorrect.
It is very difficult to use the current AttributedType as it is hard to get the tag information. To fix the problem, this patch introduced BTFTagAttributedType which is similar to AttributedType in many ways but with an additional BTFTypeTagAttr. The tag itself can be retrieved with BTFTypeTagAttr. With the new BTFTagAttributed type, the debuginfo code can be greatly simplified compared to previous TypeLoc based approach.
Differential Revision: https://reviews.llvm.org/D120296
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
33c3ef2f |
| 30-Dec-2021 |
Sam McCall <[email protected]> |
[CodeCompletion][clangd] Clean __uglified parameter names in completion & hover
Underscore-uglified identifiers are used in standard library implementations to guard against collisions with macros,
[CodeCompletion][clangd] Clean __uglified parameter names in completion & hover
Underscore-uglified identifiers are used in standard library implementations to guard against collisions with macros, and they hurt readability considerably. (Consider `push_back(Tp_ &&__value)` vs `push_back(Tp value)`. When we're describing an interface, the exact names of parameters are not critical so we can drop these prefixes.
This patch adds a new PrintingPolicy flag that can applies this stripping when recursively printing pieces of AST. We set it in code completion/signature help, and in clangd's hover display. All three features also do a bit of manual poking at names, so fix up those too.
Fixes https://github.com/clangd/clangd/issues/736
Differential Revision: https://reviews.llvm.org/D116387
show more ...
|
| #
e27b5f93 |
| 03-Jan-2022 |
Ellis Hoag <[email protected]> |
[clang][AST] Fix crash when printing error
Clang will crash if it tries to compile the following code. This commit fixes it. ``` $ cat foo.c void foo(_Nullable int *ptr) { __auto_type _Nonnull a
[clang][AST] Fix crash when printing error
Clang will crash if it tries to compile the following code. This commit fixes it. ``` $ cat foo.c void foo(_Nullable int *ptr) { __auto_type _Nonnull a = ptr; }; $ clang foo.c -c -Wnullable-to-nonnull-conversion ```
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D116342
show more ...
|
| #
af27466c |
| 20-Dec-2021 |
Sam McCall <[email protected]> |
Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a. Fixed a bad assertion, the target of a UsingShadowDecl must not
Reland "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit cc56c66f27e131b914082d3bd21180646e842e9a. Fixed a bad assertion, the target of a UsingShadowDecl must not have *local* qualifiers, but it can be a typedef whose underlying type is qualified.
show more ...
|
| #
cc56c66f |
| 20-Dec-2021 |
Sam McCall <[email protected]> |
Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.
Breaks sanitizer tests, at least on windows: https://lab.llvm.
Revert "[AST] Add UsingType: a sugar type for types found via UsingDecl"
This reverts commit e1600db19d6303f84b995acb9340459694e06ea9.
Breaks sanitizer tests, at least on windows: https://lab.llvm.org/buildbot/#/builders/127/builds/21592/steps/4/logs/stdio
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
e1600db1 |
| 19-Nov-2021 |
Sam McCall <[email protected]> |
[AST] Add UsingType: a sugar type for types found via UsingDecl
Currently there's no way to find the UsingDecl that a typeloc found its underlying type through. Compare to DeclRefExpr::getFoundDecl(
[AST] Add UsingType: a sugar type for types found via UsingDecl
Currently there's no way to find the UsingDecl that a typeloc found its underlying type through. Compare to DeclRefExpr::getFoundDecl().
Design decisions: - a sugar type, as there are many contexts this type of use may appear in - UsingType is a leaf like TypedefType, the underlying type has no TypeLoc - not unified with UnresolvedUsingType: a single name is appealing, but being sometimes-sugar is often fiddly. - not unified with TypedefType: the UsingShadowDecl is not a TypedefNameDecl or even a TypeDecl, and users think of these differently. - does not cover other rarer aliases like objc @compatibility_alias, in order to be have a concrete API that's easy to understand. - implicitly desugared by the hasDeclaration ASTMatcher, to avoid breaking existing patterns and following the precedent of ElaboratedType.
Scope: - This does not cover types associated with template names introduced by using declarations. A future patch should introduce a sugar TemplateName variant for this. (CTAD deduced types fall under this) - There are enough AST matchers to fix the in-tree clang-tidy tests and probably any other matchers, though more may be useful later.
Caveats: - This changes a fairly common pattern in the AST people may depend on matching. Previously, typeLoc(loc(recordType())) matched whether a struct was referred to by its original scope or introduced via using-decl. Now, the using-decl case is not matched, and needs a separate matcher. This is similar to the case of typedefs but nevertheless both adds complexity and breaks existing code.
Differential Revision: https://reviews.llvm.org/D114251
show more ...
|
| #
6c75ab5f |
| 06-Dec-2021 |
Aaron Ballman <[email protected]> |
Introduce _BitInt, deprecate _ExtInt
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitI
Introduce _BitInt, deprecate _ExtInt
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out:
* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors.
I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
show more ...
|
| #
eb0fa8bf |
| 04-Nov-2021 |
Yonghong Song <[email protected]> |
[Clang][Attr] Support btf_type_tag attribute
This patch introduced btf_type_tag attribute. The attribute is a type attribute and intends to address the below linux use cases. typedef int __user
[Clang][Attr] Support btf_type_tag attribute
This patch introduced btf_type_tag attribute. The attribute is a type attribute and intends to address the below linux use cases. typedef int __user *__intp; int foo(int __user *arg, ...) static int do_execve(struct filename *filename, const char __user *const __user *__argv, const char __user *const __user *__envp)
Here __user in the kernel defined as __attribute__((noderef, address_space(__user))) for sparse ([1]) type checking mode.
For normal clang compilation, we intend to replace it with __attribute__((btf_type_tag("user"))) and record such informaiton in dwarf and BTF so such information later can be used in kernel for bpf verification or for other tracing functionalities.
[1] https://www.kernel.org/doc/html/v4.11/dev-tools/sparse.html
Differential Revision: https://reviews.llvm.org/D111199
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4 |
|
| #
8bf12445 |
| 20-Sep-2021 |
David Blaikie <[email protected]> |
DebugInfo: workaround for context-sensitive use of non-type-template-parameter integer suffixes
There's a nuanced check about when to use suffixes on these integer non-type-template-parameters, but
DebugInfo: workaround for context-sensitive use of non-type-template-parameter integer suffixes
There's a nuanced check about when to use suffixes on these integer non-type-template-parameters, but when rebuilding names for -gsimple-template-names there isn't enough data in the DWARF to determine when to use suffixes or not. So turn on suffixes always to make it easy to match up names in llvm-dwarfdump --verify.
I /think/ if we correctly modelled auto non-type-template parameters maybe we could put suffixes only on those. But there's also some logic in Clang that puts the suffixes on overloaded functions - at least that's what the parameter says (see D77598 and printTemplateArguments "TemplOverloaded" parameter) - but I think maybe it's for anything that /can/ be overloaded, not necessarily only the things that are overloaded (the argument value is hardcoded at the various callsites, doesn't seem to depend on overload resolution/searching for overloaded functions). So maybe with "auto" modeled more accurately, and differentiating between function templates (always using type suffixes there) and class/variable templates (only using the suffix for "auto" types) we could correctly use integer type suffixes only in the minimal set of cases.
But that seems all too much fuss, so let's just put integer type suffixes everywhere always in the debug info of integer non-type template parameters in template names.
(more context: * https://reviews.llvm.org/D77598#inline-1057607 * https://groups.google.com/g/llvm-dev/c/ekLMllbLIZg/m/-dhJ0hO1AAAJ )
Differential Revision: https://reviews.llvm.org/D111477
show more ...
|
| #
aee49255 |
| 14-Oct-2021 |
David Blaikie <[email protected]> |
Recommit: Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing Ha
Recommit: Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned).
This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c
Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
show more ...
|
| #
f9ad1d1c |
| 14-Oct-2021 |
David Blaikie <[email protected]> |
Revert "Compress formatting of array type names (int [4] -> int[4])"
Looks like lldb has some issues with this - somehow it causes lldb to treat a "char[N]" type as an array of chars (prints them ou
Revert "Compress formatting of array type names (int [4] -> int[4])"
Looks like lldb has some issues with this - somehow it causes lldb to treat a "char[N]" type as an array of chars (prints them out individually) but a "char [N]" is printed as a string. (even though the DWARF doesn't have this string in it - it's something to do with the string lldb generates for itself using clang)
This reverts commit 277623f4d5a672d707390e2c3eaf30a9eb4b075c.
show more ...
|
| #
277623f4 |
| 14-Oct-2021 |
David Blaikie <[email protected]> |
Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing HasEmptyPlac
Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith.
Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned).
show more ...
|
| #
39093279 |
| 12-Oct-2021 |
David Blaikie <[email protected]> |
Improve printing of const variable sized arrays
Follow-on from 40acc0adad59ac39e9a7a02fcd93161298500c00 with help from Richard Smith on how to provoke this particular case.
|
| #
c5fb1a09 |
| 11-Oct-2021 |
Yonghong Song <[email protected]> |
Revert "[Clang] Ignore BTFTag attr if used as a type attribute"
This reverts commit b875343873a584965daf507d73ff1fe71eab1953.
Per discussion in https://reviews.llvm.org/D111199, instead to make exi
Revert "[Clang] Ignore BTFTag attr if used as a type attribute"
This reverts commit b875343873a584965daf507d73ff1fe71eab1953.
Per discussion in https://reviews.llvm.org/D111199, instead to make existing btf_tag attribute as a type-or-decl attribute, we will make existing btf_tag attribute as a decl only attribute, and introduce btf_type_tag as a type only attribute. This will make it easy for cases like typedef where an attribute may be applied as either a type attribute or a decl attribute.
show more ...
|
| #
b8753438 |
| 20-Sep-2021 |
Yonghong Song <[email protected]> |
[Clang] Ignore BTFTag attr if used as a type attribute
Currently, linux kernel has a __user attribute ([1]) defined as __attribute__((noderef, address_space(__user))) which is used by sparse tool
[Clang] Ignore BTFTag attr if used as a type attribute
Currently, linux kernel has a __user attribute ([1]) defined as __attribute__((noderef, address_space(__user))) which is used by sparse tool ([2]) to do some type checking of pointers to user space memory. During normal compilation, __user will be defined to nothing so it won't have an impact on compilation.
The btf_tag attribute, which is motivated by carrying linux kernel annotations into dwarf/BTF, is introduced in [3]. We intended to define __user as __attribute__((btf_tag("user"))) so such information will be encoded in dwarf/BTF and can be used later by bpf verification or other tracing tools.
But linux kernel __user attribute is also used during type conversion which btf_tag doesn't support ([4]) since such type conversion is only used for compiler analysis and not encoded in dwarf/btf. Theoretically, it is possible for clang to understand these tags and do a sparse-like type checking work. But I would like to leave that to future work and for now suggest simply ignore these btf_tag attributes if they are used as type attributes.
[1] https://github.com/torvalds/linux/blob/master/include/linux/compiler_types.h#L10 [2] https://sparse.docs.kernel.org/en/latest/ [3] https://reviews.llvm.org/D106614 [4] https://github.com/torvalds/linux/blob/master/fs/binfmt_flat.c#L135
Differential Revision: https://reviews.llvm.org/D110116
show more ...
|
| #
2ff049b1 |
| 20-Sep-2021 |
David Blaikie <[email protected]> |
DebugInfo: Don't use preferred template names in debug info
Using the preferred name creates a mismatch between the textual name of a type and the DWARF tags describing the parameters as well as pos
DebugInfo: Don't use preferred template names in debug info
Using the preferred name creates a mismatch between the textual name of a type and the DWARF tags describing the parameters as well as possible inconsistency between DWARF producers (like Clang and GCC, or older/newer Clang versions, etc).
show more ...
|
| #
40acc0ad |
| 15-Sep-2021 |
David Blaikie <[email protected]> |
Improve type printing of size-dependent const arrays to normalize array-of-const and const-array
Follow-on from 2bd84938470bf2e337801faafb8a67710f46429d based on postcommit feedback from Richard Smi
Improve type printing of size-dependent const arrays to normalize array-of-const and const-array
Follow-on from 2bd84938470bf2e337801faafb8a67710f46429d based on postcommit feedback from Richard Smith.
The VariableArray case I couldn't figure out how to test/provoke - you can't write/form a variable array in any context other than a local variable that I know of, and in that case `const int x[n]` is the normalized form already (array-of-const) and you can't use typedefs (since you can't typedef int[n] with variable 'n') to force the const-array AST that would produce the undesirable type printing "int const [n]".
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc3 |
|
| #
2bd84938 |
| 14-Sep-2021 |
David Blaikie <[email protected]> |
Improve type printing of const arrays to normalize array-of-const and const-array
Since these map to the same effective type - render them the same/in the more legible way (const x[n]).
|