Commit Graph

2297 Commits

Author SHA1 Message Date
Sockke a7f8aea714 [clang-tidy] Fix wrong FixIt in performance-move-const-arg
There are incorrect Fixit and missing warnings:
case :
A trivially-copyable object wrapped by std::move is passed to the function with rvalue reference parameters. Removing std::move will cause compilation errors.
```
void showInt(int&&) {}
void testInt() {
    int a = 10;
    // expect: warning + nofix
    showInt(std::move(a));  // showInt(a) <--- wrong fix
}

struct Tmp {};
void showTmp(Tmp&&) {}
void testTmp() {
    Tmp t;
    // expect: warning + nofix
    showTmp(std::move(t));  // showTmp(t) <--- wrong fix
}
```

Reviewed By: aaron.ballman, Quuxplusone

Differential Revision: https://reviews.llvm.org/D107450
2022-01-21 14:23:52 +08:00
Fabian Wolff d3b188a2d7 [clang-tidy] Include constructor initializers in `bugprone-exception-escape` check
Fixes PR#52435.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D113507
2022-01-21 00:53:57 +01:00
CJ Johnson a568411444 [clang-tidy] Update bugprone-stringview-nullptr to consistently prefer the empty string when passing arguments to constructors/functions
Previously, function(nullptr) would have been fixed with function({}). This unfortunately can change overload resolution and even become ambiguous. T(nullptr) was already being fixed with T(""), so this change just brings function calls in line with that.

Differential Revision: https://reviews.llvm.org/D117840
2022-01-20 18:08:40 -05:00
Richard d83ecd77cc [clang-tidy] Narrow cppguidelines-macro-usage to actual constants
Previously, any macro that didn't look like a varargs macro
or a function style macro was reported with a warning that
it should be replaced with a constexpr const declaration.
This is only reasonable when the macro body contains constants
and not expansions like ",", "[[noreturn]]", "__declspec(xxx)",
etc.

So instead of always issuing a warning about every macro that
doesn't look like a varargs or function style macro, examine the
tokens in the macro and only warn about the macro if it contains
only comment and constant tokens.

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

Fixes #39945
2022-01-19 12:28:22 -07:00
Fabian Wolff f7b7138a62 [clang-tidy] Make `readability-container-data-pointer` more robust
Fixes PR#52245. I've also added a few test cases beyond PR#52245 that would also fail with the current implementation, which is quite brittle in many respects (e.g. it uses the `hasDescendant()` matcher to find the container that is being accessed, which is very easy to trick, as in the example in PR#52245).

I have not been able to reproduce the second issue mentioned in PR#52245 (namely that using the `data()` member function is suggested even for containers that don't have it), but I've added a test case for it to be sure.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D113863
2022-01-18 21:08:59 +01:00
Fabian Wolff 2cd2accc61 [clang-tidy] Fix false positives involving type aliases in `misc-unconventional-assign-operator` check
clang-tidy currently reports false positives even for simple cases such as:
```
struct S {
    using X = S;
    X &operator=(const X&) { return *this; }
};
```
This is due to the fact that the `misc-unconventional-assign-operator` check fails to look at the //canonical// types. This patch fixes this behavior.

Reviewed By: aaron.ballman, mizvekov

Differential Revision: https://reviews.llvm.org/D114197
2022-01-17 21:16:17 +01:00
Fabian Wolff 42bc3275d3 [clang-tidy] Fix `readability-redundant-declaration` false positive for template friend declaration
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=48086 | PR#48086 ]]. The problem is that the current matcher uses `hasParent()` to detect friend declarations, but for a template friend declaration, the immediate parent of the `FunctionDecl` is a `FunctionTemplateDecl`, not the `FriendDecl`. Therefore, I have replaced the matcher with `hasAncestor()`.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D114299
2022-01-17 20:50:32 +01:00
CJ Johnson 7e29da875c Add support for return values in bugprone-stringview-nullptr
bugprone-stringview-nullptr was not initially written with tests for return statements. After landing the check, the thought crossed my mind to add such tests. After writing them, I realized they needed additional handling in the matchers.

Differential Revision: https://reviews.llvm.org/D115121
2022-01-12 16:53:13 -05:00
Richard fff59f4817 [clang-tidy] Improve modernize-redundant-void-arg to recognize macro uses
Sometimes a macro invocation will look like an argument list
declaration.  Improve the check to detect this situation and not
try to modify the macro invocation.

Thanks to Nathan James for the fix.

- Ignore implicit typedefs (e.g. compiler builtins)
- Improve lexing state machine to locate void argument tokens
- Add additional return_t() macro tests
- clang-format control in the test case file
- remove braces around single statements per LLVM style guide

Fixes #43791

Differential Revision: https://reviews.llvm.org/D116425
2022-01-12 13:51:50 -07:00
serge-sans-paille 35cca45b09 Misleading bidirectional detection
This patch implements detection of incomplete bidirectional sequence withing
comments and string literals within clang-tidy.

It detects the bidi part of https://www.trojansource.codes/trojan-source.pdf

Differential Revision: https://reviews.llvm.org/D112913
2022-01-12 11:38:36 +01:00
Elvis Stansvik 36af073342 Accept string literal decay in conditional operator
The cppcoreguidelines-pro-bounds-array-to-pointer-decay check currently
accepts:

const char *b = i ? "foo" : "foobar";

but not

const char *a = i ? "foo" : "bar";

This is because the AST is slightly different in the latter case (see
https://godbolt.org/z/MkHVvs).

This eliminates the inconsistency by making it accept the latter form
as well.

Fixes https://github.com/llvm/llvm-project/issues/31155.
2022-01-11 15:05:30 -05:00
Richard a2c33b0ec9 [clang-tidy] Refactor: Extract Class CheckRunner on check_clang_tidy.py
Break up the huge function by extracting a class, storing intermediate
state as class members and breaking up the big function into a group
of class methods all at the same level of abstraction.

Differential Revision: https://reviews.llvm.org/D56343
2022-01-10 15:44:12 -07:00
Logan Smith 988c3f5f96 [clang-tidy] Fix RenamerClangTidyChecks suggesting invalid macro identifiers
This behavior was fixed for regular identifiers in
9f3edc323a, but the same fix was not applied to
macro fixits. This addresses https://github.com/llvm/llvm-project/issues/52895.

Differential Revision: https://reviews.llvm.org/D116824
2022-01-10 10:35:04 -08:00
Carlos Galvez 670de10f9d Disable clang-tidy warnings from system macros
Currently, it's inconsistent that warnings are disabled if they
come from system headers, unless they come from macros.
Typically a user cannot act upon these warnings coming from
system macros, so clang-tidy should ignore them unless the
user specifically requests warnings from system headers
via the corresponding configuration.

This change broke the ProTypeVarargCheck check, because it
was checking for the usage of va_arg indirectly, expanding it
(it's a system macro) to detect the usage of __builtin_va_arg.
The check has been fixed by checking directly what the rule
is about: "do not use va_arg", by adding a PP callback that
checks if any macro with name "va_arg" is expanded. The old
AST matcher is still kept for compatibility with Windows.

Add unit test that ensures warnings from macros are disabled
when not using the -system-headers flag. Document the change
in the Release Notes.

Differential Revision: https://reviews.llvm.org/D116378
2022-01-06 20:27:28 +00:00
Clement Courbet ed8ff29aa6 [clang-tidy] Fix false positive in modernize-pass-by-value
The check should not trigger on lvalue/rvalue overload pairs:

```
struct S {
  S(const A& a) : a(a) {}
  S(A&& a) : a(std::move(a)) {}

  A a;
}
```

Differential Revision: https://reviews.llvm.org/D116535
2022-01-05 14:33:40 +01:00
Oleg Smolsky 051847cfec Improve the 'modernize-use-default-member-init'
We want to deal with non-default constructors that just happen to
contain constant initializers. There was already a negative test case,
it is now a positive one. We find and refactor this case:

struct PositiveNotDefaultInt {
  PositiveNotDefaultInt(int) : i(7) {}
  int i;
};
2022-01-04 07:27:02 -05:00
Ivan Gerasimov fd8fc5e8d9 [clang-tidy] abseil-string-find-startswith: detect `s.rfind(z, 0) == 0`
Suggest converting `std::string::rfind()` calls to `absl::StartsWith()`
where possible.
2021-12-22 16:45:51 +01:00
Paul Altin 9198d04c06 Allow disabling integer to floating-point narrowing conversions for cppcoreguidelines-narrowing-conversions
This change adds an option to disable warnings from the
cppcoreguidelines-narrowing-conversions check on integer to floating-
point conversions which may be narrowing.

An example of a case where this might be useful:
```
std::vector<double> v = {1, 2, 3, 4};
double mean = std::accumulate(v.cbegin(), v.cend(), 0.0) / v.size();
```
The conversion from std::size_t to double is technically narrowing on
64-bit systems, but v almost certainly does not have enough elements
for this to be a problem.

This option would allow the cppcoreguidelines-narrowing-conversions
check to be enabled on codebases which might otherwise turn it off
because of cases like the above.
2021-12-16 08:24:09 -05:00
Markus Böck b7d55771ce [clang-tidy][#51939] Exempt placement-new expressions from 'bugprone-throw-keyword-missing'
The purpose of this checker is to flag a missing throw keyword, and does so by checking for the construction of an exception class that is then unused.
This works great except that placement new expressions are also flagged as those lead to the construction of an object as well, even though they are not temporary (as that is dependent on the storage).
This patch fixes the issue by exempting the match if it is within a placement-new.

Fixes https://github.com/llvm/llvm-project/issues/51939

Differential Revision: https://reviews.llvm.org/D115576
2021-12-15 16:59:14 +01:00
CJ Johnson a1968d5341 Prevent abseil-cleanup-ctad check from stomping on surrounding context
This change applies two fixes to the abseil-cleanup-ctad check. It uses hasSingleDecl() to ensure only declStmt()s with one varDecl() are matched (leaving compount declStmt()s unchanged). It also addresses a bug in the handling of comments that surround the absl::MakeCleanup() calls by switching to the callArgs() combinator from Clang Transformer.

Reviewed By: ymandel

Differential Revision: https://reviews.llvm.org/D115452
2021-12-09 17:41:12 +00:00
Adrian Vogelsgesang 5d3b8956e8 Don't offer partial fix-its for `modernize-pass-by-value`
This commit improves the fix-its of modernize-pass-by-value by
no longer proposing partial fixes. In the presence of using/typedef,
we failed to rewrite the function signature but still adjusted the
function body. This led to incorrect, partial fix-its. Instead, the
check now simply doesn't offer any fixes at all in such a situation.
2021-12-08 13:31:30 -05:00
Aaron Ballman 6c75ab5f66 Introduce _BitInt, deprecate _ExtInt
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:

* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.

I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.
2021-12-06 12:52:01 -05:00
Vy Nguyen aba8f320cc [clang-tidy][objc] Finds and fixes improper usages of XCTAssertEquals and XCTAssertNotEquals.
Using XCTAssertEqual on NSString* objects is almost always  wrong.

Unfortunately, we have seen a lot of tests doing this and reyling on pointer equality for strings with the same values (which happens to work sometimes - depending on the linker, but this assumption is not guaranteed by the language)

These fixes would make tests less brittle.

Differential Revision: https://reviews.llvm.org/D114975
2021-12-02 18:32:16 -05:00
CJ Johnson 6a9487df73 Add new clang-tidy check for string_view(nullptr)
Checks for various ways that the `const CharT*` constructor of `std::basic_string_view` can be passed a null argument and replaces them with the default constructor in most cases. For the comparison operators, braced initializer list does not compile so instead a call to `.empty()` or the empty string literal are used, where appropriate.

This prevents code from invoking behavior which is unconditionally undefined. The single-argument `const CharT*` constructor does not check for the null case before dereferencing its input. The standard is slated to add an explicitly-deleted overload to catch some of these cases: wg21.link/p2166

https://reviews.llvm.org/D114823 is a companion change to prevent duplicate warnings from the `bugprone-string-constructor` check.

Reviewed By: ymandel

Differential Revision: https://reviews.llvm.org/D113148
2021-12-02 13:25:28 +00:00
Fabian Wolff 987a21522f [clang-tidy] Use `hasCanonicalType()` matcher in `bugprone-unused-raii` check
Fixes PR#52217.

Reviewed By: simon.giesecke

Differential Revision: https://reviews.llvm.org/D113429
2021-12-02 01:53:12 +01:00
Fabian Wolff 844a8d3cec Fix false positives in `fuchsia-trailing-return` check involving deduction guides
Fixes PR#47614. Deduction guides, implicit or user-defined, look like
function declarations in the AST. They aren't really functions, though,
and they always have a trailing return type, so it doesn't make sense
to issue this warning for them.
2021-12-01 15:28:01 -05:00
Michael Jones 155f5a6dac [libc][clang-tidy] fix namespace check for externals
Up until now, all references to `errno` were marked with `NOLINT`, since
it was technically calling an external function. This fixes the lint
rules so that `errno`, as well as `malloc`, `calloc`, `realloc`, and
`free` are all allowed to be called as external functions. All of the
relevant `NOLINT` comments have been removed, and the documentation has
been updated.

Reviewed By: sivachandra, lntue, aaron.ballman

Differential Revision: https://reviews.llvm.org/D113946
2021-11-30 11:44:24 -08:00
Carlos Galvez 5bbe50148f [clang-tidy] Warn on functional C-style casts
The google-readability-casting check is meant to be on par
with cpplint's readability/casting check, according to the
documentation. However it currently does not diagnose
functional casts, like:

float x = 1.5F;
int y = int(x);

This is detected by cpplint, however, and the guidelines
are clear that such a cast is only allowed when the type
is a class type (constructor call):

> You may use cast formats like `T(x)` only when `T` is a class type.

Therefore, update the clang-tidy check to check this
case.

Differential Revision: https://reviews.llvm.org/D114427
2021-11-30 07:31:17 +00:00
Balazs Benics a8120a7711 [clang-tidy] Ignore narrowing conversions in case of bitfields
Bitfields are special. Due to integral promotion [conv.prom/5] bitfield
member access expressions are frequently wrapped by an implicit cast to
`int` if that type can represent all the values of the bitfield.

Consider these examples:
  struct SmallBitfield { unsigned int id : 4; };
  x.id & 1;             (case-1)
  x.id & 1u;            (case-2)
  x.id << 1u;           (case-3)
  (unsigned)x.id << 1;  (case-4)

Due to the promotion rules, we would get a warning for case-1. It's
debatable how useful this is, but the user at least has a convenient way
of //fixing// it by adding the `u` unsigned-suffix to the literal as
demonstrated by case-2. However, this won't work for shift operators like
the one in case-3. In case of a normal binary operator, both operands
contribute to the result type. However, the type of the shift expression is
the promoted type of the left operand. One could still suppress this
superfluous warning by explicitly casting the bitfield member access as
case-4 demonstrates, but why? The compiler already knew that the value from
the member access should safely fit into an `int`, why do we have this
warning in the first place? So, hereby we suppress this specific scenario,
when a bitfield's value is implicitly cast to int (likely due to integral
promotion).

Note that the bitshift operation might invoke unspecified/undefined
behavior, but that's another topic, this checker is about detecting
conversion-related defects.

Example AST for `x.id << 1`:
  BinaryOperator 'int' '<<'
  |-ImplicitCastExpr 'int' <IntegralCast>
  | `-ImplicitCastExpr 'unsigned int' <LValueToRValue>
  |   `-MemberExpr 'unsigned int' lvalue bitfield .id
  |     `-DeclRefExpr 'SmallBitfield' lvalue ParmVar 'x' 'SmallBitfield'
  `-IntegerLiteral 'int' 1

Reviewed By: courbet

Differential Revision: https://reviews.llvm.org/D114105
2021-11-29 09:56:43 +01:00
Balazs Benics e1d0673aee [clang-tidy] Fix crashing altera-struct-pack-align on invalid RecordDecls
Reviewed-By: martong

Differential Revision: https://reviews.llvm.org/D114256
2021-11-29 09:56:43 +01:00
Balazs Benics 0540485436 [libtooling][clang-tidy] Fix crashing on rendering invalid SourceRanges
Invalid SourceRanges can occur generally if the code does not compile,
thus we expect clang error diagnostics.
Unlike `clang`, `clang-tidy` did not swallow invalid source ranges, but
tried to highlight them, and blow various assertions.

The following two examples produce invalid source ranges, but this is
not a complete list:

  void test(x); // error: unknown type name 'x'
  struct Foo {
    member; // error: C++ requires a type specifier for all declarations
  };

Thanks @whisperity helping me fix this.

Reviewed-By: xazax.hun

Differential Revision: https://reviews.llvm.org/D114254
2021-11-29 09:56:43 +01:00
Balazs Benics 0685e83534 Fix cppcoreguidelines-virtual-base-class-destructor in macros
The `cppcoreguidelines-virtual-base-class-destructor` checker crashed on
this example:

  #define DECLARE(CLASS) \
  class CLASS {          \
  protected:             \
    virtual ~CLASS();    \
  }
  DECLARE(Foo); // no-crash

The checker will hit the following assertion:

  clang-tidy: llvm/include/llvm/ADT/Optional.h:196: T &llvm::optional_detail::OptionalStorage<clang::Token, true>::getValue() & [T = clang::Token]: Assertion `hasVal' failed."

It turns out, `Lexer::findNextToken()` returned `llvm::None` within the
`getVirtualKeywordRange()` function when the `VirtualEndLoc`
SourceLocation represents a macro expansion.
To prevent this from happening, I decided to propagate the `llvm::None`
further up and only create the removal of `virtual` if the
`getVirtualKeywordRange()` succeeds.

I considered an alternative fix for this issue:
I could have checked the `Destructor.getLocation().isMacroID()` before
doing any Fixit calculation inside the `check()` function.
In contrast to this approach my patch will preserve the diagnostics and
drop the fixits only if it would have crashed.

Reviewed By: whisperity

Differential Revision: https://reviews.llvm.org/D113558
2021-11-29 09:56:43 +01:00
Quinn Pham c3dc6b081d [NFC][clang-tools-extra] Inclusive language: replace master with main
[NFC] As part of using inclusive language within the llvm project, this patch
replaces master with main in `SubModule2.h`.

Reviewed By: sammccall

Differential Revision: https://reviews.llvm.org/D114100
2021-11-25 11:01:16 -06:00
Clement Courbet ba4411e7c6 [clang-tidy] performance-unnecessary-copy-initialization: Fix false negative.
`isConstRefReturningMethodCall` should be considering
`CXXOperatorCallExpr` in addition to `CXXMemberCallExpr`. Clang considers
these to be distinct (`CXXOperatorCallExpr` derives from `CallExpr`, not
`CXXMemberCallExpr`), but we don't care in the context of this
check.

This is important because of
`std::vector<Expensive>::operator[](size_t) const`.

Differential Revision: https://reviews.llvm.org/D114249
2021-11-24 08:07:21 +01:00
Felix Berger fefe20b993 [clang-tidy] performance-unnecessary-copy-initialization: Correctly match the type name of the thisPointertype.
The matching did not work correctly for pointer and reference types.

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

Reviewed-by: courbet
2021-11-20 15:13:41 -05:00
Fabian Wolff 6259016361 [clang-tidy] Fix false positive in readability-identifier-naming check involving override attribute
Overriding methods should not get a readability-identifier-naming
warning because the issue can only be fixed in the base class; but the
current check for whether a method is overriding does not take the
override attribute into account.

Differential Revision: https://reviews.llvm.org/D113830
2021-11-19 22:31:11 +13:00
Matt Beardsley 85e03cb7eb [clang-tidy] fix debug-only test failure
The clang-tidy/infrastructure/pr37091.cpp test inherits the top-level .clang-tidy configuration because it doesn't specify its own checks. It'd be a more stable test if it operates independently of the top-level .clang-tidy settings.

I've made the clang-tidy/infrastructure/pr37091.cpp test independent of the top-level .clang-tidy (picked an arbitrary check that I saw another clang-tidy/infrastructure test was also using: clang-tidy/infrastructure/temporaries.cpp)

Reviewed By: kbobyrev

Differential Revision: https://reviews.llvm.org/D114034
2021-11-19 10:19:07 +01:00
Fabian Wolff 738e7f1231 Fix false positive in `bugprone-throw-keyword-missing` check
Fixes PR#52400. The tests for bugprone-throw-keyword-missing actually
already contain exceptions as class members, but not as members with
initializers, which was probably just an oversight.
2021-11-16 07:09:17 -05:00
Matheus Izvekov c9e46219f3
[clang] retain type sugar in auto / template argument deduction
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith, #libc, ldionne

Differential Revision: https://reviews.llvm.org/D110216
2021-11-15 23:07:45 +01:00
Kristóf Umann 29a8d45c5a [clang-tidy] Fix a crash in modernize-loop-convert around conversion operators
modernize-loop-convert checks and fixes when a loop that iterates over the
elements of a container can be rewritten from a for(...; ...; ...) style into
the "new" C++11 for-range format. For that, it needs to parse the elements of
that loop, like its init-statement, such as ItType it = cont.begin().
modernize-loop-convert checks whether the loop variable is initialized by a
begin() member function.

When an iterator is initialized with a conversion operator (e.g. for
(const_iterator it = non_const_container.begin(); ...), attempts to retrieve the
name of the initializer expression resulted in an assert, as conversion
operators don't have a valid IdentifierInfo.

I fixed this by making digThroughConstructors dig through conversion operators
as well.

Differential Revision: https://reviews.llvm.org/D113201
2021-11-15 13:11:29 +01:00
Fabian Wolff c3e3c76209 [clang-tidy] Fix `bugprone-use-after-move` check to also consider moves in constructor initializers
Fixes PR#38187. Constructors are actually already checked,
but only as functions, i.e. the check only looks at the
constructor body and not at the initializers, which misses
the (common) case where constructor parameters are moved
as part of an initializer expression.

One remaining false negative is when both the move //and//
the use-after-move occur in constructor initializers.
This is a lot more difficult to handle, though, because
the `bugprone-use-after-move` check is currently based on
a CFG that only takes the body into account, not the
initializers, so e.g. initialization order would have to
manually be considered. I will file a follow-up issue for
this once PR#38187 is closed.

Reviewed By: carlosgalvezp

Differential Revision: https://reviews.llvm.org/D113708
2021-11-15 07:41:35 +00:00
Matheus Izvekov 6438a52df1
Revert "[clang] retain type sugar in auto / template argument deduction"
This reverts commit 4d8fff477e.
2021-11-15 00:29:05 +01:00
Matheus Izvekov 4d8fff477e
[clang] retain type sugar in auto / template argument deduction
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D110216
2021-11-13 03:35:22 +01:00
Adrian Kuegel 1d7fdbbc18 Revert "[clang] retain type sugar in auto / template argument deduction"
This reverts commit 9b6036deed.
Breaks two libc++ tests.
2021-11-12 13:21:59 +01:00
Matheus Izvekov 9b6036deed
[clang] retain type sugar in auto / template argument deduction
This implements the following changes:
* AutoType retains sugared deduced-as-type.
* Template argument deduction machinery analyses the sugared type all the way
down. It would previously lose the sugar on first recursion.
* Undeduced AutoType will be properly canonicalized, including the constraint
template arguments.
* Remove the decltype node created from the decltype(auto) deduction.

As a result, we start seeing sugared types in a lot more test cases,
including some which showed very unfriendly `type-parameter-*-*` types.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D110216
2021-11-12 01:16:31 +01:00
Adrian Vogelsgesang 8188484daa [clang-apply-replacements] Correctly handle relative paths
The fixes from the YAML file can refer to relative paths.
Those relative paths are meant to be resolved relative to the
corresponding `build directory`.
However, `clang-apply-replacements` currently interprets all
paths relative to its own working directory. This causes issues,
e.g., when `clang-apply-replacements` is run from outside of
the original build directory.

This commit adjusts `clang-apply-replacements` to take the build
directory into account when resolving relative file paths.

Reviewed By: ymandel

Differential Revision: https://reviews.llvm.org/D112647
2021-11-11 18:28:43 +00:00
serge-sans-paille 26d195d8b3 Replace include by forward declaration in test case
This should fix the remaining buildbot issue for the misleading identifier
detection pass.

Differential Revision: https://reviews.llvm.org/D112914
2021-11-10 20:34:05 +01:00
serge-sans-paille a35efc4dcb Misleading unicode identifier detection pass
Detect when an identifier contains some Right-To-Left characters.
This pass relates to https://trojansource.codes/

Example of misleading source:

    short int א = (short int)0;
    short int ג = (short int)12345;

    int main() {
      int א = ג; // a local variable, set to zero?
      printf("ג is %d\n", ג);
      printf("א is %d\n", א);
    }

This is a recommit of 299aa4dfa1 with missing
option registration fixed.

Differential Revision: https://reviews.llvm.org/D112914
2021-11-10 10:21:27 +01:00
serge-sans-paille c178ada3c3 Revert "Misleading unicode identifier detection pass"
This reverts commit 7f92a1a84b.

It triggers an assert, see http://45.33.8.238/linux/60293/step_9.txt

"AST/Decl.h:277: llvm::StringRef clang::NamedDecl::getName() const: Assertion `Name.isIdentifier() && "Name is not a simple identifier"' failed."
2021-11-09 22:40:18 +01:00
serge-sans-paille 7f92a1a84b Misleading unicode identifier detection pass
Detect when an identifier contains some Right-To-Left characters.
This pass relates to https://trojansource.codes/

This is a recommit of 299aa4dfa1 with missing
option registration fixed.

Differential Revision: https://reviews.llvm.org/D112914
2021-11-09 21:46:35 +01:00