13 Commits

Author SHA1 Message Date
YexuanXiao
7c402b8b81
Reland [Clang] Make the SizeType, SignedSizeType and PtrdiffType be named sugar types (#149613)
The checks for the 'z' and 't' format specifiers added in the original
PR #143653 had some issues and were overly strict, causing some build
failures and were consequently reverted at
4c85bf2fe8.

In the latest commit
27c58629ec,
I relaxed the checks for the 'z' and 't' format specifiers, so warnings
are now only issued when they are used with mismatched types.

The original intent of these checks was to diagnose code that assumes
the underlying type of `size_t` is `unsigned` or `unsigned long`, for
example:

```c
printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long
```  

However, it produced a significant number of false positives. This was
partly because Clang does not treat the `typedef` `size_t` and
`__size_t` as having a common "sugar" type, and partly because a large
amount of existing code either assumes `unsigned` (or `unsigned long`)
is `size_t`, or they define the equivalent of size_t in their own way
(such as
sanitizer_internal_defs.h).2e67dcfdcd/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h (L203)
2025-07-19 03:44:14 -03:00
Kazu Hirata
4c85bf2fe8 Revert "[Clang] Make the SizeType, SignedSizeType and PtrdiffType be named sugar types instead of built-in types (#143653)"
This reverts commit c27e283cfbca2bd22f34592430e98ee76ed60ad8.

A builbot failure has been reported:
https://lab.llvm.org/buildbot/#/builders/186/builds/10819/steps/10/logs/stdio

I'm also getting a large number of warnings related to %zu and %zx.
2025-07-17 21:04:01 -07:00
YexuanXiao
c27e283cfb
[Clang] Make the SizeType, SignedSizeType and PtrdiffType be named sugar types instead of built-in types (#143653)
Including the results of `sizeof`, `sizeof...`, `__datasizeof`,
`__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and
signed `size_t` literals, the results of pointer-pointer subtraction and
checks for standard library functions (and their calls).

The goal is to enable clang and downstream tools such as clangd and
clang-tidy to provide more portable hints and diagnostics.

The previous discussion can be found at #136542.

This PR implements this feature by introducing a new subtype of `Type`
called `PredefinedSugarType`, which was considered appropriate in
discussions. I tried to keep `PredefinedSugarType` simple enough yet not
limited to `size_t` and `ptrdiff_t` so that it can be used for other
purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a
name, conceptually similar to a compiler internal `TypedefType` but
without depending on a `TypedefDecl` or a source file.

Additionally, checks for the `z` and `t` format specifiers in format
strings for `scanf` and `printf` were added. It will precisely match
expressions using `typedef`s or built-in expressions.

The affected tests indicates that it works very well.

Several code require that `SizeType` is canonical, so I kept `SizeType`
to its canonical form.

The failed tests in CI are allowed to fail. See the
[comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611)
in another PR #135386.
2025-07-17 22:45:57 -03:00
Matheus Izvekov
10a1502421
[clang] AST: remove source locations from [Variable/Dependent]SizedArrayType (#135511) 2025-04-14 10:44:25 -03:00
Sam McCall
09f8315bba [Sema] a[x] has type T when a has type T* or T[], even when T is dependent
This more precise type is useful for tools, e.g.
fixes https://github.com/clangd/clangd/issues/831

Differential Revision: https://reviews.llvm.org/D107275
2021-12-31 01:30:39 +01:00
David Blaikie
aee4925507 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).
2021-10-21 11:34:43 -07:00
David Blaikie
f9ad1d1c77 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.
2021-10-14 14:49:25 -07:00
David Blaikie
277623f4d5 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).
2021-10-14 14:23:32 -07:00
David Blaikie
40acc0adad 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]".
2021-09-15 13:46:37 -07:00
Bruno Ricci
ecbf2f5f3d
[clang][test][NFC] Also test for serialization in AST dump tests, part 2/n.
The outputs between the direct ast-dump test and the ast-dump test after
deserialization should match modulo a few differences.

For hand-written tests, strip the "<undeserialized declarations>"s and
the "imported"s with sed.

For tests generated with "make-ast-dump-check.sh", regenerate the
output.

Part 2/n.
2020-06-21 13:59:11 +01:00
Stephen Kelly
0fa7bf099d Extend test for DependentSizedArrayType
Use a using declaration to force the type to appear in the -ast-dump
output.

llvm-svn: 348241
2018-12-04 09:53:36 +00:00
Stephen Kelly
e8e4f09add Fix whitespace
llvm-svn: 348094
2018-12-02 16:42:34 +00:00
Stephen Kelly
765e1a4472 Add dump tests for ArrayInitLoopExpr and ArrayInitIndexExpr
llvm-svn: 348093
2018-12-02 16:36:23 +00:00