Summary:
https://bugs.llvm.org/show_bug.cgi?id=46383
When the c preprocessor stringizes tokens, the generated string literals
are affected by the whitespace. This means clang-format can affect
codegen silently, adding spaces and newlines to strings. Practically
speaking, the vast majority of cases will be harmless, only affecting
single identifiers or debug macros.
In the interest of doing no harm in other cases though, this introduces
a blacklist option 'WhitespaceSensitiveMacros', which contains a list of
names of function-like macros whose contents should not be touched by
clang-format, period. Clang-format can't automatically detect these
without a real compile context, so users will have to specify it
explicitly (it still beats clang-format off'ing at every invocation).
Defaults include "STRINGIZE", "PP_STRINGIZE", and "BOOST_PP_STRINGIZE".
Subscribers: kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82620
Currently on http://clang.llvm.org/docs/ClangFormattedStatus.html there are format stats on files no actually inside the tree but generated by build scripts. These are usually copied from somewhere else. Right now for example there are files from `llvm/utils/release/llvm-package...`. Adding these files bloats the list while not giving an accurate representation of how formatted the repo is.
This addresses this issue by checking the git index and ignoring any folder that doesn't contain tracked files.
I'm still unsure whether it would be better to just do away with the `os.walk` method and just check over every file returned from `git ls-index <project-root>`.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D82707
This fixes a unit test. Otherwise here is the original commit:
1) Shared writable directories like /tmp are a security problem.
2) Systems provide dedicated cache directories these days anyway.
3) This also refines LLVM's cache_directory() on Darwin platforms to use
the Darwin per-user cache directory.
Reviewers: compnerd, aprantl, jakehehrlich, espindola, respindola, ilya-biryukov, pcc, sammccall
Reviewed By: compnerd, sammccall
Subscribers: hiraditya, llvm-commits, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D82362
This is to correct bugs.llvm.org/show_bug.cgi?id=46444
ffinite-math-only is a gcc option. That is the correct spelling.
File modified is clang/docs/UsersManual.rst
1) Shared writable directories like /tmp are a security problem.
2) Systems provide dedicated cache directories these days anyway.
3) This also refines LLVM's cache_directory() on Darwin platforms to use
the Darwin per-user cache directory.
Reviewers: compnerd, aprantl, jakehehrlich, espindola, respindola, ilya-biryukov, pcc, sammccall
Reviewed By: compnerd, sammccall
Subscribers: hiraditya, llvm-commits, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D82362
Keep deprecated -fsanitize-coverage-{white,black}list as aliases for compatibility for now.
Reviewed By: echristo
Differential Revision: https://reviews.llvm.org/D82244
This commit updates the 'CLion Integration' section in ClangFormat docs.
Key changes:
- clang-format is enabled automatically when there is a config file;
- formatting now works for indentations;
- if clang-format is enabled without a config file, CLion suggests creating it based on the IDE settings or uses the LLVM style by default.
Patch by Marina Kalashina!
Reviewers: sylvestre.ledru, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ilya-biryukov, klimek, MyDeveloperDay, sammccall, gribozavr2
Differential Revision: https://reviews.llvm.org/D80721
Summary:
This patch upstreams support for a new storage only bfloat16 C type.
This type is used to implement primitive support for bfloat16 data, in
line with the Bfloat16 extension of the Armv8.6-a architecture, as
detailed here:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
The bfloat type, and its properties are specified in the Arm Architecture
Reference Manual:
https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
In detail this patch:
- introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type.
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
The following people contributed to this patch:
- Luke Cheeseman
- Momchil Velikov
- Alexandros Lamprineas
- Luke Geeson
- Simon Tatham
- Ties Stuij
Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli
Reviewed By: SjoerdMeijer
Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76077
Extension vectors now can be used in element-wise conditional selector.
For example:
```
R[i] = C[i]? A[i] : B[i]
```
This feature was previously only enabled in OpenCL C. Now it's also
available in C. Not that it has different behaviors than GNU vectors
(i.e. __vector_size__). Extension vectors selects on signdness of the
vector. GNU vectors on the other hand do normal bool conversions. Also,
this feature is not available in C++.
Differential Revision: https://reviews.llvm.org/D80574
This patch adds clang options:
-fbasic-block-sections={all,<filename>,labels,none} and
-funique-basic-block-section-names.
LLVM Support for basic block sections is already enabled.
+ -fbasic-block-sections={all, <file>, labels, none} : Enables/Disables basic
block sections for all or a subset of basic blocks. "labels" only enables
basic block symbols.
+ -funique-basic-block-section-names: Enables unique section names for
basic block sections, disabled by default.
Differential Revision: https://reviews.llvm.org/D68049
Summary:
Any change to clang-format is tested with the unit tests, However sometimes the better approach is to run it over a very large fully formatted source tree and then inspect the differences. This seems to be a source of many of the regressions found by @krasimir and by @sylvestre.ledru and @Abpostelnicu who run it over the Mozilla sources, but often these regressions are only found after changes have been committed.
LLVM itself would be a good dog-fooding candidate for similar tests except such a large proportion of the tree is not 100% clang formatted, as such you are never aware if the change comes from a change to clang-format or just because the tree has not been formatted first.
The following review is for a small python tool which scans the whole of the LLVM source tree and counts the number of files which have one or more clang-format violations.
This revision contains the tool and the output from the initial run of the tool and the generated documentation which looks like the following
Reviewers: krasimir, JakeMerdichAMD, sammccall, curdeius, bollu, alexshap, jdoerfert, DavidTruby, sscalpone
Reviewed By: curdeius
Subscribers: dschuff, aheejin, fedor.sergeev, ilya-biryukov, simoncook, cryptoad, arphaman, jfb, kadircet, mstorsjo, s.egerton, usaxena95, aartbik, phosek, sstefan1, cfe-commits, sylvestre.ledru, Abpostelnicu, krasimir
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80627
And bump its version number accordingly.
This is a patched recommit of 7c298c104b
Previous hash implementation was incorrectly passing an uint64_t, that got converted
to an uint8_t, to finalize the hash computation. This led to different functions
having the same hash if they only differ by the remaining statements, which is
incorrect.
Added a new test case that trivially tests that a small function change is
reflected in the hash value.
Not that as this patch fixes the hash computation, it would invalidate all hashes
computed before that patch applies, this is why we bumped the version number.
Update profile data hash entries due to hash function update, except for binary
version, in which case we keep the buggy behavior for backward compatibility.
Differential Revision: https://reviews.llvm.org/D79961
This makes many scenarios simpler by not requiring the user to write
ignoringImplicit() all the time, nor to account for non-visible
cxxConstructExpr() and cxxMemberCalExpr() nodes. This is also, in part,
inclusive of the equivalent of adding a use of ignoringParenImpCasts()
between all expr()-related matchers in an expression.
The pre-existing traverse(TK_AsIs, ...) matcher can be used to explcitly
match on implicit/invisible nodes. See
http://lists.llvm.org/pipermail/cfe-dev/2019-December/064143.html
for more
Reviewers: aaron.ballman
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72534
Fixed following trivial issues that caught by warnings by adding
indents.
clang/docs/ConstantInterpreter.rst:133: WARNING: Bullet list ends
without a blank line; unexpected unindent.
clang/docs/ConstantInterpreter.rst:136: WARNING: Bullet list ends
without a blank line; unexpected unindent.
clang/docs/ConstantInterpreter.rst:153: WARNING: Bullet list ends
without a blank line; unexpected unindent.
clang/docs/ConstantInterpreter.rst:195: WARNING: Bullet list ends
without a blank line; unexpected unindent.
clang/docs/ConstantInterpreter.rst:225: WARNING: Bullet list ends
without a blank line; unexpected unindent.
clang/docs/ConstantInterpreter.rst:370: WARNING: Bullet list ends
without a blank line; unexpected unindent.
clang/docs/ConstantInterpreter.rst:383: WARNING: Bullet list ends
without a blank line; unexpected unindent.
Summary:
The predefined styles that clang-format supports are listed in two
places, and neither is up-to-date. GNU style isn't mentioned at all!
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80309
Jake Merdich