Commit Graph

1019 Commits

Author SHA1 Message Date
serge-sans-paille 299aa4dfa1 Misleading unicode identifier detection pass
Detect when an identifier contains some Right-To-Left characters.
This pass relates to https://trojansource.codes/

Differential Revision: https://reviews.llvm.org/D112914
2021-11-09 16:01:28 +01:00
CJ Johnson 16b07c866a [clang-tidy] Add check for initialization of `absl::Cleanup`.
Suggests switching the initialization pattern of `absl::Cleanup` instances from the factory function to class template argument deduction (CTAD) in C++17 and higher.

Reviewed By: ymandel

Differential Revision: https://reviews.llvm.org/D113195
2021-11-08 15:57:32 +00:00
Quinn Pham c3b15b71ce [NFC] Inclusive Language: change master to main for .chm files
[NFC] As part of using inclusive language within the llvm project,
this patch replaces master with main when referring to `.chm` files.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D113299
2021-11-08 08:23:04 -06:00
Balázs Kéri 4bcbb3d4d7 [clang-tidy] Add check 'cert-err33-c'.
The CERT rule ERR33-C can be modeled partially by the existing check
'bugprone-unused-return-value'. The existing check is reused with
a fixed set of checked functions.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D112409
2021-11-02 11:38:47 +01:00
Salman Javed 5de69e16ea [clang-tidy] Tidy up spelling, grammar, and inconsistencies in documentation (NFC)
Differential Revision: https://reviews.llvm.org/D112356
2021-10-23 00:07:36 -07:00
Carlos Galvez bf6b0d1674 [clang-tidy] Support globbing in NOLINT* expressions
To simplify suppressing warnings (for example, for
when multiple check aliases are enabled).

The globbing format reuses the same code as for
globbing when enabling checks, so the semantics
and behavior is identical.

Differential Revision: https://reviews.llvm.org/D111208
2021-10-19 16:30:51 +00:00
Balázs Kéri a76cfc2e84 [clang-tidy] Update documentation of check bugprone-unused-return-value [NFC].
The list of checked functions was incomplete in the description.

Reviewed By: aaron.ballman, steakhal

Differential Revision: https://reviews.llvm.org/D111623
2021-10-12 16:43:45 +02:00
Carlos Galvez 40546cb381 Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions
This requirement was introduced in the C++ Core guidelines in 2016:

1894380d0a

Then clang-tidy got updated to comply with the rule.

However in 2019 this decision was reverted:

5fdfb20b76

Therefore we need to apply the correct configuration to
clang-tidy again.

This also makes this cppcoreguidelines check consistent
with the other 2 alias checks: hicpp-use-override and
modernize-use-override.

Additionally, add another RUN line to the unit test,
to make sure cppcoreguidelines-explicit-virtual-functions
is tested.
2021-10-12 10:08:08 -04:00
Salman Javed 722e705f72 Revert 9b944c1843 with fixes
This reintroduces c0687e1984 (Add support
for `NOLINTBEGIN` ... `NOLINTEND` comments) but with fixes to the tests.
2021-09-29 08:00:45 -04:00
Aaron Ballman 9b944c1843 Revert "Add support for `NOLINTBEGIN` ... `NOLINTEND` comments"
This reverts commit c0687e1984.

There are testing failures being caught by bots.
See http://45.33.8.238/linux/56886/step_8.txt as an example.
2021-09-28 14:49:27 -04:00
Salman Javed c0687e1984 Add support for `NOLINTBEGIN` ... `NOLINTEND` comments
Add support for NOLINTBEGIN ... NOLINTEND comments to suppress
clang-tidy warnings over multiple lines. All lines between the "begin"
and "end" markers are suppressed.

Example:

// NOLINTBEGIN(some-check)
<Code with warnings to be suppressed, line 1>
<Code with warnings to be suppressed, line 2>
<Code with warnings to be suppressed, line 3>
// NOLINTEND(some-check)
Follows similar syntax as the NOLINT and NOLINTNEXTLINE comments
that are already implemented, i.e. allows multiple checks to be provided
in parentheses; suppresses all checks if the parentheses are omitted,
etc.

If the comments are misused, e.g. using a NOLINTBEGIN but not
terminating it with a NOLINTEND, a clang-tidy-nolint diagnostic
message pointing to the misuse is generated.

As part of implementing this feature, the following bugs were fixed in
existing code:

IsNOLINTFound(): IsNOLINTFound("NOLINT", Str) returns true when Str is
"NOLINTNEXTLINE". This is because the textual search finds NOLINT as
the stem of NOLINTNEXTLINE.

LineIsMarkedWithNOLINT(): NOLINTNEXTLINEs on the very first line of a
file are ignored. This is due to rsplit('\n\').second returning a blank
string when there are no more newline chars to split on.
2021-09-28 07:53:23 -04:00
M Bakinovsky 4f01a02d73 Fix documentation typos; NFC
Fixes bugprone-virtual-near-miss & performance-type-promotion-in-math-fn.
2021-09-28 06:56:49 -04:00
Saleem Abdulrasool f1e8ceb305 docs: correct SPHNIX document reference
The trailing `>` was missing, which resulted in the reference not being
processed properly.
2021-09-16 17:43:59 +00:00
Saleem Abdulrasool d249200fa7 Revert "Re-Revert "clang-tidy: introduce readability-containter-data-pointer check""
This reverts commit 626586fc25.

Tweak the test for Windows.  Windows defaults to delayed template
parsing, which resulted in the main template definition not registering
the test on Windows.  Process the file with the additional
`-fno-delayed-template-parsing` flag to change the default beahviour.
Additionally, add an extra check for the fix it and use a more robust
test to ensure that the value is always evaluated.

Differential Revision: https://reviews.llvm.org/D108893
2021-09-15 20:52:55 +00:00
Nico Weber 626586fc25 Re-Revert "clang-tidy: introduce readability-containter-data-pointer check"
This reverts commit 49992c0414.
The test is still failing on Windows, see comments on https://reviews.llvm.org/D108893
2021-09-14 22:27:59 -04:00
Saleem Abdulrasool 49992c0414 Revert "Revert "clang-tidy: introduce readability-containter-data-pointer check""
This reverts commit 76dc8ac36d.

Restore the change.  The test had an incorrect negative from testing.
The test is expected to trigger a failure as mentioned in the review
comments.  This corrects the test and should resolve the failure.
2021-09-14 10:52:35 -07:00
Nico Weber 76dc8ac36d Revert "clang-tidy: introduce readability-containter-data-pointer check"
This reverts commit d0d9e6f084.
Breaks tests, see e.g. https://lab.llvm.org/buildbot/#/builders/188/builds/3326
2021-09-14 12:37:10 -04:00
Saleem Abdulrasool d0d9e6f084 clang-tidy: introduce readability-containter-data-pointer check
This introduces a new check, readability-containter-data-pointer.  This
check is meant to catch the cases where the user may be trying to
materialize the data pointer by taking the address of the 0-th member of
a container.  With C++11 or newer, the `data` member should be used for
this.  This provides the following benefits:

- `.data()` is easier to read than `&[0]`
- it avoids an unnecessary re-materialization of the pointer
  * this doesn't matter in the case of optimized code, but in the case
    of unoptimized code, this will be visible
- it avoids a potential invalid memory de-reference caused by the
  indexing when the container is empty (in debug mode, clang will
  normally optimize away the re-materialization in optimized builds).

The small potential behavioural change raises the question of where the
check should belong.  A reasoning of defense in depth applies here, and
this does an unchecked conversion, with the assumption that users can
use the static analyzer to catch cases where we can statically identify
an invalid memory de-reference.  For the cases where the static analysis
is unable to prove the size of the container, UBSan can be used to track
the invalid access.

Special thanks to Aaron Ballmann for the discussion on whether this
check would be useful and where to place it.

This also partially resolves PR26817!

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D108893
2021-09-14 08:12:10 -07:00
Marco Gartmann c58c7a6ea0 [clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check
Finds base classes and structs whose destructor is neither public and
virtual nor protected and non-virtual.
A base class's destructor should be specified in one of these ways to
prevent undefined behaviour.

Fixes are available for user-declared and implicit destructors that are
either public and non-virtual or protected and virtual.

This check implements C.35 [1] from the CppCoreGuidelines.

Reviewed By: aaron.ballman, njames93

Differential Revision: http://reviews.llvm.org/D102325

  [1]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual
2021-09-09 13:23:38 +02:00
Kazu Hirata d8afa5777b [clang-tidy] Fix documentation typos (NFC) 2021-09-01 08:48:31 -07:00
Gabor Bencze 3373e84539 [clang-tidy] Add bugprone-suspicious-memory-comparison check
The check warns on suspicious calls to `memcmp`.
It currently checks for comparing types that do not have
unique object representations or are non-standard-layout.
Based on
  https://wiki.sei.cmu.edu/confluence/display/c/EXP42-C.+Do+not+compare+padding+data
  https://wiki.sei.cmu.edu/confluence/display/c/FLP37-C.+Do+not+use+object+representations+to+compare+floating-point+values
and part of
  https://wiki.sei.cmu.edu/confluence/display/cplusplus/OOP57-CPP.+Prefer+special+member+functions+and+overloaded+operators+to+C+Standard+Library+functions
Add alias `cert-exp42-c` and `cert-flp37-c`.

Some tests are currently failing at head, the check depends on D89649.
Originally started in D71973

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D89651
2021-08-26 09:23:37 +02:00
Florin Iucha d2c5cbc3a8 Add a check for enforcing minimum length for variable names
Add a check for enforcing minimum length for variable names. A default
minimum length of three characters is applied to regular variables
(including function parameters). Loop counters and exception variables
have a minimum of two characters. Additionally, the 'i', 'j' and 'k'
are accepted as legacy values.

All three sizes, as well as the list of accepted legacy loop counter
names are configurable.
2021-08-12 11:31:26 -04:00
Whisperity 39bbbc2c2a [clang-tidy][docs] Remove the entry about 'cppcoreguidelines-init-variables' from the release notes
The patch in http://reviews.llvm.org/D106431 landed in commit
4a097efe77 to the main branch.
However, this patch was also backported to upcoming release 13.0.0 in
commit 8dcdfc0de84f60b5b4af97ac5b357881af55bc6e, which makes this entry
in the release notes **NOT** a new thing for the purposes of 14.0.0.
2021-08-12 10:41:46 +02:00
Douglas Chen 2b9b5bc040 [clang-tidy] Add new case type to check variables with Hungarian notation
Add IdentifierNamingCheck::CaseType, CT_HungarianNotation, supporting
naming check with Hungarian notation.

Differential Revision: https://reviews.llvm.org/D86671
2021-08-01 15:22:17 -07:00
Liuke Gehry 4a097efe77 [clang-tidy] Fix cppcoreguidelines-init-variables by removing the enum
FixIt, and add support for initialization check of scoped enum

In C++, the enumeration is never Integer, and the enumeration condition judgment is added to avoid compiling errors when it is initialized to an integer.
Add support for initialization check of scope enum.

As the following case show, clang-tidy will give a wrong automatic fix:

    enum Color {Red, Green, Blue};
    enum class Gender {Male, Female};
    void func() {
      Color color; // Color color = 0; <--- fix bug
      Gender gender; // <--- no warning
    }

Reviewd By: aaron.ballman, whisperity

Differential Revision: http://reviews.llvm.org/D106431
2021-07-30 18:24:47 +02:00
Jesse Towner 68546c9d6f bugprone-forwarding-reference-overload: support non-type template parameters
Many concepts emulation libraries, such as the one found in Range v3, tend to
use non-type template parameters for the enable_if type expression, due to
their versatility in template functions and constructors containing variadic
template parameter packs.

Unfortunately the bugprone-forwarding-reference-overload check does not
handle non-type template parameters, as was first noted in this bug report:
https://bugs.llvm.org/show_bug.cgi?id=38081

This patch fixes this long standing issue and allows for the check to be suppressed
with the use of a non-type template parameter containing enable_if or enable_if_t in
the type expression, so long as it has a default literal value.
2021-07-29 07:01:19 -04:00
Kirill Bobyrev d8fd2146da
NFC: Change quotes from Unicode to ASCII
This was causing some problems for Python scripts that we have.

Context: https://reviews.llvm.org/D106792
2021-07-29 11:37:10 +02:00
Tom Stellard 08c766a731 Bump the trunk major version to 14
and clear the release notes.
2021-07-27 21:58:25 -07:00
Felix Berger cb4c12b611 [clang-tidy] performance-unnecessary-copy-initialization: Create option to exclude container types from triggering the check.
Add string list option of type names analagous to `AllowedTypes` which lets
users specify a list of ExcludedContainerTypes.

Types matching this list will not trigger the check when an expensive variable
is copy initialized from a const accessor method they provide, i.e.:

```
ExcludedContainerTypes = 'ExcludedType'

void foo() {
  ExcludedType<ExpensiveToCopy> Container;
  const ExpensiveToCopy NecessaryCopy = Container.get();
}
```

Even though an expensive to copy variable is copy initialized the check does not
trigger because the container type is excluded.

This is useful for container types that don't own their data, such as view types
where modification of the returned references in other places cannot be reliably
tracked, or const incorrect types.

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

Reviewed-by: ymandel
2021-07-22 16:20:20 -04:00
Whisperity 73e4b5cfa8 [clang-tidy] Add 'readability-suspicious-call-argument' check
Finds function calls where the call arguments might be provided in an
incorrect order, based on the comparison (via string metrics) of the
parameter names and the argument names against each other.

A diagnostic is emitted if an argument name is similar to a *different*
parameter than the one currently passed to, and it is sufficiently
dissimilar to the one it **is** passed to currently.

False-positive warnings from this check are useful to indicate bad
naming convention issues, even if a swap isn't necessary.
This check does not generate FixIts.

Originally implemented by @varjujan as his Master's Thesis work.
The check was subsequently taken over by @barancsuk who added type
conformity checks to silence false positive matches.
The work by @whisperity involved driving the check's review and fixing
some more bugs in the process.

Reviewed By: aaron.ballman, alexfh

Differential Revision: http://reviews.llvm.org/D20689

Co-authored-by: János Varjú <varjujanos2@gmail.com>
Co-authored-by: Lilla Barancsuk <barancsuklilla@gmail.com>
2021-07-19 10:18:09 +02:00
Whisperity 0fba450b97 [clang-tidy] Suppress reports to patternedly named parameters in 'bugprone-easily-swappable-parameters'
While the original check's purpose is to identify potentially dangerous
functions based on the parameter types (as identifier names do not mean
anything when it comes to the language rules), unfortunately, such a plain
interface check rule can be incredibly noisy. While the previous
"filtering heuristic" is able to find many similar usages, there is an entire
class of parameters that should not be warned about very easily mixed by that
check: parameters that have a name and their name follows a pattern,
e.g. `text1, text2, text3, ...`.`

This patch implements a simple, but powerful rule, that allows us to detect
such cases and ensure that no warnings are emitted for parameter sequences that
follow a pattern, even if their types allow for them to be potentially mixed at a call site.

Given a threshold `k`, warnings about two parameters are filtered from the
result set if the names of the parameters are either prefixes or suffixes of
each other, with at most k letters difference on the non-common end.
(Assuming that the names themselves are at least `k` long.)

 - The above `text1, text2` is an example of this. (Live finding from Xerces.)
 - `LHS` and `RHS` are also fitting the bill here. (Live finding from... virtually any project.)
 - So does `Qmat, Tmat, Rmat`. (Live finding from I think OpenCV.)

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D97297
2021-06-28 10:49:37 +02:00
Whisperity b9ece03461 [clang-tidy] Suppress reports to similarly used parameters in 'bugprone-easily-swappable-parameters'
There are several types of functions and various reasons why some
"swappable parameters" cannot be fixed with changing the parameters' types, etc.
The most common example might be int `min(int a, int b)`... no matter what you
do, the two parameters must remain the same type.

The **filtering heuristic** implemented in this patch deals with trying to find
such functions during the modelling and building of the swappable parameter
range.
If the parameter currently scrutinised matches either of the predicates below,
it will be regarded as **not swappable** even if the type of the parameter
matches.

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D78652
2021-06-28 10:49:37 +02:00
Whisperity e33d047883 [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions
Adds a relaxation option ModelImplicitConversions which will make the check
report for cases where parameters refer to types that are implicitly
convertible to one another.

Example:

    struct IntBox { IntBox(int); operator int(); };
    void foo(int i, double d, IntBox ib) {}

Implicit conversions are the last to model in the set of things that are
reasons for the possibility of a function being called the wrong way which is
not always immediately apparent when looking at the function (signature or
call).

Reviewed By: aaron.ballman, martong

Differential Revision: http://reviews.llvm.org/D75041
2021-06-28 10:49:37 +02:00
Whisperity 961e9e6af6 [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with optionally considering differently qualified types mixable
Adds a relaxation option QualifiersMix which will make the check report for
cases where parameters refer to the same type if they only differ in qualifiers.

This makes cases, such as the following, not warned about by default, produce
a warning.

    void* memcpy(void* dst, const void* src, unsigned size) {}

However, unless people meticulously const their local variables, unfortunately,
even such a function carry a potential swap:

    T* obj = new T; // Not const!!!
    void* buf = malloc(sizeof(T));

    memcpy(obj, buf, sizeof(T));
    //     ^~~  ^~~ accidental swap here, even though the interface "specified" a const.

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D96355
2021-06-28 10:49:37 +02:00
Whisperity 26d864b44b [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with `typedef` and `const &` diagnostics
The base patch only deals with strict (canonical) type equality, which is
merely a subset of all the dangerous function interfaces that we intend to
find.
In addition, in the base patch, canonical type equivalence is not diagnosed in
a way that is immediately apparent to the user.

This patch extends the check with two features:

 * Proper typedef diagnostics and explanations to the user.
 * "Reference bind power" matching.

Case 2 is a necessary addition because in every case someone encounters a
function `f(T t, const T& tr)`, any expression that might be passed to either
can be passed to both. Thus, such adjacent parameter sequences should be
matched.

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D95736
2021-06-28 10:49:37 +02:00
Whisperity 499e39c598 [clang-tidy] Add 'bugprone-easily-swappable-parameters' check
Finds function definitions where parameters of convertible types follow
each other directly, making call sites prone to calling the function
with swapped (or badly ordered) arguments.

Such constructs are usually the result of inefficient design and lack of
exploitation of strong type capabilities that are possible in the
language.

This check finds and flags **function definitions** and **not** call
sites!

Reviewed By: aaron.ballman, alexfh

Differential Revision: http://reviews.llvm.org/D69560
2021-06-28 10:49:37 +02:00
Guillaume Chatelet 89c41c335d [clang-tidy] Allow disabling integer narrowing conversions for cppcoreguidelines-narrowing-conversions
Differential Revision: https://reviews.llvm.org/D104018
2021-06-10 12:41:57 +00:00
Stephen Concannon 211761332e [clang-tidy] Allow opt-in or out of some commonly occuring patterns in NarrowingConversionsCheck.
Within clang-tidy's NarrowingConversionsCheck.
* Allow opt-out of some common occurring patterns, such as:
  - Implicit casts between types of equivalent bit widths.
  - Implicit casts occurring from the return of a ::size() method.
  - Implicit casts on size_type and difference_type.
* Allow opt-in of errors within template instantiations.

This will help projects adopt these guidelines iteratively.
Developed in conjunction with Yitzhak Mandelbaum (ymandel).

Patch by Stephen Concannon!

Differential Revision: https://reviews.llvm.org/D99543
2021-05-12 20:51:25 +02:00
Malcolm Parsons 5389a05836 [docs] Fix documentation for bugprone-dangling-handle
string_view isn't experimental anymore.
This check has always handled both forms.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D102313
2021-05-12 17:20:15 +01:00
Frank Derry Wanye 83af66e18e new altera ID dependent backward branch check
This lint check is a part of the FLOCL (FPGA Linters for OpenCL) project
out of the Synergy Lab at Virginia Tech.

FLOCL is a set of lint checks aimed at FPGA developers who write code
in OpenCL.

The altera ID dependent backward branch lint check finds ID dependent
variables and fields used within loops, and warns of their usage. Using
these variables in loops can lead to performance degradation.
2021-05-06 17:01:39 -04:00
Balázs Kéri 530456caf9 [clang-tidy] Add new check 'bugprone-unhandled-exception-at-new'.
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D97196
2021-04-14 09:33:11 +02:00
Roman Lebedev 46b8ea2fff
[clang-tidy] Add check for implicit widening of multiplication result
Overflows are never fun.
In most cases (in most of the code), they are rare,
because usually you e.g. don't have as many elements.

However, it's exceptionally easy to fall into this pitfail
in code that deals with images, because, assuming 4-channel 32-bit FP data,
you need *just* ~269 megapixel image to case an overflow
when computing at least the total byte count.

In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs:
* https://github.com/darktable-org/darktable/pull/7740
* https://github.com/darktable-org/darktable/pull/7419
* eea1989f2c
* 70626dd95b
* https://github.com/darktable-org/darktable/pull/670
* 38c69fb1b2

and yet they clearly keep resurfacing still.

It would be immensely helpful to have a diagnostic for those patterns,
which is what this change proposes.

Currently, i only diagnose the most obvious case, where multiplication
is directly widened with no other expressions inbetween,
(i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`)
however that might be worth relaxing later.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D93822
2021-04-13 21:41:22 +03:00
Nathan James 27dfcd978e
[clang-tidy] Add <utility> include to misc-uniqueptr-reset-release
This is the only remaining check that creates `std::move` includes but doesn't add a `<utility>` include.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D97683
2021-04-12 23:32:15 +01:00
Richard Smith fc1e146e44 Fix documentation typo. 2021-04-12 11:39:08 -07:00
Alexander Kornienko 8883cb3e40 Fix nits. 2021-04-12 18:46:13 +02:00
Jens Massberg 8a944d82cd [clang-tidy] Add option to ignore macros in readability-function-cognitive-complexity check.
(this was originally part of https://reviews.llvm.org/D96281 and has been split off into its own patch)

If a macro is used within a function, the code inside the macro
doesn't make the code less readable. Instead, for a reader a macro is
more like a function that is called. Thus the code inside a macro
shouldn't increase the complexity of the function in which it is called.
Thus the flag 'IgnoreMacros' is added. If set to 'true' code inside
macros isn't considered during analysis.

This isn't perfect, as now the code of a macro isn't considered at all,
even if it has a high cognitive complexity itself. It might be better if
a macro is considered in the analysis like a function and gets its own
cognitive complexity. Implementing such an analysis seems to be very
complex (if possible at all with the given AST), so we give the user the
option to either ignore macros completely or to let the expanded code
count to the calling function's complexity.

See the code example from vgeof (originally added as note in https://reviews.llvm.org/D96281)

   bool doStuff(myClass* objectPtr){
         if(objectPtr == nullptr){
             LOG_WARNING("empty object");
             return false;
         }
         if(objectPtr->getAttribute() == nullptr){
             LOG_WARNING("empty object");
             return false;
         }
         use(objectPtr->getAttribute());
     }

The LOG_WARNING macro itself might have a high complexity, but it do not make the
the function more complex to understand like e.g. a 'printf'.

By default 'IgnoreMacros' is set to 'false', which is the original behavior of the check.

Reviewed By: lebedev.ri, alexfh

Differential Revision: https://reviews.llvm.org/D98070
2021-04-12 18:46:12 +02:00
Whisperity 3b677b81ce [libtooling][clang-tidy] Fix diagnostics not highlighting fed SourceRanges
Fixes bug http://bugs.llvm.org/show_bug.cgi?id=49000.

This patch allows Clang-Tidy checks to do

    diag(X->getLocation(), "text") << Y->getSourceRange();

and get the highlight of `Y` as expected:

    warning: text [blah-blah]
        xxx(something)
        ^   ~~~~~~~~~

Reviewed-By: aaron.ballman, njames93

Differential Revision: http://reviews.llvm.org/D98635
2021-04-10 16:43:44 +02:00
Vince Bridgers c060945b23 [docs] Update documentation for bugprone-misplaced-widening-cast
The default setting for CheckImplicitCasts was changed in
https://reviews.llvm.org/D32164 but the documentation was not updated.
This simple change just syncs the documentation with the behavior of
that checker.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D99991
2021-04-06 16:18:50 -05:00
Felix Berger ddebed8e97 [clang-tidy] performance-* checks: Match AllowedTypes against qualified type names when they contain "::".
This allows users to be more precise and exclude a type in a specific namespace
from triggering the check instead of excluding all types with the same
unqualified name.

This change should not interfere with correctly configured clang-tidy setups
since an AllowedType with "::" would never match.

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

Reviewed-by: ymandel, hokein
2021-04-06 15:41:35 -04:00
Frank Derry Wanye 5a87f81fe9 new altera unroll loops check
This lint check is a part of the FLOCL (FPGA Linters for OpenCL)
project out of the Synergy Lab at Virginia Tech.

FLOCL is a set of lint checks aimed at FPGA developers who write code
in OpenCL.

The altera unroll loops check finds inner loops that have not been
unrolled, as well as fully-unrolled loops that should be partially
unrolled due to unknown loop bounds or a large number of loop
iterations.

Based on the Altera SDK for OpenCL: Best Practices Guide.
2021-03-22 13:09:53 -04:00