History log of /llvm-project-15.0.7/clang/lib/AST/TypePrinter.cpp (Results 1 – 25 of 295)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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]).


12345678910>>...12