Added new checks
- `performance-noexcept-destructor`
- `performance-noexcept-swap`
Also added cppcoreguidlines aliases for the 2 new checks as well as `performance-noexcept-move-constructor`
This fixes llvm#62154
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D148697
I'd like to use RedundantStringCStrCheck's formatDereference function
from the up-coming modernize-use-std-print check. Let's move it to
FixItHintUtils so that the implementation can be shared.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D150602
This was causes by `getValueOfValueInit` unconditionally calling
`getScalarTypeKind` on the member type, which would then trigger an
assertions since arrays are not scalar type.
This fixes llvm#63285
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D152802
(This patch addresses the comment from https://reviews.llvm.org/D151785#4402460.)
Previously, we used a special printing policy that enabled `PrintCanonicalTypes`
to print type hints for structure bindings. This was intended to
eliminate type aliases like `tuple_element::type`. However, this also
caused TypePrinter to print default template arguments, which could
result in losing the ability to see types like `std::basic_string<char>`
if the fully expanded template-id exceeded the default inlay hint threshold.
Simply getting the canonical type at the call site could help us get rid of
the side effect.
This also merges overloaded `addTypeHint` into one function without
`PrintingPolicy`.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D152520
This patch alleviates https://github.com/clangd/clangd/issues/1298.
Containers in C++ such as `std::vector` or `llvm::SmallVector`,
introduce a series of type aliases to adapt to generic algorithms.
Currently, If we write an declarator involving expressions with
these containers and `auto` placeholder, we probably obtain opaque
type alias like following:
```
std::vector<int> v = {1, 2, 3};
auto value = v[1]; // hint for `value`: value_type
auto *ptr = &v[0]; // hint for `ptr`: value_type *
```
These hints are useless for most of the time. It would be nice if we
desugar the type of `value_type` and print `int`, `int *` respectively
in this situation. But note we can't always prefer desugared type
since user might introduce type-aliases for brevity, where printing
sugared types makes more sense.
This patch introduces a heuristic method that displays the desugared
type that is an alias of template parameter. It merges
analogous method `shouldPrintCanonicalType` into `maybeDesugar` as well.
Previous commit for shouldPrintCanonicalType: dde8a0fe91cc
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D151785
We would like to move the preamble index out of the critical path.
This patch is an RFC to get feedback on the correct implementation and potential pitfalls to keep into consideration.
I am not entirely sure if the lazy AST initialisation would create using Preamble AST in parallel. I tried with tsan enabled clangd but it seems to work OK (at least for the cases I tried)
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D148088
I'd like to use RedundantStringCStrCheck's formatDereference function
from the up-coming modernize-use-std-print check. Let's move it to
FixItHintUtils so that the implementation can be shared.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D150602
Adds a new option to the clang-tidy's check : readability-container-data-pointer to ignore some containers.
This option is useful in the case of std::array where the size is known at compile time and there is no real risk to access the first index of the container. In that case some users might prefer to ignore this type of container.
Relates to : https://github.com/llvm/llvm-project/issues/57445
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D133244
These functions can rethrow a current exception that is caught by the
catch block. We can pass the currently caught excections to the function
declaration analyzer just like the statement analyzer to handle this
case.
Differential Revision: https://reviews.llvm.org/D152330
This is final optimization for this check. Main
improvements comes from changing a logic order
in mayShadow function, to first validate result
of mayShadowImpl, then search primary context in
a vectors. Secondary improvement comes from excluding
all implicit code by using TK_IgnoreUnlessSpelledInSource.
All other changes are just cosmetic improvements.
Tested on Cataclysm-DDA open source project, result in
check execution time reduction from 3682 seconds to
100 seconds (~0.25s per TU). That's 97.2% reduction for
this change alone. Resulting in cumulative improvement for
this check around -99.6%, finally bringing this check
into a cheap category.
Reviewed By: serge-sans-paille
Differential Revision: https://reviews.llvm.org/D151594
The documentation claims that the check recognizes `ASSERT_THAT`, but it doesn't
recognize any googletest macros at the moment. This patch removes the reference.
(When clients support it, otherwise keep the existing rendering).
In VSCode this makes the signature darker.
Differential Revision: https://reviews.llvm.org/D151253
clangIncludeCleaner isn't part of libclang-cpp, so link it with
target_link_libraries instead of clang_target_link_libraries.
This fixes a regression from
c28506ba4b6961950849f8fdecd0cf7e503a14f9.
Fix suggested by Michal Gorny.
Summary:
Recently, the changes in https://reviews.llvm.org/D148793 introduced
some extra dependencies that caused link failured on my machine. This
patch adds the necessary libraries to resolve the link failures and
allow me to build again.
Platform-specific language extensions often want to provide a way of
indicating that certain functions should be called in a different way,
compiled in a different way, or otherwise treated differently from a
“normal” function. Honoring these indications is often required for
correctness, rather being than an optimization/QoI thing.
If a function declaration has a property P that matters for correctness,
it will be ODR-incompatible with a function that does not have property P.
If a function type has a property P that affects the calling convention,
it will not be two-way compatible with a function type that does not
have property P. These properties therefore affect language semantics.
That in turn means that they cannot be treated as standard [[]]
attributes.
Until now, many of these properties have been specified using GNU-style
attributes instead. GNU attributes have traditionally been more lax
than standard attributes, with many of them having semantic meaning.
Examples include calling conventions and the vector_size attribute.
However, there is a big drawback to using GNU attributes for semantic
information: compilers that don't understand the attributes will
(by default) emit a warning rather than an error. They will go on to
compile the code as though the attributes weren't present, which will
inevitably lead to wrong code in most cases. For users who live
dangerously and disable the warning, this wrong code could even be
generated silently.
A more robust approach would be to specify the properties using
keywords, which older compilers would then reject. Some vendor-specific
extensions have already taken this approach. But traditionally, each
such keyword has been treated as a language extension in its own right.
This has three major drawbacks:
(1) The parsing rules need to be kept up-to-date as the language evolves.
(2) There are often corner cases that similar extensions handle differently.
(3) Each extension requires more custom code than a standard attribute.
The underlying problem for all three is that, unlike for true attributes,
there is no established template that extensions can reuse. The purpose
of this patch series is to try to provide such a template.
One option would have been to pick an existing keyword and do whatever
that keyword does. The problem with that is that most keywords only
apply to specific kinds of types, kinds of decls, etc., and so the
parsing rules are (for good reason) not generally applicable to all
types and decls.
Really, the “only” thing wrong with using standard attributes is that
standard attributes cannot affect semantics. In all other respects
they provide exactly what we need: a well-defined grammar that evolves
with the language, clear rules about what an attribute appertains to,
and so on.
This series therefore adds keyword “attributes” that can appear
exactly where a standard attribute can appear and that appertain
to exactly what a standard attribute would appertain to. The link is
mechanical and no opt-outs or variations are allowed. This should
make the keywords predictable for programmers who are already
familiar with standard attributes.
This does mean that these keywords will be accepted for parsing purposes
in many more places than necessary. Inappropriate uses will then be
diagnosed during semantic analysis. However, the compiler would need
to reject the keywords in those positions whatever happens, and treating
them as ostensible attributes shouldn't be any worse than the alternative.
In some cases it might even be better. For example, SME's
__arm_streaming attribute would make conceptual sense as a statement
attribute, so someone who takes a “try-it-and-see” approach might write:
__arm_streaming { …block-of-code…; }
In fact, we did consider supporting this originally. The reason for
rejecting it was that it was too difficult to implement, rather than
because it didn't make conceptual sense.
One slight disadvantage of the keyword-based approach is that it isn't
possible to use #pragma clang attribute with the keywords. Perhaps we
could add support for that in future, if it turns out to be useful.
For want of a better term, I've called the new attributes "regular"
keyword attributes (in the sense that their parsing is regular wrt
standard attributes), as opposed to "custom" keyword attributes that
have their own parsing rules.
This patch adds the Attr.td support for regular keyword attributes.
Adding an attribute with a RegularKeyword spelling causes tablegen
to define the associated tokens and to record that attributes created
with that syntax are regular keyword attributes rather than custom
keyword attributes.
A follow-on patch contains the main Parse and Sema support,
which is enabled automatically by the Attr.td definition.
Other notes:
* The series does not allow regular keyword attributes to take
arguments, but this could be added in future.
* I wondered about trying to use tablegen for
TypePrinter::printAttributedAfter too, but decided against it.
RegularKeyword is really a spelling-level classification rather
than an attribute-level classification, and in general, an attribute
could have both GNU and RegularKeyword spellings. In contrast,
printAttributedAfter is only given the attribute kind and the type
that results from applying the attribute. AFAIK, it doesn't have
access to the original attribute spelling. This means that some
attribute-specific or type-specific knowledge might be needed
to print the attribute in the best way.
* Generating the tokens automatically from Attr.td means that
pseudo's libgrammar does now depend on tablegen.
* The patch uses the SME __arm_streaming attribute as an example
for testing purposes. The attribute does not do anything at this
stage. Later SME-specific patches will add proper semantics for it,
and add other SME-related keyword attributes.
Differential Revision: https://reviews.llvm.org/D148700
Show line numbers to the left of diagnostic code snippets and increase
the numbers of lines shown from 1 to 16.
Differential Revision: https://reviews.llvm.org/D147875
Most users of `Module::Header` already assume its `Entry` is populated. Enforce this assumption in the type system and handle the only case where this is not the case by wrapping the whole struct in `std::optional`. Do the same for `Module::DirectoryName`.
Depends on D151584.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D151586
This patch changes the argument type of `ModuleMap::parseModuleMapFile()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove the deprecated uses of `DirectoryEntry::getName()`.
Depends on D127648.
Reviewed By: bnbarham
Differential Revision: https://reviews.llvm.org/D127651
All exceptions thrown in coroutine bodies are caught and
unhandled_exception member of the coroutine promise type is called.
In accordance with the existing rules of diagnostics related to
exceptions thrown in functions marked noexcept, even if the promise
type's constructor, get_return_object, or unhandled_exception
throws, diagnostics should not be emitted.
Fixes#61905.
Reviewed By: PiotrZSL, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D147417
The variable was introduced without a use by:
commit 2bebc3d0602b407b3f351e782940959da5808f97
Author: Sam McCall <sam.mccall@gmail.com>
Date: Tue Nov 20 10:56:03 2018 +0000
