Token annotator incorrectly annotates operator& as a reference type in
situations like Boost serialization archives:
https://www.boost.org/doc/libs/1_81_0/libs/serialization/doc/tutorial.html
Add annotation rules for standalone and chained operator& instances while
preserving behavior for reference declarations at class scope. Add tests to
validate annotation and formatting behavior.
Differential Revision: https://reviews.llvm.org/D141959
New option --dxv-path is added for dxc mode to set the installation path for dxv.
If cannot find dxv, a warning will be report.
dxv will be executed with command line dxv file_name -o file_name.
It will validate and sign the file and overwrite it.
Differential Revision: https://reviews.llvm.org/D141705
Currently, the interpretation of `swap` calls in the optional model assumes the
optional arguments are modeled (and therefore have valid storage locations and
values). This assumption is incorrect, for example, in the case of unmodeled
optional fields (which can be missing either value or location). This patch
relaxes these assumptions, to return rather than assert when either argument is
not modeled.
Differential Revision: https://reviews.llvm.org/D142710
The invariants around `ReferenceValues` are subtle (arguably, too much so). That
includes that we need to take care not to double wrap them -- in cases where we
wrap a loc in an `ReferenceValue` we need to be sure that the pointee isn't
already a `ReferenceValue`. `BindingDecl` introduces another situation in which
this can arise. Previously, the code did not properly handle `BindingDecl`,
resulting in double-wrapped values, which broke other invariants (at least, that
struct values have an `AggregateStorageLocation`).
This patch adjusts the interpretation of `DeclRefExpr` to take `BindingDecl`'s
peculiarities into account. It also fixes the two tests which should have caught
this issue but were themselves (subtly) buggy.
Differential Revision: https://reviews.llvm.org/D140897
ASTImporterLookupTable did not handle correctly friend declarations
where the friend type is an UsingType (type of a declaration that
comes from an using-declaration). The problem is fixed by handling
it in the same way as a friend with TypedefType.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D142607
With https://reviews.llvm.org/D141826 `TemplateArgument`s have an
additional field that indicates their defaulted-ness. This gets
used during debug-info generation and in the `clang::TypePrinter`.
This patch copies the field during the import process so consumers
of the ASTImporter can benefit from the other Clang components that
read the field.
**Testing**
* Added unit-test
* Checked that this fixes (in addition to a follow-up LLDB patch)
fix current test failures in LLDB
Differential Revision: https://reviews.llvm.org/D142713
**Summary**
This patch adds a `IsDefaulted` field to `clang::TemplateArgument`.
To prevent memory footprint increase we still 1 bit from `ArgKind`.
**Changes**
1. `getIsDefaulted`/`setIsDefaulted` to allow clients to communicate
an argument's defaulted-ness to the TypePrinter
2. The `TemplateArgument` properties description had to be changed
to make sure we correctly mark the defaulted-ness of arguments
that came from a deserialized AST (caught by the HLSL test-suite)
3. The `TemplateArgument` constructors now accept a `IsDefaulted`
parameter to simplify construction from the tablegen description.
Though if people don't want to clutter the constructors we can
instead call `setIsDefaulted` from tablegen
4. When `clang::Sema` checks the template arguments against template
parameters we now call `setIsDefaulted`. This makes sure that
whenever a specialization decl gets constructed, the defaulted-ness
of the associated `TemplateArgument`s has already been deduced.
This preserves the immutability of `TemplateArgumentList`s
**Background**
In LLDB we construct ASTs from debug-info and hand it to clang
to perform actions such as printing/formatting a typenames.
Some debug formats, specifically DWARF, may only encode information
about class template instantiations, losing the structure of the generic
class definition. However, the `clang::TypePrinter` needs a properly
constructed `ClassTemplateDecl` with generic default argument decls
to be able to deduce whether a `ClassTemplateSpecializationDecl` was
instantiatiated with `TemplateArgument`s that correspond to the
defaults. LLDB does know whether a particular template argument was
defaulted, but can't currently tell clang about it.
This patch allows LLDB to set the defaulted-ness of a `TemplateArgument`
and thus benefit more from `clang::TypePrinter`.
See discussion in https://reviews.llvm.org/D140423
**Testing**
* Added unit-test
* LLDB/clang/llvm test-suite passes
Differential Revision: https://reviews.llvm.org/D141826
This patch adds support for `TemplateArgument`s of kind
`TemplateArgument::Expression` to `clang::isSubstitutedDefaultArgument`.
We do so by evaluating both the `Pattern` and `Arg` expression to an
`APInt`, if we can, and comparing the results.
This will be useful in an upcoming change where
`clang::isSubstitutedDefaultArgument` gets called from `clang::Sema`
where the `TemplateArgument`s are instantiated as expressions (without
being evaluted to `APInt` beforehand).
**Testing**
- Added unit-tests
Differential Revision: https://reviews.llvm.org/D142632
There should not be any cases where the angle brackets of template
parameters are directly followed by a literal. It is more likely that a
comparison is taking place instead.
This patch makes the TokenAnnotator prefer to annotate < and > as
operators when directly followed by a literal. A similar check already
exists for literals directly *before* potential template args.
Fixes https://github.com/llvm/llvm-project/issues/60140
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D142139
Basically NFC: A TEST/TEST_F/etc that bails out early (usually because
setup failed or some other runtime condition wasn't met) generally
should use GTEST_SKIP() to report its status correctly, unless it
takes steps to report another status (e.g., FAIL()).
This change fixes the following warnings:
llvm/clang/unittests/StaticAnalyzer/RangeSetTest.cpp:727:55: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
727 | TYPED_TEST_SUITE(RangeSetCastToNoopTest, NoopCastTypes);
| ^
llvm/clang/unittests/StaticAnalyzer/RangeSetTest.cpp:728:65: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
728 | TYPED_TEST_SUITE(RangeSetCastToPromotionTest, PromotionCastTypes);
| ^
llvm/clang/unittests/StaticAnalyzer/RangeSetTest.cpp:729:67: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
729 | TYPED_TEST_SUITE(RangeSetCastToTruncationTest, TruncationCastTypes);
| ^
llvm/clang/unittests/StaticAnalyzer/RangeSetTest.cpp:730:67: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
730 | TYPED_TEST_SUITE(RangeSetCastToConversionTest, ConversionCastTypes);
| ^
llvm/clang/unittests/StaticAnalyzer/RangeSetTest.cpp:732:46: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
732 | PromotionConversionCastTypes);
| ^
llvm/clang/unittests/StaticAnalyzer/RangeSetTest.cpp:734:47: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
734 | TruncationConversionCastTypes);
| ^
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D142439
This patch fixes a subtle bug in how we create lvalues to reference-typed
fields. In the rare case that the field is umodeled because of the depth limit
on field modeling, the lvalue created can be malformed. This patch prevents that
and adds some related assertions to other code dealing with lvalues for
references.
Differential Revision: https://reviews.llvm.org/D142468
The LLVMTestingAnnotations library that is now used by unittests
is not installed as part of LLVM. In order to make it possible to build
unittests when performing the standalone build of clang, build
the library from LLVM sources locally. This mirrors the existing logic
for LLVMTestingSupport.
Differential Revision: https://reviews.llvm.org/D142449
This callback was removed with commit 7a124f4859, but we use it
downstream in ROOT/Cling to implement handling of a special include
syntax. Add back a "safe" version of the callback that only takes
the file name and return a bool to silently skip the file.
Differential Revision: https://reviews.llvm.org/D142196
In unit tests for concrete dataflow analyses we typically use the
testonly `checkDataflow()` helper to analyse a free function called
"target". This pattern allows our tests to be uniform and focused on
specific statement- or expression-level C++ features.
As we expand our feature coverage, we want to analyze functions whose
names we don't fully control, like constructors, destructors, operators
etc. In such tests it is often convenient to analyze all functions
defined in the input code, to avoid having to carefully craft an AST
matcher that finds the exact function we're interested in. That can be
easily done by providing `checkDataflow()` with a catch-all matcher like
`functionDecl()`.
It is also often convenient to define multiple special member functions
in a single unit test, for example, multiple constructors, and share the
rest of the class definition code between constructors. As a result, it
makes sense to analyze multiple functions in one unit test.
This change allows `checkDataflow()` to correctly handle AST matchers
that match more than one function. Previously, it would only ever
analyze the first matched function, and silently ignore the rest. Now it
runs dataflow analysis in a loop, and calls `VerifyResults` for each
function that was found in the input and analyzed.
Reviewed By: ymandel, sgatev
Differential Revision: https://reviews.llvm.org/D140859
Currently, the code assumes that all boolean-typed values are an instance of
`BoolValue` (or its subclasses). Yet, lvalues violate this assumption. This
patch drops the assumption and strengthens the check to confirm the shape of
both values being joined.
The patch also notes as FIXMES a number of problems discovered fixing this bug.
Differential Revision: https://reviews.llvm.org/D141709
Some `TypeLoc`s are considered "sugar" and we go past them in
`GetTypeSourceInfoForDeclarator`. The problem is that we peel off only
the same kind of `TypeLoc` at the time which makes it impossible to
handle mixed sequences like
`AttributedTypeLoc - MacroQualifiedTypeLoc - AttributedTypeLoc - PointerTypeLoc`
In this situation, as shown in the added test, we don't get to
`PointerTypeLoc` and don't set its starLoc leaving it uninitialized.
Address FIXME and peel off "sugar" `TypeLoc`s regardless of their order.
rdar://102149264
Differential Revision: https://reviews.llvm.org/D141424
With the addition of `getFileRange`, we rename `getRangeForEdit` as
`getFileRangeForEdit` for consistency in the API.
Depends on D141634
Differential Revision: https://reviews.llvm.org/D141636
The Annotations helper class does not have a gtest or gmock dependency, but because it's bundled with the rest of TestingSupport, it gets one. By splitting it out, a target can use it without being forced to use LLVM's copy of gtest.
Reviewed By: GMNGeoffrey, sammccall, gribozavr2
Differential Revision: https://reviews.llvm.org/D141175
This patch includes two related changes:
1. Rewrite `compare` operation to be sound. Current version checks for equality
of `isNonEmptyOptional` on both values, judging the values `Same` when the
results are equal. While that works when both are true, it is problematic when
they are both false, because there are four cases in which that's can occur:
both empty, one empty and one unknown (which is two cases), and both unknown. In
the latter three cases, it is unsound to judge them `Same`. This patch changes
`compare` to explicitly check for case of `both empty` and then judge any other
case `Different`.
2. With the change to `compare`, a number of common cases will no longer
terminate. So, we also implement widening to properly handle those cases and
recover termination.
Drive-by: improve performance of `merge` operation.
Of the new tests, the code before the patch fails
* ReassignValueInLoopToSetUnsafe, and
* ReassignValueInLoopToUnknownUnsafe.
Differential Revision: https://reviews.llvm.org/D140344
This reverts commit 879bfe6a979295f834b76df66b19a203b93eed0f.
owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.
This patch properly recognizes the generic selection expression
introduced in C11, by adding an additional token type for the colons
present in such expressions.
Previously, they would be recognized as
"inline ASM colons" purely by the fact that those are the last thing
checked for.
I tried to avoid adding an addition token type, but since colons by
default like having spaces around them, I chose to add a new type so
that no space is added after the type selector.
Currently, no aspect of the formatting of these expressions in able to
be configured, as I'm not sure what could even be configured here.
One notable thing is that association list is always formatted as
either entirely on one line, if it can fit, or with line breaks
after every comma in the expression (also after the controlling expr.)
This visually makes them more similar to switch statements when long,
matching the behaviour of the selection expression, being that of a sort
of switch on types, but also allows for terseness when only selecting
for a few things.
Fixes https://github.com/llvm/llvm-project/issues/18080
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D139211
D119599 added the ability to align compound assignments, right aligning
them in order to line up at the equals sign.
However, that patch didn't account for AlignTokens being called
recursively across scopes, which reset the right justification to be
false in any scope besides the top scope. This meant the compound
assignments were aligned, just not at the right place.
(No tests also ever introduced any scopes)
This patch makes sure to inherit the right justification value, just as
every other parameter is passed on.
Fixes https://github.com/llvm/llvm-project/issues/58029
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D141288
There were two (small) bugs causing crashes in the analysis. This patch fixes both of them.
1. An enum value was accessed as a class member. Now, the engine gracefully
ignores such member expressions.
2. Field access in `MemberExpr` of struct/class-typed global variables. Analysis
didn't interpret fields of global vars, because the vars were initialized before
the fields were added to the "allowlist". Now, the allowlist is set _before_
init of globals.
Differential Revision: https://reviews.llvm.org/D141384
Merges `TransferOptions` into the newly-introduced
`DataflowAnalysisContext::Options` and removes explicit parameter for
`TransferOptions`, relying instead on the common options carried by the analysis
context. Given that there was no intent to allow different options between calls
to `transfer`, a common value for the options is preferable.
Differential Revision: https://reviews.llvm.org/D140703
This reverts commit a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f.
It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.
This reverts commit 2b1a517a92bfdfa3b692a660e19a2bb22513a567. It's a fix forward
with two memory errors fixed, one of which was the cause of the build breakage
in the buildbots.
Original message:
Previously, the model for structs modeled all fields in a struct when
`createValue` was called for that type. This patch adds a prepass on the
function under analysis to discover the fields referenced in the scope and then
limits modeling to only those fields. This reduces wasted memory usage
(modeling unused fields) which can be important for programs that use large
structs.
Note: This patch obviates the need for https://reviews.llvm.org/D123032.
