Summary:
Following on from review comments in D65919 about the ordering
of the registerCheck<> calls. Sort based on the check name which might
be on the line after the registerCheck<>
Reviewers: aaron.ballman
Subscribers: cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66505
llvm-svn: 370527
Summary: Structured bindings are in a BindingDecl. The decl the declRefExpr points to are the BindingDecls. So this adds an additional if statement in the addToken function to highlight them.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66738
llvm-svn: 370473
Summary: TokenBuffer does not collect macro expansions inside macro arguments which is needed for semantic higlighting. Therefore collects macro expansions in the main file in a PPCallback when building the ParsedAST instead.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66928
llvm-svn: 370452
Summary:
We didn't change this in D64019 just in case we revert it back.
Deleting it now.
Reviewers: hokein, sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66943
llvm-svn: 370367
Exposed a new function, createIndexingASTConsumer, that creates an
ASTConsumer. ASTConsumers compose well.
Removed wrapping functionality from createIndexingAction.
llvm-svn: 370337
Summary:
Add event listener that listens to configuration changes and reloads the ThemeRuleMatcher when the theme changes.
Right now it will not recolor the files, depends on the colorizer CL for that.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66406
llvm-svn: 370305
Summary:
- Only works for extraction from free functions
- Basic analysis of the code being extracted.
- Extract to void function
- Bail out if extracting a return, continue or break.
- Doesn't hoist decls yet
Reviewers: kadircet, sammccall
Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65526
llvm-svn: 370249
Summary: We miss a few places where we need to add them to the subscriptions.
Reviewers: jvikstrom
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66881
llvm-svn: 370218
Summary: Disposes of the vscode listeners when clangd crashes and reuses the old highlighter when it restarts. The reason for reusing the highlighter is because this way the highlightings will not disappear as we won't have to dispose of them.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66743
llvm-svn: 370202
Summary:
The recordIsTriviallyDefaultConstructible may cause an infinite loop when
running on an ill-formed decl.
Reviewers: gribozavr
Subscribers: nemanjai, xazax.hun, kbarton, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66874
llvm-svn: 370200
Summary:
Those errors are exposed at the first character of a file,
for a lack of a better place.
Previously, all errors were stored inside the AST and report
accordingly. However, errors in command-line argument parsing could
result in failure to produce the AST, so we need an alternative ways to
report those errors.
We take the following approach in this patch:
- buildCompilerInvocation() now requires an explicit DiagnosticConsumer.
- TUScheduler and TestTU now collect the diagnostics produced when
parsing command line arguments.
If pasing of the AST failed, diagnostics are reported via a new
ParsingCallbacks::onFailedAST method.
If parsing of the AST succeeded, any errors produced during
command-line parsing are stored alongside the AST inside the
ParsedAST instance and reported as previously by calling the
ParsingCallbacks::onMainAST method;
- The client code that uses ClangdServer's DiagnosticConsumer
does not need to change, it will receive new diagnostics in the
onDiagnosticsReady() callback
Errors produced when parsing command-line arguments are collected using
the same StoreDiags class that is used to collect all other errors. They
are recognized by their location being invalid. IIUC, the location is
invalid as there is no source manager at this point, it is created at a
later stage.
Although technically we might also get diagnostics that mention the
command-line arguments FileID with after the source manager was created
(and they have valid source locations), we choose to not handle those
and they are dropped as not coming from the main file. AFAICT, those
diagnostics should always be notes, therefore it's safe to drop them
without loosing too much information.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: nridge, javed.absar, MaskRay, jkorous, arphaman, cfe-commits, gribozavr
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66759
llvm-svn: 370177
"Bad block found.\n" -> "bad block found"
The lower cased form with no full stop or newline is more common in LLVM
tools.
Reviewed By: juliehockett
Differential Revision: https://reviews.llvm.org/D66783
llvm-svn: 370155
The clang-tidy-vs visual studio plugin in clang-tools-extra contains a
security vulnerability in the YamlDotNet package [1]. I posted to cfe-dev [2],
asking if there was anyone who was interested in updating the the plugin
to address the vulnerability. Reid mentioned that Zach (the original committer),
said that there's another plugin (Clang Power Tools) that provides clang-tidy support,
with additional extra features, so it would be ok to remove clang-tidy-vs.
This commit removes the plugin to address the security vulnerability, and adds
a section to the release notes that mentions that the plugin was removed, and
suggests to use Clang Power Tools.
Fixes PR 41791.
[1]: https://nvd.nist.gov/vuln/detail/CVE-2018-1000210
[2]: http://lists.llvm.org/pipermail/cfe-dev/2019-August/063196.html
Differential Revision: https://reviews.llvm.org/D66813
llvm-svn: 370096
This fixes the issue where a filename dependendency was missing if the file that
was referenced with __has_include() was accessed through a symlink in an earlier run,
if the file manager was reused between runs.
llvm-svn: 370081
Summary: I think it makes method implementations more obvious.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66788
llvm-svn: 370039
Summary:
Previously, it would always return nullptr on any error.
This change adds a parameter, controlling whether the function should
attempt to return a non-null result even if unknown arguments (or other
errors were encountered).
The new behavior is only used in clangd.
Considered an alternative of changing the return value instead of adding
a new parameter, but that would require updating all callsites. Settled
with the parameter to minimize the code changes.
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: nridge, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66731
llvm-svn: 370033
Summary:
The last glob that matches the string decides whether that string is
included or excluded.
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66787
llvm-svn: 370028
This fixes the issue where a filename dependendency was missing if the file that
was skipped was included through a symlink in an earlier run, if the file
manager was reused between runs.
llvm-svn: 369998
Summary:
It is a separate abstraction that is used in more contexts than just
a helper for ClangTidyDiagnosticConsumer.
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66747
llvm-svn: 369918
Summary:
This is a first step in documenting different configuration knobs we
have in clangd.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66740
llvm-svn: 369917
One call `makeRule` is unqualified (and unintentionally relying on ADL to
resolve correctly). This revision qualifies that call for consistency and to
drop use of ADL.
llvm-svn: 369915
Summary:
This patch changes the location specified to the
`ClangTidyCheck::diag()`. Currently, the beginning of the matched range is
used. This patch uses the beginning of the first fix's range. This change both
simplifies the code and (hopefully) gives a more intuitive result: the reported
location aligns with the fix(es) provided, rather than the (arbitrary) range of
the rule's match.
N.B. this patch will break the line offset numbers in lit tests if the first fix
is not at the beginning of the match.
Reviewers: gribozavr
Subscribers: xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66676
llvm-svn: 369914
Summary:
Just reapplies highlightings for all files when visible text editors change. Could find the correct text editor that should be reapplied but going for a simple implementation instead.
Removes the associated highlighting entry from the Colorizer when a text document is closed.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66735
llvm-svn: 369911
Summary:
Adds the main colorizer component. It colorizes every time clangd sends a publishSemanticHighlighting notification.
Every time it colorizes it does a full recolorization (removes all decorations from the editor and applies new ones). The reason for this is that all ranges for the same scope share a TextEditorDecorationType. This is due to TextEditorDecorationTypes being very expensive to create. The prototype used one DecorationType per range but that ran into very big performance problems (it took >100 ms to apply 600 lines of highlightings which froze the editor).
This version does not share the problem of being extremly slow, but there is probably potential to optimize it even more.
No document/texteditor lifecycle management code in this CL, that will come in the next one.
Reviewers: hokein, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66219
llvm-svn: 369893
Summary: This would make the client life (tracking the changes) easier.
Reviewers: jvikstrom
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66541
llvm-svn: 369884
Daniel Sanders