There's no reason that arguments to e.g. lambda calls should be treated
differently than those to "real" functions.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D128329
- when printing a shared node for the second time, don't print its children
(This keeps output proportional to the size of the structure)
- when printing a shared node for the second time, print its type only, not rule
(for consistency with above: don't dump details of nodes twice)
- don't abbreviate shared nodes, to ensure we can prune the tree there
Differential Revision: https://reviews.llvm.org/D128805
Followup to D128352. This patch pulls the `NoopLattice` class out from the `NoopAnalysis.h` test file into its own `NoopLattice.h` source file, and uses it to replace usage of `SourceLocationsLattice` in `UncheckedOptionalAccessModel`.
Reviewed By: ymandel, sgatev, gribozavr2, xazax.hun
Differential Revision: https://reviews.llvm.org/D128356
Followup to D127898. This patch updates `bugprone-unchecked-optional-access` to use the new `diagnoseCFG` function instead of just looking at the exit block.
A followup to this will update the optional model itself to use a noop lattice rather than redundantly computing the diagnostics in both phases of the analysis.
Reviewed By: ymandel, sgatev, gribozavr2, xazax.hun
Differential Revision: https://reviews.llvm.org/D128352
Followup to D127898. This patch updates `bugprone-unchecked-optional-access` to use the new `diagnoseCFG` function instead of just looking at the exit block.
A followup to this will update the optional model itself to use a noop lattice rather than redundantly computing the diagnostics in both phases of the analysis.
Reviewed By: ymandel, sgatev, gribozavr2, xazax.hun
Differential Revision: https://reviews.llvm.org/D128352
"Ascii" StringLiteral instances are actually narrow strings
that are UTF-8 encoded and do not have an encoding prefix.
(UTF8 StringLiteral are also UTF-8 encoded strings, but with
the u8 prefix.
To avoid possible confusion both with actuall ASCII strings,
and with future works extending the set of literal encodings
supported by clang, this rename StringLiteral::isAscii() to
isOrdinary(), matching C++ standard terminology.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D128762
The idea is:
- a parse failure is detected when all heads die when trying to shift
the next token
- we can recover by choosing a nonterminal we're partway through parsing,
and determining where it ends through nonlocal means (e.g. matching brackets)
- we can find candidates by walking up the stack from the (ex-)heads
- the token range is defined using heuristics attached to grammar rules
- the unparsed region is represented in the forest by an Opaque node
This patch has the core GLR functionality.
It does not allow recovery heuristics to be attached as extensions to
the grammar, but rather infers a brace-based heuristic.
Expected followups:
- make recovery heuristics grammar extensions (depends on D127448)
- add recover to our grammar for bracketed constructs and sequence nodes
- change the structure of our augmented `_ := start` rules to eliminate
some special-cases in glrParse.
- (if I can work out how): avoid some spurious recovery cases described
in comments
- grammar changes to eliminate the hard distinction between init-list
and designated-init-list shown in the recovery-init-list.cpp testcase
Differential Revision: https://reviews.llvm.org/D128486
Treat captures as a uniform list, rather than default-captures being special
snowflakes that may only appear at the start.
This accepts a larger set of (incorrect) code, and simplifies error-handling
by making this fit into the usual homogeneous-list pattern.
Differential Revision: https://reviews.llvm.org/D128708
This isn't allowed by the standard grammar but is allowed in C, and clang/GCC
permit it as an extension.
It avoids the need to determine which type of list we have in error-recovery.
While here, also support array index designators `{ [4]=1 }` which are
also legal in C, and common extensions in C++.
Differential Revision: https://reviews.llvm.org/D128687
Previously, the action table stores a reduce action for each lookahead
token it should allow. These tokens are the followSet(action.rule.target).
In practice, the follow sets are large, so we spend a bunch of time binary
searching around all these essentially-duplicates to check whether our lookahead
token is there.
However the number of reduces for a given state is very small, so we're
much better off linear scanning over them and performing a fast check for each.
D128318 was an attempt at this, storing a bitmap for each reduce.
However it's even more compact just to use the follow sets directly, as
there are fewer nonterminals than (state, rule) pairs. It's also faster.
This specialized approach means unbundling Reduce from other actions in
LRTable, so it's no longer useful to support it in Action. I suspect
Action will soon go away, as we store each kind of action separately.
This improves glrParse speed by 42% (3.30 -> 4.69 MB/s).
It also reduces LR table size by 59% (343 -> 142kB).
Differential Revision: https://reviews.llvm.org/D128472
MSVC was issuing "illegal conversion; more than one user-defined
conversion has been implicitly applied" as a warning on this code.
Explicitly calling .str() causes a StringRef to be materialized so
that a second user-defined conversion is not required.
Check llvm::Optional before dereferencing it.
Compute VirtualEndLoc differently to avoid an assertion failure
in clang::SourceManager::getFileIDLoaded:
Assertion `0 && "Invalid SLocOffset or bad function choice"' failed
after the test-reorg commit (89a1d03e2b), the
cert/uppercase test starts to fail in our internal environment -- it accesses
a header file from "../readability", which is not friendly to a hermetic test environment.
This change makes the test fully hermetic, and does some cleanup on the
uppercase header (I think it is better to move it the share
Inputs/Header directory, and rename it)
Differential Revision: https://reviews.llvm.org/D128511
The current way to specify CheckOptions is pretty verbose and unintuitive.
Given that the options are a dictionary it makes much more sense to treat them as such in the config files.
Example:
```
CheckOptions: {SomeCheck.Option: true, SomeCheck.OtherOption: 'ignore'}
# Or
CheckOptions:
SomeCheck.Option: true
SomeCheck.OtherOption: 'ignore'
```
This change will still handle the old syntax with no issue, ensuring we don't screw up users current config files.
The only observable differences are support for the new syntax and `-dump=config` will emit using the new syntax.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D128337
Adds a `-verify-config` command line argument, that when specified will verify the Checks and CheckOptions fields in the config files:
- A warning will be raised for any check that doesn't correspond to a registered check, a suggestion will also be emitted for close misses.
- A warning will be raised for any check glob(containing *) that doesn't match any registered check.
- A warning will be raised for any CheckOption that isn't read by any registered check, a suggestion will also be emitted for close misses.
This can be useful if debuging why a certain check isn't enabled, or the options are being handled as you expect them to be.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D127446
We have to walk up to the last node to find the start token, but no need
to go even one node further.
This is one node fewer to store, but more importantly if the last node
happens to have multiple parents we avoid storing the sequence multiple times.
This saves ~5% on glrParse.
Based on a comment by hokein@ on https://reviews.llvm.org/D128307
Copying sequences around as the heap resized is significantly expensive.
This speeds up glrParse by ~35% (2.4 => 3.25 MB/s)
Differential Revision: https://reviews.llvm.org/D128307
This is a ~5% speedup, we no longer have to allocate the priority queues and
other collections for each reduction step where we use them.
It's also IMO easier to understand the structure of a class with methods vs a
function with nested lambdas.
Differential Revision: https://reviews.llvm.org/D128301
In general we split a reduce into pop/push, so concurrently-available reductions
can run in the correct order. The data structures for this are expensive.
When only one reduction is possible at a time, we need not do this: we can pop
and immediately push instead.
Strictly this is correct whenever we yield one concurrent PushSpec.
This patch recognizes a trivial but common subset of these cases:
- there must be no pending pushes and only one head available to pop
- the head must have only one reduction rule
- the reduction path must be a straight line (no multiple parents)
On my machine this speeds up by 2.12 -> 2.30 MB/s = 8%
Differential Revision: https://reviews.llvm.org/D128299
IMO this model is simpler to understand (borrowed from the LR0 patch D127357).
It also makes error recovery easier to implement, as we have a simple list of
head nodes lying around to recover from when needed.
(It's not quite as nice as LR0 in this respect though).
It's slightly slower (2.24 -> 2.12 MB/S on my machine = 5%) but nothing close
to as bad as LR0.
However
- I think we'd have to eat a litle performance loss otherwise to implement
error recovery.
- this frees up some complexity budget for optimizations like fastpath push/pop
(this + fastpath is already faster than head)
- I haven't changed the data structure here and it's now pretty dumb, we can
make it faster
Differential Revision: https://reviews.llvm.org/D128297
I expect to eliminate this ambiguity at the grammar level by use of guards,
because it interferes with brace-based error recvoery.
Differential Revision: https://reviews.llvm.org/D127400
Eliminate clutter by reorganizing the Lit test files for clang-tidy:
- Move checkers/<module>-* to checkers/<module>/*.
- Move module specific inputs from Inputs to <module>/Inputs. Remove
any module prefix from the file or subdirectory name as they are no
longer needed.
- Introduce a Lit substitution %clang_tidy_headers for the system
headers in checkers/Inputs/Headers and use this throughout. This
avoids referencing system headers through a relative path to the
parent directory and makes it clear that these fake system headers are
shared among all modules.
- Update add_new_check.py to follow the above conventions when creating
the boiler plate test files for a new check.
- Update Contributing.rst to describe per-module Inputs directory and
fix link to test source code.
Differential Revision: https://reviews.llvm.org/D128072
The documentation files were reorganized into subdirectories, but a new
check was added concurrently and wasn't rebased correctly before
submitting. Sort the new clang-tidy checks by check name and fix the
indentation of bugprone-unchecked-optional-access.
The misc-unused-parameters check would trigger false positive warnings
about the parameter being unused when the parameter declaration was
invalid. No longer issue the warning in that case on the assumption
that most parameters are used in practice, so the extra diagnostic is
most likely a false positive.
Fixes#56152
There was a copy-paste mistake at the embedded link:
`clang-tidy/checks/cppcoreguidelines-virtual-class-destructor`
->
`clang-tidy/checks/cppcoreguidelines/virtual-class-destructor`
Sphinx error:
/home/zbebnal/git/llvm-project/clang-tools-extra/docs/ReleaseNotes.rst:168:unknown document: clang-tidy/checks/cppcoreguidelines-virtual-class-destructor
Build bot: https://lab.llvm.org/buildbot#builders/115/builds/29805
Differential Revision: https://reviews.llvm.org/D126891
The `cppcoreguidelines-virtual-class-destructor` supposed to enforce
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c35-a-base-class-destructor-should-be-either-public-and-virtual-or-protected-and-non-virtual
Quote:
> A **base** class destructor should be either public and virtual, or
> protected and non-virtual
[emphasis mine]
However, this check still rules the following case:
class MostDerived final : public Base {
public:
MostDerived() = default;
~MostDerived() = default;
void func() final;
};
Even though `MostDerived` class is marked `final`, thus it should not be
considered as a **base** class. Consequently, the rule is satisfied, yet
the check still flags this code.
In this patch, I'm proposing to ignore `final` classes since they cannot
be //base// classes.
Reviewed By: whisperity
Differential Revision: https://reviews.llvm.org/D126891
Fangrui Song