Commit Graph

20 Commits

Author SHA1 Message Date
Balazs Benics 170c67d5b8 [analyzer] Use the MacroExpansionContext for macro expansions in plists
Removes the obsolete ad-hoc macro expansions during bugreport constructions.
It will skip the macro expansion if the expansion happened in an imported TU.

Also removes the expected plist file, while expanding matching context for
the tests.
Adds a previously crashing `plist-macros-with-expansion.c` testfile.
Temporarily marks `plist-macros-with-expansion-ctu.c ` to `XFAIL`.

Reviewed By: xazax.hun, Szelethus

Differential Revision: https://reviews.llvm.org/D93224
2021-02-22 11:12:18 +01:00
Chris Hamilton 2697d138a6 [Analyzer] GNU named variadic macros in Plister
Added support for GNU named variadic macros in
macro expansion for plist generation.

Fix for https://bugs.llvm.org/show_bug.cgi?id=44493

Reviewed By: Szelethus

Differential Revision: https://reviews.llvm.org/D87942
2020-09-21 15:38:28 -05:00
Kristóf Umann be0d79f329 [analyzer][MacroExpansion] Fix a crash where multiple parameters resolved to __VA_ARGS__
In short, macro expansions handled the case where a variadic parameter mapped to
multiple arguments, but not the other way around. An internal ticket was
submitted that demonstrated that we fail an assertion. Macro expansion so far
worked by lexing the source code token-by-token and using the Preprocessor to
turn these tokens into identifiers or just get their proper spelling, but what
this counter intuitively doesn't do, is actually expand these macros, so we have
to do the heavy lifting -- in this case, figure out what __VA_ARGS__ expands
into. Since this case can only occur in a nested macro, the information we
gathered from the containing macro does contain this information. If a parameter
resolves to __VA_ARGS__, we need to temporarily stop getting our tokens from the
lexer, and get the tokens from what __VA_ARGS__ maps to.

Differential Revision: https://reviews.llvm.org/D86135
2020-09-11 14:07:58 +02:00
Kirstóf Umann 7527898fef [analyzer][MacroExpansion][NFC] Fix a missing test output check 2020-09-11 13:48:26 +02:00
Artem Dergachev b0914e7276 [analyzer] Specify the C++ standard in more tests.
Makes life easier for downstream developers with different default standard.

llvm-svn: 375308
2019-10-19 00:08:17 +00:00
Hubert Tong 61c848d254 Reapply r362994 & co "[analyzer][tests] Add normalize_plist to replace diff_plist"
Following r363007, which reverted r362998, r362996, and r362994,
reapply with adjustments for the CRLF differences encountered with
Windows. Namely, the `-b` option of `diff` is employed, and the `grep`
patterns have `$` replaced with `[[:space:]]*$`.

llvm-svn: 363069
2019-06-11 14:21:32 +00:00
Reid Kleckner e7ea1834f4 Revert r362994 & co "[analyzer][tests] Add normalize_plist to replace diff_plist"
Reverts r362998, r362996, and r362994 because the tests do not pass on
Windows due to CRLF changes. Adding back `-w` to diff is not enough, the
new grep substitution doesn't work on Windows, and fixing it is
non-trivial.

llvm-svn: 363007
2019-06-10 23:25:43 +00:00
Hubert Tong 65db5d4cb5 [analyzer][tests] Use normalize_plist in place of diff_plist (`cat` cases)
Summary:
The `%diff_plist` lit substitution invokes `diff` with a non-portable
`-I` option. The intended effect can be achieved by normalizing the
inputs to `diff` beforehand. Such normalization can be done with
`grep -Ev`, which is also used by other tests.

This patch applies the change (adjusted for review comments) described
in http://lists.llvm.org/pipermail/cfe-dev/2019-April/061904.html
mechanically to the cases where the output file is piped to
`%diff_plist` via `cat`.

The changes were applied via a script, except that
`clang/test/Analysis/NewDelete-path-notes.cpp` and
`clang/test/Analysis/plist-macros-with-expansion.cpp` were each adjusted
for the line-continuation on the relevant `RUN` step.

Reviewers: NoQ, sfertile, xingxue, jasonliu, daltenty

Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, jsji, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D62950

llvm-svn: 362996
2019-06-10 22:37:31 +00:00
Kristof Umann 7b907bed3c [analyzer] Fix function macro crash
Re-commit D57893.

Differential Revision: https://reviews.llvm.org/D57893

llvm-svn: 356142
2019-03-14 13:38:16 +00:00
Kristof Umann e58dde2a80 Revert "[analyzer] Fix function macro crash"
Buildbot breaks when LLVm is compiled with memory sanitizer.

WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0xa3d16d8 in getMacroNameAndPrintExpansion(blahblah)
                             lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:903:11
llvm-svn: 355911
2019-03-12 11:22:30 +00:00
Kristof Umann 9f92b3d081 [analyzer] Fix function macro crash
When there is a functor-like macro which is passed as parameter to another
"function" macro then its parameters are not listed at the place of expansion:

#define foo(x) int bar() { return x; }
#define hello(fvar) fvar(0)
hello(foo)
int main() { 1 / bar(); }

Expansion of hello(foo) asserted Clang, because it expected an l_paren token in
the 3rd line after "foo", since it is a function-like token.

Patch by Tibor Brunner!

Differential Revision: https://reviews.llvm.org/D57893

llvm-svn: 355903
2019-03-12 10:03:32 +00:00
Kristof Umann b4cdfe8e7f [analyzer] Fix infinite recursion in printing macros
In the commited testfile, macro expansion (the one implemented for the plist
output) runs into an infinite recursion. The issue originates from the algorithm
being faulty, as in

#define value REC_MACRO_FUNC(value)

the "value" is being (or at least attempted) expanded from the same macro.

The solved this issue by gathering already visited macros in a set, which does
resolve the crash, but will result in an incorrect macro expansion, that would
preferably be fixed down the line.

Patch by Tibor Brunner!

Differential Revision: https://reviews.llvm.org/D57891

llvm-svn: 355705
2019-03-08 16:26:29 +00:00
George Karpenkov 363dd8e4b8 [analyzer] [NFC] Reverse the argument order for "diff" in tests
The current argument order has "expected" and "actual" the wrong way around,
so that the diff shows the change from expected to actual, not from actual to expected.

Namely, if the expected diagnostics contains the string "foo", but the analyzer emits "bar",
we really want to see:

```
- foo
+ bar
```

not

```
- bar
+ foo
```

since adapting to most changes would require applying that diff to the expected output.

Differential Revision: https://reviews.llvm.org/D56340

llvm-svn: 350866
2019-01-10 18:15:44 +00:00
Kristof Umann 5f9981f8a5 [analyzer][PlistMacroExpansion] Part 5.: Support for # and ##
From what I can see, this should be the last patch needed to replicate macro
argument expansions.

Differential Revision: https://reviews.llvm.org/D52988

llvm-svn: 348025
2018-11-30 19:21:35 +00:00
Kristof Umann 8de6062010 [analyzer][PlistMacroExpansion] Part 4.: Support for __VA_ARGS__
Differential Revision: https://reviews.llvm.org/D52986

llvm-svn: 347888
2018-11-29 17:09:41 +00:00
Kristof Umann 08d92e4a10 [analyzer][PlistMacroExpansion] Part 3.: Macro arguments are expanded
This part focuses on expanding macro arguments.

Differential Revision: https://reviews.llvm.org/D52795

llvm-svn: 347629
2018-11-27 02:28:23 +00:00
Kristof Umann 3800257fba Reland '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion'
llvm-svn: 346111
2018-11-05 02:14:36 +00:00
Kristof Umann d96bdd2402 Revert '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion'
llvm-svn: 346096
2018-11-04 14:18:37 +00:00
Kristof Umann 7430213d8e [analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion
This patch adds a couple new functions to acquire the macro's name, and also
expands it, although it doesn't expand the arguments, as seen from the test files

Differential Revision: https://reviews.llvm.org/D52794

llvm-svn: 346095
2018-11-04 13:59:44 +00:00
Kristof Umann 7d6d9eb688 [analyzer][PlistMacroExpansion] Part 1.: New expand-macros flag
This is the first part of the implementation of the inclusion of macro
expansions into the plist output. It adds a new flag that adds a new
"macro_expansions" entry to each report that has PathDiagnosticPieces that were
expanded from a macro. While there's an entry for each macro expansion, both
the name of the macro and what it expands to is missing, and will be implemented
in followup patches.

Differential Revision: https://reviews.llvm.org/D52742

llvm-svn: 345724
2018-10-31 14:54:27 +00:00