The combination of
- AlignConsecutiveAssignments.Enabled = true
- BinPackArguments = false
would result in the first continuation line of a braced-init-list being
improperly indented (missing a shift) when in a continued function call.
Indentation was also wrong for braced-init-lists continuing a
direct-list-initialization. Check for opening braced lists in
continuation and ensure that the correct shift occurs.
Fixes https://github.com/llvm/llvm-project/issues/55360
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D125162
Fixes https://github.com/llvm/llvm-project/issues/55407.
Given configuration:
```
UseTab: Always
PointerAlignment: Right
AlignConsecutiveDeclarations: true
```
Before, the pointer was misaligned in this code:
```
void f() {
unsigned long long big;
char *ptr; // misaligned
int i;
}
```
That was due to the fact that when handling right-aligned pointers, the Spaces were changed but StartOfTokenColumn was not.
Also, a tab was used not only for indentation but for spacing too when using `UseTab: ForIndentation` config option:
```
void f() {
unsigned long long big;
char *ptr; // \t after char
int i;
}
```
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D125528
This patch is the result of running clang-format version 753fe33 in
clang/unittests/Format/:
clang-format -style="{InsertBraces: true, RemoveBracesLLVM: true}" -i *.cpp *.h
Differential Revision: https://reviews.llvm.org/D125510
Fixes the `FIXME:` related to adding `forEachTemplateArgument` to the
core AST Matchers library.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D125383
If a closing brace is followed by a non-trailing comment, the
newline before the closing brace must also be removed.
Differential Revision: https://reviews.llvm.org/D125451
Reimplement the RemoveBracesLLVM feature which handles a
single-statement block that would get wrapped.
Fixes#53543.
Differential Revision: https://reviews.llvm.org/D125137
Due to how parseBracedList always stopped on the first closing angle
bracket and was used in parsing angle bracketed expression inside concept
definition, nested brackets inside concepts were parsed incorrectly.
nextToken() call before calling parseBracedList is required because
we were processing opening angle bracket inside parseBracedList second
time leading to incorrect logic after my fix.
Fixes https://github.com/llvm/llvm-project/issues/54943
Fixes https://github.com/llvm/llvm-project/issues/54837
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D123896
This is generally a better default for tools other than the compiler, which
shouldn't assume a PCH file on disk is something they can consume.
Preserve the old behavior in places associated with libclang/c-index-test
(including ASTUnit) as there are tests relying on it and most important
consumers are out-of-tree. It's unclear whether the tests are specifically
trying to test this functionality, and what the downstream implications of
removing it are. Hopefully someone more familiar can clean this up in future.
Differential Revision: https://reviews.llvm.org/D125149
Fixes https://github.com/llvm/llvm-project/issues/54522.
This fixes regression introduced in 5e5efd8a91.
Before the culprit commit, macros in WhitespaceSensitiveMacros were correctly formatted even if their closing parenthesis weren't followed by semicolon (or, to be precise, when they were followed by a newline).
That commit changed the type of the macro token type from TT_UntouchableMacroFunc to TT_FunctionLikeOrFreestandingMacro.
Correct formatting (with `WhitespaceSensitiveMacros = ['FOO']`):
```
FOO(1+2)
FOO(1+2);
```
Regressed formatting:
```
FOO(1 + 2)
FOO(1+2);
```
Reviewed By: HazardyKnusperkeks, owenpan, ksyx
Differential Revision: https://reviews.llvm.org/D123676
The ShouldShiftBeAdded lambda checks if extra space should be
added before the wrapped part of a braced list. If the first
element of the list is wrapped, no extra space should be added.
Fixes#55161.
Differential Revision: https://reviews.llvm.org/D124956
If clang is passed "-include foo.h", it will rewrite to "-include-pch foo.h.pch"
before passing it to cc1, if foo.h.pch exists.
Existence is checked, but validity is not. This is probably a reasonable
assumption for the compiler itself, but not for clang-based tools where the
actual compiler may be a different version of clang, or even GCC.
In the end, we lose our -include, we gain a -include-pch that can't be used,
and the file often fails to parse.
I would like to turn this off for all non-clang invocations (i.e.
createInvocationFromCommandLine), but we have explicit tests of this behavior
for libclang and I can't work out the implications of changing it.
Instead this patch:
- makes it optional in the driver, default on (no change)
- makes it optional in createInvocationFromCommandLine, default on (no change)
- changes driver to do IO through the VFS so it can be tested
- tests the option
- turns the option off in clangd where the problem was reported
Subsequent patches should make libclang opt in explicitly and flip the default
for all other tools. It's probably also time to extract an options struct
for createInvocationFromCommandLine.
Fixes https://github.com/clangd/clangd/issues/856
Fixes https://github.com/clangd/vscode-clangd/issues/324
Differential Revision: https://reviews.llvm.org/D124970
It's accumulating way too many optional params (see D124970)
While here, improve the name and the documentation.
Differential Revision: https://reviews.llvm.org/D124971
tapi & clang-extractapi both attempt to construct then check against
how a header was included to determine api information when working
against multiple search paths, headermap, and vfsoverlay mechanisms.
Validating this against what the preprocessor sees during lookup time
makes this check more reliable.
Reviewed By: zixuw, jansvoboda11
Differential Revision: https://reviews.llvm.org/D124638
`IgnoreParenImpCasts` will remove implicit casts to bool
(e.g. `PointerToBoolean`), such that the resulting expression may not
be of the `bool` type. The `cast_or_null<BoolValue>` in
`extendFlowCondition` will then trigger an assert, as the pointer
expression will not have a `BoolValue`.
Instead, we only skip `ExprWithCleanups` and `ParenExpr` nodes, as the
CFG does not emit them.
Differential Revision: https://reviews.llvm.org/D124807
C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 without a deprecation period, so implementations continued to
support the feature. Now, as with implicit function declarations, is a
good time to reevaluate the need for this support.
This patch allows -Wimplicit-int to issue warnings in C89 mode (off by
default), defaults the warning to an error in C99 through C17, and
disables support for the feature entirely in C2x. It also removes a
warning about missing declaration specifiers that really was just an
implicit int warning in disguise and other minor related cleanups.
Before C++20, MSVC treated any friend function declaration as a function declaration, so the following code would compile despite funGlob being declared after its first call:
```
class Glob {
public:
friend void funGlob();
void test() {
funGlob();
}
};
void funGlob() {}
```
This proposed patch mimics the MSVC behavior when in MSVC compatibility mode
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D124613
Enable efficient implementation of context-aware joining of distinct
boolean values. It can be used to join distinct boolean values while
preserving flow condition information.
Flow conditions are represented as Token <=> Clause iff formulas. To
perform context-aware joining, one can simply add the tokens of flow
conditions to the formula when joining distinct boolean values, e.g:
`makeOr(makeAnd(FC1, Val1), makeAnd(FC2, Val2))`. This significantly
simplifies the implementation of `Environment::join`.
This patch removes the `DataflowAnalysisContext::getSolver` method.
The `DataflowAnalysisContext::flowConditionImplies` method should be
used instead.
Reviewed-by: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D124395
The DXIL validator version option(/validator-version) decide the validator version when compile hlsl.
The format is major.minor like 1.0.
In normal case, the value of validator version should be got from DXIL validator. Before we got DXIL validator ready for llvm/main, DXIL validator version option is added first to set validator version.
It will affect code generation for DXIL, so it is treated as a code gen option.
A new member std::string DxilValidatorVersion is added to clang::CodeGenOptions.
Then CGHLSLRuntime is added to clang::CodeGenModule.
It is used to translate clang::CodeGenOptions::DxilValidatorVersion into a ModuleFlag under key "dx.valver" at end of clang code generation.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D123884
Strutures of function pointers are a good surface area for attacks. We
should therefore randomize them unless explicitly told not to.
Reviewed By: aaron.ballman, MaskRay
Differential Revision: https://reviews.llvm.org/D123544
This is to improve maintenance a bit and remove need to maintain the additional option and related code-paths.
Differential Revision: https://reviews.llvm.org/D124558
A record may have more than just FieldDecls in it. If so, then we're
likely to drop them if we only randomize the FieldDecls.
We need to be careful about anonymous structs/unions. Their fields are
made available in the RecordDecl as IndirectFieldDecls, which are listed
after the anonymous struct/union. The ordering doesn't appear to be
super important, however we place them unrandomized at the end of the
RecordDecl just in case. There's also the possiblity of
StaticAssertDecls. We also want those at the end.
All other non-FieldDecls we place at the top, just in case we get
something like:
struct foo {
enum e { BORK };
enum e a;
};
Link: https://github.com/KSPP/linux/issues/185
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123958
- Do not traverse concept decl inside `AutoType`. We only traverse
declaration and definitions, not references to a declaration.
- Do not visit implicit AST node the relevant traversal mode.
- Add traversal extension points for concept requirements.
- Renamed `TraverseConceptReference` to mark as helper to share
the code. Having an extension point there seems confusing given that
there are many concept refences in the AST that do not call the
helper. Those are `AutoType`, `AutoTypeLoc` and constraint requirements.
Only clangd code requires an update.
There are no use-cases for concept requirement traversals yet, but
I added them in the earlier version of the patch and decided to keep
them for completeness.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D124532
This reverts commit d46fa023ca.
Regressed include order in some cases with trailing comments, see the
comments on https://reviews.llvm.org/D121370. Will add a regression test
in a follow-up commit.
If the underlying template name of a qualified template name is a using
decl, TemplateName::getAsUsingDecl() will return it.
This will make the UsingTemplateName consumer life easier.
Differential Revision: https://reviews.llvm.org/D124437
The current implementation mutates the environment as it performs the
join. However, that interferes with the call to the model's `merge` operation,
which can modify `MergedEnv`. Since any modifications are assumed to apply to
the post-join environment, providing the same environment for both is
incorrect. This mismatch is a particular concern for joining the flow
conditions, where modifications in the old environment may not be propagated to
the new one.
Differential Revision: https://reviews.llvm.org/D124104
There was some duplicate code in determineStarAmpUsage and
determinePlusMinusCaretUsage
Now a `-` or `+` following `;`, `sizeof`, `co_await`, or `delete` is
regarded as a unary operator.
Now a `*` or `&` following `case` is also a unary operator.
Reviewed By: curdeius, MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D121754
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.
This uses "llvm::shuffle" to stop differences in shuffle ordering on
different platforms.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124199
Tests that need ASTs have to deal with the awkward control flow of
FrontendAction in some way. There are a few idioms used:
- don't bother with unit tests, use clang -dump-ast
- create an ASTConsumer by hand, which is bulky
- use ASTMatchFinder - works pretty well if matchers are actually
needed, very strange if they are not
- use ASTUnit - this yields nice straight-line code, but ASTUnit is a
terrifically complicated library not designed for this purpose
TestAST provides a very simple way to write straight-line tests: specify
the code/flags and it provides an AST that is kept alive until the
object is destroyed.
It's loosely modeled after TestTU in clangd, which we've successfully
used for a variety of tests.
I've updated a couple of clang tests to use this helper, IMO they're clearer.
Differential Revision: https://reviews.llvm.org/D123668
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.
We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.
This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.
We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.
In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.
The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.
This is a re-commit of
fc30901096,
a571f82a50,
64c045e25b, and
de6ddaeef3,
and reverts aa643f455a.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123345
Revert "Fixup D123950 to address revert of D123345"
This reverts commit aa643f455a.
