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
Without this change, code such as "f(/*param=*/1_op)" will check the
comment twice, once for the parameter of f (correct) and once for
the parameter of operator""_op (likely incorrect). The change removes
only the second check.
Reviewed By: njames93, LegalizeAdulthood
Differential Revision: https://reviews.llvm.org/D125885
From [class.copy.ctor]:
```
A non-template constructor for class X is a copy constructor if its first
parameter is of type X&, const X&, volatile X& or const volatile X&, and
either there are no other parameters or else all other parameters have
default arguments (9.3.4.7).
A copy/move constructor for class X is trivial if it is not user-provided and if:
- class X has no virtual functions (11.7.3) and no virtual base classes (11.7.2), and
- the constructor selected to copy/move each direct base class subobject is trivial, and
- or each non-static data member of X that is of class type (or array thereof),
the constructor selected to copy/move that member is trivial;
otherwise the copy/move constructor is non-trivial.
```
So `T(T&) = default`; should be trivial assuming that the previous
provisions are met.
This works in GCC, but not in Clang at the moment:
https://godbolt.org/z/fTGe71b6P
Reviewed By: royjacobson
Differential Revision: https://reviews.llvm.org/D127593
- Rename doc files to subdirs by module
- Update release notes and check list to use subdirs
- Update add_new_check.py to handle doc subdirs
Differential Revision: https://reviews.llvm.org/D126495
This removes parameter inlay hints from a few builtin functions like std::move/std::forward
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D127859
When querying the index during an ObjC protocol name lookup for code
completion, we should only suggest ObjC protocols.
Differential Revision: https://reviews.llvm.org/D127125
This has been tested on a large set of c++ developers for a long while,
without any crashes or complaints.
Differential Revision: https://reviews.llvm.org/D127833
It was previously reverted by 8406839d19.
---
This flag was introduced by
6818991d71
commit 6818991d71
Author: Ted Kremenek <kremenek@apple.com>
Date: Mon Dec 7 22:06:12 2009 +0000
Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
block literals as an entry point for analyzer checks.
The last reference was removed by this commit:
5c32dfc5fb
commit 5c32dfc5fb
Author: Anna Zaks <ganna@apple.com>
Date: Fri Dec 21 01:19:15 2012 +0000
[analyzer] Add blocks and ObjC messages to the call graph.
This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.
Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).
Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
- Should the `cc1` frontend still accept this flag - to keep
tools/users passing this flag directly to `cc1` (which is unsupported,
unadvertised) working.
- If we should remain backward compatible, how long?
- How can we get rid of deprecated and obsolete flags at some point?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126067
The standard type is vastly more popular than the Abseil polyfill, so it
makes more sense to use it in documentation, even though the checker
actually understands both (and that fact is documented already).
D126215 removed the `AnalysisStoreOpt` field, so `clang-tidy` should not
refer to it.
http://45.33.8.238/linux/78232/step_4.txt
../../clang-tools-extra/clang-tidy/ClangTidy.cpp:444:22: error: no
member named 'AnalysisStoreOpt' in 'clang::AnalyzerOptions'
AnalyzerOptions->AnalysisStoreOpt = RegionStoreModel;
~~~~~~~~~~~~~~~~~^
../../clang-tools-extra/clang-tidy/ClangTidy.cpp:444:41: error: use of
undeclared identifier 'RegionStoreModel'
AnalyzerOptions->AnalysisStoreOpt = RegionStoreModel;
This one liner patch should resolve the build failure.
Differential Revision: https://reviews.llvm.org/D126215
This flag was introduced by
6818991d71
commit 6818991d71
Author: Ted Kremenek <kremenek@apple.com>
Date: Mon Dec 7 22:06:12 2009 +0000
Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
block literals as an entry point for analyzer checks.
The last reference was removed by this commit:
5c32dfc5fb
commit 5c32dfc5fb
Author: Anna Zaks <ganna@apple.com>
Date: Fri Dec 21 01:19:15 2012 +0000
[analyzer] Add blocks and ObjC messages to the call graph.
This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.
Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).
Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
- Should the `cc1` frontend still accept this flag - to keep
tools/users passing this flag directly to `cc1` (which is unsupported,
unadvertised) working.
- If we should remain backward compatible, how long?
- How can we get rid of deprecated and obsolete flags at some point?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126067
Before commit b3a991df3c SystemHeaderMap used to be a vector.
Commit b3a991df3c changed it into a map, but neglected to remove
duplicate keys (e.g. "bits/typesizes.h", "include/stdint.h", etc.).
To prevent confusion, remove all duplicates, build HeaderMapping
one pair at a time and assert() that no duplicates are found.
Change by Paul Pluzhnikov (ppluzhnikov)!
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D125742
Add annotation handling ([key=value]) in the BNF grammar parser, which
will be used in the conditional reduction, and error recovery.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D126536
glrReduce maintains two priority queues (one for bases, and the other
for Sequence), these queues are in parallel with each other, corresponding to a
single family. They can be folded into one.
This patch removes the bases priority queue, which improves the glrParse by
10%.
ASTReader.cpp: 2.03M/s (before) vs 2.26M/s (after)
Differential Revision: https://reviews.llvm.org/D127283
As pointed out in the previous review section, having a dedicated accept
action doesn't seem to be necessary. This patch implements the the same behavior
without accept acction, which will save some code complexity.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D125677
Most GSS nodes have short effective lifetimes, keeping them around until the
end of the parse is wasteful. Mark and sweep them every 20 tokens.
When parsing clangd/AST.cpp, this reduces the GSS memory from 1MB to 20kB.
We pay ~5% performance for this according to the glrParse benchmark.
(Parsing more tokens between GCs doesn't seem to improve this further).
Compared to the refcounting approach in https://reviews.llvm.org/D126337, this
is simpler (at least the complexity is better isolated) and has >2x less
overhead. It doesn't provide death handlers (for error-handling) but we have
an alternative solution in mind.
Differential Revision: https://reviews.llvm.org/D126723
There are more states than symbols.
This means first partioning the action list by state leaves us with a smaller
range to binary search over. This improves find() a lot and glrParse() by 7%.
The tradeoff is storing more smaller ranges increases the size of the offsets
array, overall grammar memory is +1% (337->340KB).
Before:
glrParse 188795975 ns 188778003 ns 77 bytes_per_second=1.98068M/s
After:
glrParse 175936203 ns 175916873 ns 81 bytes_per_second=2.12548M/s
Differential Revision: https://reviews.llvm.org/D127006
This is failing to find `EnableABIBreakingCheck` at link time. Add
Support to provide it here.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D127269
The parenthese body should be parameter-declaration-clause, rather
than parameter-declaration-list.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D125479
The clang lexer lexes it as a dedicated token kind (rather than
identifier), we extend the grammar to handle it.
Differential Revision: https://reviews.llvm.org/D126996
Fixes https://github.com/clangd/clangd/issues/1132
where clangd's semantic highlighting is missing for symbols of a template
specialization definition. It turns out the visitor didn't traverse the
base classes of Class/Var##TemplateSpecializationDecl, i.e.
CXXRecordDecl/VarDecl. This patch adds them back as what is done in
DEF_TRAVERSE_TMPL_PART_SPEC_DECL.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D126757
ClangBasic dependency eliminated by replacing our usage of
tok::getPunctuatorSpelling etc with direct use of the *.def file.
Implicit dependencies on clang-tablegen-targets removed as we manage to avoid
any transitive tablegen deps.
After these changes, `ninja clean; ninja pseudo-gen` runs 169 actions only
(basically Support and Demangle).
Differential Revision: https://reviews.llvm.org/D126731
This reverts commit b94db7ed7e.
See comments on https://reviews.llvm.org/D112916:
- breaks `check-clangd`, and makes clang-tidy crash on simple inputs
- likely does the wrong thing in cross builds
Also revert follow-up "[gn build] (manually) port b94db7ed7e (Confusables.inc)"
This reverts commit 180bae08a0.
The HashLoc in InclusionDirective callback is an unused parameter.
Since pp-trace is also used as a test of Clang’s PPCallbacks interface,
add it to the output of pp-trace could avoid some unintended change on
it.
This shuold resolves PR52673
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D125373
Previously, we were treating a move in the lambda capture as if it happened
within the body of the lambda, not within the function that defines the lambda.
This fixes the same bug as https://reviews.llvm.org/D119165 (which it appears
may have been abandoned by the author?) but does so more simply.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D126780
modernize-use-emplace only recommends going from a push_back to an
emplace_back, but does not provide a recommendation when emplace_back is
improperly used. This adds the functionality of warning the user when
an unecessary temporary is created while calling emplace_back or other "emplacy"
functions from the STL containers.
Reviewed By: kuhar, ivanmurashko
Differential Revision: https://reviews.llvm.org/D101471
Without this fix we get
../../clang-tools-extra/unittests/clang-tidy/ModernizeModuleTest.cpp:270:2: error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
};
^
1 error generated.
when compiling with -Werror.
C requires that enum values fit into an int. Scan the macro tokens
present in an initializing expression and reject macros that contain
tokens that have suffixes making them larger than int.
C forbids the comma operator in enum initializing expressions, so
optionally reject comma operator.
Differential Revision: https://reviews.llvm.org/D125622Fixes#55467
This reverts commit a544710cd4.
See discussion in D120540.
This breaks C++ Clang modules on Darwin and also more than a dozen
tests in the LLDB testsuite. I think we need to be more careful to
separate out the enabling of Clang C++ modules and C++20
modules. Either by having -fmodules-ts control the HaveModules flag,
or by adding a way to explicitly turn them off.
When pretty printing the value of an expression, we cannot infer from
the type of the expression the type of the constant that the expression
evaluates to, as the expression might contain a type cast.
This is the intended way to request that build-time tools be built in a
distinct configuration.
This is set implicitly by LLVM_OPTIMIZED_TABLEGEN, which may be
surprising, but if undesired this should be fixed elsewhere.
Should fix crbug.com/1330304
- Use the expression's type for non-C++ as the variable type. This works
well, but might not preserve the typedefs due to type
canonicalization.
- Improve support for Objective-C property references which are
represented using `ObjCPropertyRefExpr` and `BuiltinType::PseudoObject`.
Differential Revision: https://reviews.llvm.org/D124486
This patch allows user to use C++20 module by -fcxx-modules. Previously,
we could only use it under -std=c++20. Given that user could use C++20
coroutine standalonel by -fcoroutines-ts. It makes sense to offer an
option to use C++20 modules without enabling C++20.
Reviewed By: iains, MaskRay
Differential Revision: https://reviews.llvm.org/D120540
If two different texts are inserted at the same offset, clang-apply-replacements prints the conflict error and discards all fixes. This patch adds support for adjusting conflict offset and keeps running to continually fix them.
https://godbolt.org/z/P938EGoxj doesn't have any fixes when I run run-clang-tidy.py to generate a YAML file with clang-tidy and fix them with clang-apply-replacements. The YAML file has two different header texts insertions at the same offset, unlike clang-tidy with '-fix', clang-apply-replacements does not adjust for this conflict.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123924
The checker missed a check for parameter type of primary template of specialization template and this could cause build breakages.
Reviewed By: aaron.ballman, flx
Differential Revision: https://reviews.llvm.org/D116593
Use the LLVM build system's cross-compilation support for the tool, so
that the build works for both host and cross-compilation scenarios.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D126397
Virtually all LLVM tools accept a `-o` flag, so add one. This will make it
possible to possibly add a --write-if-changed flag later. It also makes it
so that the file isn't partially written if the tool oesn't run successfully.
Marking --grammar as `Required` allows removing some manual
verification code for it.
Differential Revision: https://reviews.llvm.org/D126373
Adds an option SimplifyDemorganRelaxed which, when enabled, will transform negated conjunctions or disjunctions when neither operand is a negation.
Default value is `false`.
Reviewed By: LegalizeAdulthood
Differential Revision: https://reviews.llvm.org/D126162
The main idea is to compile the cxx grammar at build time, and construct
the core pieces (Grammar, LRTable) of the pseudoparse based on the compiled
data sources.
This is a tiny implementation, which is good for start:
- defines how the public API should look like;
- integrates the cxx grammar compilation workflow with the cmake system.
- onlynonterminal symbols of the C++ grammar are compiled, anything
else are still doing the real compilation work at runtime, we can opt-in more
bits in the future;
- splits the monolithic clangPsuedo library for better layering;
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D125667
5da7c04 introduced a regression in the NOLINT macro checking loop, replacing the
call to `getImmediateExpansionRange().getBegin()` with
`getImmediateMacroCallerLoc()`, which has similar but subtly different
behaviour.
The consequence is that NOLINTs cannot suppress diagnostics when they are
attached to a token that came from a macro **argument**, rather than elsewhere
in the macro expansion.
Revert to pre-patch behaviour and add test cases to cover this issue.
Differential Revision: https://reviews.llvm.org/D126138
Error-tolerant bracket matching enables our error-tolerant parsing strategies.
The implementation here is *not* yet error tolerant: this patch sets up the APIs
and plumbing, and describes the planned approach.
Differential Revision: https://reviews.llvm.org/D125911
When looking for whether or not a check provides fixits, the script
examines the implementation of the check. Some checks are not
implemented in source files that correspond one-to-one with the check
name, e.g. cert-dcl21-cpp. So if we can't find the check implementation
directly from the check name, open up the corresponding module file and
look for the class name that is registered with the check. Then consult
the file corresponding to the class name.
Some checks are derived from a base class that implements fixits. So if
we can't find fixits in the implementation file for a check, scrape out
the name of it's base class. If it's not ClangTidyCheck, then consult
the base class implementation to look for fixit support.
Differential Revision: https://reviews.llvm.org/D126134Fixes#55630
I and @whisperity spent some time debugging a LIT test case using the
`-std=c++11-or-later` `check_clang_tidy.py` flag when the test had
fixits.
It turns out if the test wants to report a diagnostic into a header
file AND into the test file as well, one needs to first copy the header
somewhere under the build directory.
It needs to be copied since `clang-tidy` sorts the reports into
alphabetical order, thus to have a deterministic order relative to the
diagnostic in the header AND the diagnostic in the test cpp file.
There is more to this story.
The `-std=c++11-or-later` turns out executes the test with multiple
`-std=XX` version substitution, and each execution will also have the
`-fix` tidy parameter. This means that the freshly copied header file I
stated in the previous paragraph gets fixed up and the very next tidy
execution will fail miserably.
Following @whisperity's advice, I'm leaving a reminder about such
//shared// state in the related doc comment.
Reviewed By: LegalizeAdulthood
Differential Revision: https://reviews.llvm.org/D125771
The end-user has no way of 'fixing' bugs in the system library anyway.
Let's suppress these as well.
Reviewed By: LegalizeAdulthood
Differential Revision: https://reviews.llvm.org/D125770
Unfortunately, we must restrict the checker to warn for deprecated headers
only if the header is included directly from a c++ source file.
For header files, we cannot know if the project has a C source file
that also directly/indirectly includes the offending header file
otherwise. Thus, it's better to be on the safe side and suppress those
reports.
One can opt-in the old behavior, emitting diagnostics into header files,
if one explicitly sets the WarnIntoHeaders=true, in which case nothing
will be changed.
Reviewed By: LegalizeAdulthood
Differential Revision: https://reviews.llvm.org/D125769
This partially reverts commit e8cae48702.
Changes since that commit:
- Use `SourceManager::isBeforeInTranslationUnit` instead of the fancy
decomposed decl logarithmic search.
- Add a test for including a system header containing a deprecated
include.
- Add `REQUIRES: system-linux` clause to the test.
Reviewed By: LegalizeAdulthood, whisperity
Differential Revision: https://reviews.llvm.org/D125209
Previously, clangd would filter completions only on the first part of
the selector (first typed chunk) instead of all remaining selector
fragments (all typed chunks).
Differential Revision: https://reviews.llvm.org/D124637
LSP supports Diagnostic.codeInformation since 3.16.
In VSCode, this turns the code (e.g. "unused-includes" or "bugprone-foo") into
a clickable link that opens the docs in a web browser.
Differential Revision: https://reviews.llvm.org/D126065
This allows index implementations to fill container details when required specially when computing containerID is expensive.
Differential Revision: https://reviews.llvm.org/D125925
Explicitly sizing Kind enum suggests that too-large values are allowed,
and that putting it in a bitfield is dangerous.
GCC doesn't like condition ? integer : enum.
Tracked down the crash, which was argument-evaluation-order UB
in the wrapping indexStandardLibrary().
Sorry for the churn!
This reverts commit 77533ea443.
This reverts commit ccdb56ac10.
Still seeing windows failures on GN bots: http://45.33.8.238/win/58316/step_9.txt
Unfortunately I can't debug these at all - it's a bare unsymbolized
stacktrace, and I can't reproduce the failure.
- add missing benchmark for lex/preprocess steps
- name benchmarks after the function they're benchmarking, when appropriate
- remove unergonomic "run" prefixes from benchmark names
- give a useful error message if --grammar or --source are missing
- Use realistic example of how to run, run all benchmarks by default.
(for someone who doesn't know the commands, this is the most useful action)
- Improve typos/wording in comment
- clean up unused vars
- avoid "parseable stream" name, which isn't a great name & not one I expected
to escape from ClangPseudoMain
Differential Revision: https://reviews.llvm.org/D125312
This is a followup to D124715, which changed the default, and it anticipates
future patches raising the priority of Low (which is currently equal to
Background on Windows & Linux).
The main point is to allow users to restore the old behavior, which e.g.
allows efficiency cores to remain idle.
I did consider making this a config setting, this is a more complicated change:
- needs to touch queue priorities as well as thread priorities
- we don't know the priority until evaluating the config inside the task
- users would want the ability to prioritize background indexing tasks relative
to each other without necessarily affecting thread priority, so using one
option for both may be confusing
I don't really have a use case, so I prefer the simpler thing.
Differential Revision: https://reviews.llvm.org/D125673
This provides a nice "warm start" with all headers indexed, not just
those included so far.
The standard library is indexed after a preamble is parsed, using that
file's configuration. The result is pushed into the dynamic index.
If we later see a higher language version, we reindex it.
It's configurable as Index.StandardLibrary, off by default for now.
Based on D105177 by @kuhnel
Fixes https://github.com/clangd/clangd/issues/618
Differential Revision: https://reviews.llvm.org/D115232
Previously the Expr returned by getOperand() was actually the
subexpression common to the "ready", "suspend", and "resume"
expressions, which often isn't just the operand but e.g.
await_transform() called on the operand.
It's important for the AST to expose the operand as written
in the source for traversals and tools like clangd to work
correctly.
Fixes https://github.com/clangd/clangd/issues/939
Differential Revision: https://reviews.llvm.org/D115187
Reimplement the matching logic using Visitors instead of matchers.
Benchmarks from running the check over SemaCodeComplete.cpp
Before 0.20s, After 0.04s
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D125026
I am working on support for forwarding parameter names in make_unique-like functions, first for inlay hints, later maybe for signature help.
For that to work generically, I'd like to parse all of these functions in the preamble. Not sure how this impacts performance on large codebases though.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D124688
With this patch, we're able to parse smaller chunks of C++ code (statement,
declaration), rather than translation-unit.
The start symbol is listed in the grammar in a form of `_ :=
statement`, each start symbol has a dedicated state (`_ := • statement`).
We create and track all these separate states in the LRTable. When we
start parsing, we lookup the corresponding state to start the parser.
LR pasing table changes with this patch:
- number of states: 1467 -> 1471
- number of actions: 82891 -> 83578
- size of the table (bytes): 334248 -> 336996
Differential Revision: https://reviews.llvm.org/D125006
Disable the warnings with `IWYU pragma: export` or `begin_exports` +
`end_exports` until we have support for these pragmas. There are too many
false-positive warnings for the headers that have the correct pragmas for now
and it makes the user experience very unpleasant.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D125468
On Apple Silicon Macs, using a Darwin thread priority of PRIO_DARWIN_BG seems to
map directly to the QoS class Background. With this priority, the thread is
confined to efficiency cores only, which makes background indexing take forever.
Introduce a new ThreadPriority "Low" that sits in the middle between Background
and Default, and maps to QoS class "Utility" on Mac. Make this new priority the
default for indexing. This makes the thread run on all cores, but still lowers
priority enough to keep the machine responsive, and not interfere with
user-initiated actions.
I didn't change the implementations for Windows and Linux; on these systems,
both ThreadPriority::Background and ThreadPriority::Low map to the same thread
priority. This could be changed as a followup (e.g. by using SCHED_BATCH for Low
on Linux).
See also https://github.com/clangd/clangd/issues/1119.
Reviewed By: sammccall, dgoldman
Differential Revision: https://reviews.llvm.org/D124715
Clang erroneously flagged the function as "unused", but it is most
definitely used by gtest to pretty print the parameter value when
a test fails.
Make the pretty printing function a friend function in the parameter
class similar to other clang unit tests.
Add a recursive descent parser to match macro expansion tokens against
fully formed valid expressions of integral literals. Partial
expressions will not be matched -- they can't be valid initializing
expressions for an enum.
Differential Revision: https://reviews.llvm.org/D124500Fixes#55055
The check should not report includes wrapped by `extern "C" { ... }` blocks,
such as:
```lang=C++
#ifdef __cplusplus
extern "C" {
#endif
#include "assert.h"
#ifdef __cplusplus
}
#endif
```
This pattern comes up sometimes in header files designed to be consumed
by both C and C++ source files.
The check now reports false reports when the header file is consumed by
a C++ translation unit.
In this change, I'm not emitting the reports immediately from the
`PPCallback`, rather aggregating them for further processing.
After all preprocessing is done, the matcher will be called on the
`TranslationUnitDecl`, ensuring that the check callback is called only
once.
Within that callback, I'm recursively visiting each decls, looking for
`LinkageSpecDecls` which represent the `extern "C"` specifier.
After this, I'm dropping all the reports coming from inside of it.
After the visitation is done, I'm emitting the reports I'm left with.
For performance reasons, I'm sorting the `IncludeMarkers` by their
corresponding locations.
This makes the scan `O(log(N)` when looking up the `IncludeMarkers`
affected by the given `extern "C"` block. For this, I'm using
`lower_bound()` and `upper_bound()`.
Reviewed By: whisperity
Differential Revision: https://reviews.llvm.org/D125209
Fixes the `FIXME:` related to adding `forEachTemplateArgument` to the
core AST Matchers library.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D125383
`FileNotFound` preprocessor callback is removed in D119708.
We should also remove it from the documentation.
Reviewed by: jansvoboda11
Differential Revision: https://reviews.llvm.org/D125258
- Make clangd's internal representation more aligned with the standard.
We keep range and extra inlayhint kinds around, but don't serialize
them on standard version.
- Have custom serialization for extension (ugly, but going to go away).
- Support both versions until clangd-17.
- Don't advertise extension if client has support for standard
implementation.
- Log a warning at startup about extension being deprecated, if client
doesn't have support.
Differential Revision: https://reviews.llvm.org/D125228
This is unneccesary work.
With this change, we skip generating and lexing ~10k of predefines twice.
A dumb benchmark of building a preamble for an empty file in a loop shows:
- before: 1.90ms/run
- after: 1.36ms/run
So this should be worth 0.5ms for each AST build and code completion.
There can be a functional difference, but it's very minor.
If the preamble contains e.g. `#ifndef __llvm__ ... #endif` then before we would
not take it. After this change we will take the branch (single-file mode takes
all branches with unknown conditions) and so gather different directives.
However I think this is negligible:
- this is already true of non-builtin macros (from included headers).
We've had no complaints.
- this affects the baseline and modified in the same way, so only makes a
difference transiently when code guarded by such an #ifdef is being edited
Differential Revision: https://reviews.llvm.org/D125179
Previously the EXPECT_AVAILABLE macros would rebuild the code at each marked
point, by expanding the cases textually.
There were often lots, and it's nice to have lots!
This reduces total unittest time by ~10% on my machine.
I did have to sacrifice a little apply() coverage in AddUsingTests (was calling
expandCases directly, which was otherwise unused), but we have
EXPECT_AVAILABLE tests covering that, I don't think there's real risk here.
Differential Revision: https://reviews.llvm.org/D125109
This is a clever cross-cutting sanity test for clang's arg parsing I suppose.
But clangd creates thousands of invocations, ~all with identical trivial
arguments, and problems with these would be caught by clang's tests.
This overhead accounts for 10% of total unittest time!
Differential Revision: https://reviews.llvm.org/D125169
These aren't needed. With them the generated predefines buffer is 13KB.
For every TestTU, we must:
- generate the buffer (3 times: parsing preamble, scanning preamble, main file)
- parse the buffer (again 3 times)
- serialize all the macros it defines in the PCH
- compress the buffer itself to write it into the PCH
- decompress it from the PCH
Avoiding this reduces unit test time by ~25%.
Differential Revision: https://reviews.llvm.org/D125172
There's many instances in clang tidy checks where owning strings are used when we already have a stable string from the options, so using a StringRef makes much more sense.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124341
All llvm-project fuzzers use this library to parse command-line arguments.
Many of them don't deal with LLVM IR or modules in any way. Bundling those
functions in one library forces build dependencies that don't need to be there.
Among other things, this means check-clang-pseudo no longer depends on most of
LLVM.
Differential Revision: https://reviews.llvm.org/D125081
This change was intended to add the tests check-clang and check-clang-pseudo,
but afterwards it was *only* running those tests.
(This was because unlike add_lit_testsuite, add_lit_testsuite*s* does not
get included in umbrella suites).
This check verifies the safety of access to `std::optional` and related
types (including `absl::optional`). It is based on a corresponding Clang
Dataflow Analysis, which does most of the work. This check merely runs it and
converts its findings into diagnostics.
Differential Revision: https://reviews.llvm.org/D121120
This testcase runs slowly due to 3.2s of sleeps = 2 + 1 + 0.2s.
After this patch it has 0.55s only.
Reduced by:
- observed that the last test was bogus: we were sleeping until the queue was
idle, effectively just a second copy of the first test. This avoids 1s sleep.
- when waiting for debounce, sleep only until test passes, not for enough
time to be safe (in practice was 2x debounce time, now 1x debounce time)
- scaling delays down by a factor of 2 (note: factor of 10 caused bot failures)
Differential Revision: https://reviews.llvm.org/D125103
This method won't add a check if it isn't supported in the Contexts current LanguageOptions.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124320
The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.
We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:
umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)
(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt
This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).
Differential Revision: https://reviews.llvm.org/D121838
This includes only the taken branch of conditional sections.
The API allows for producing a stream for a particular PP branch, which
will be used later for the secondary GLR parses of not-taken branches.
Differential Revision: https://reviews.llvm.org/D123243
As confirmation, running this locally found 2 crashes:
- trivial: crashes on file with no tokens
- lexer: hits an assertion failure on bytes: 0x5c,0xa,0x5c,0x1,0x65,0x5c,0xa
Differential Revision: https://reviews.llvm.org/D125037
It turns out clang::expandUCNs only works on tokens that contain valid UCNs
and no other random escapes, and clang only uses it on raw_identifiers.
Currently we can hit an assertion by creating tokens with stray non-valid-UCN
backslashes in them.
Fortunately, expanding UCNs in raw_identifiers is actually all we need.
Most tokens (keywords, punctuation) can't have them. UCNs in literals can be
treated as escape sequences like \n even this isn't the standard's
interpretation. This more or less matches how clang works.
(See https://isocpp.org/files/papers/P2194R0.pdf which points out that the
standard's description of how UCNs work is misaligned with real implementations)
Differential Revision: https://reviews.llvm.org/D125049
Currently it rejects "// FOO_BAR_H" as an endif comment due to the extra space.
A user complained that this is too picky, which seems fair enough.
Differential Revision: https://reviews.llvm.org/D124955
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
Messages generated by Transformer rules may have `%` in them, which
needs to be escaped before being passed to `diag`, which interprets them
specially (and crashes if they are misused).
Differential Revision: https://reviews.llvm.org/D124952
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.
This patch implements a standard GLR parsing algorithm, the
core piece of the pseudoparser.
- it parses preprocessed C++ code, currently it supports correct code
only and parse them as a translation-unit;
- it produces a forest which stores all possible trees in an efficient
manner (only a single node being build for per (SymbolID, Token Range));
no disambiguation yet;
Reland with a fix for g++'s -fpermissive error on previous declaration `GSS& GSS;`.
Differential Revision: https://reviews.llvm.org/D121150
This patch implements a standard GLR parsing algorithm, the
core piece of the pseudoparser.
- it parses preprocessed C++ code, currently it supports correct code
only and parse them as a translation-unit;
- it produces a forest which stores all possible trees in an efficient
manner (only a single node being build for per (SymbolID, Token Range));
no disambiguation yet;
Differential Revision: https://reviews.llvm.org/D121150
The code was written to handle nullable grammar, and we disallow
nullable grammar, so it is not necessary to keep it around.
Differential Revision: https://reviews.llvm.org/D124827
Add a & prefix to all parameter inlay hints that refer to a non-const l-value reference. That makes it easier to identify them even if semantic highlighting is not used (where this is already available)
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D124359
In C++ and C2x, we would avoid calling ImplicitlyDefineFunction at all,
but in OpenCL mode we would still call the function and have it produce
an error diagnostic. Instead, we now have a helper function to
determine when implicit function definitions are allowed and we use
that to determine whether to call ImplicitlyDefineFunction so that the
behavior is more consistent across language modes.
This changes the diagnostic behavior from telling the users that an
implicit function declaration is not allowed in OpenCL to reporting use
of an unknown identifier and going through typo correction, as done in
C++ and C2x.
Nathan James