Commit Graph

5663 Commits

Author SHA1 Message Date
Steffen Larsen ead1690d31 Allow parameter pack expansions and initializer lists in annotate attribute
These changes make the Clang parser recognize expression parameter pack
expansion and initializer lists in attribute arguments. Because
expression parameter pack expansion requires additional handling while
creating and instantiating templates, the support for them must be
explicitly supported through the AcceptsExprPack flag.

Handling expression pack expansions may require a delay to when the
arguments of an attribute are correctly populated. To this end,
attributes that are set to accept these - through setting the
AcceptsExprPack flag - will automatically have an additional variadic
expression argument member named DelayedArgs. This member is not
exposed the same way other arguments are but is set through the new
CreateWithDelayedArgs creator function generated for applicable
attributes.

To illustrate how to implement support for expression pack expansion
support, clang::annotate is made to support pack expansions. This is
done by making handleAnnotationAttr delay setting the actual attribute
arguments until after template instantiation if it was unable to
populate the arguments due to dependencies in the parsed expressions.
2022-02-08 13:38:07 -05:00
Corentin Jabot c151225096 [C++2b] Implement multidimentional subscript operator
Implement P2128R6 in C++23 mode.

Unlike GCC's implementation, this doesn't try to recover when a user
meant to use a comma expression.

Because the syntax changes meaning in C++23, the patch is *NOT*
implemented as an extension. Instead, declaring an array with not
exactly 1 parameter is an error in older languages modes. There is an
off-by-default extension warning in C++23 mode.

Unlike the standard, we supports default arguments;

Ie, we assume, based on conversations in WG21, that the proposed
resolution to CWG2507 will be accepted.

We allow arrays OpenMP sections and C++23 multidimensional array to
coexist:

[a , b] multi dimensional array
[a : b] open mp section
[a, b: c] // error

The rest of the patch is relatively straight forward: we take care to
support an arbitrary number of arguments everywhere.
2022-02-08 12:10:47 -05:00
Simon Pilgrim c00db97159 [Clang] Add elementwise saturated add/sub builtins
This patch implements `__builtin_elementwise_add_sat` and `__builtin_elementwise_sub_sat` builtins.

These map to the add/sub saturated math intrinsics described here:
https://llvm.org/docs/LangRef.html#saturation-arithmetic-intrinsics

With this in place we should then be able to replace the x86 SSE adds/subs intrinsics with these generic variants - it looks like other targets should be able to use these as well (arm/aarch64/webassembly all have similar examples in cgbuiltin).

Differential Revision: https://reviews.llvm.org/D117898
2022-02-08 11:22:01 +00:00
Chuanqi Xu e39ba04617 [C++20] [Coroutines] Warning for always_inline coroutine
See the discussion in https://reviews.llvm.org/D100282. The coroutine
marked always inline might not be inlined properly in current compiler
support. Since the coroutine would be splitted into pieces. And the call
to resume() and destroy() functions might be indirect call. Also the
ramp function wouldn't get inlined under O0 due to pipeline ordering
problems. It might be different to what users expects to. Emit a warning
to tell it.

This is what GCC does too: https://godbolt.org/z/7eajb1Gf8

Reviewed By: Quuxplusone

Differential Revision: https://reviews.llvm.org/D115867
2022-02-08 11:43:42 +08:00
Hans Wennborg 807e2f12fa Revert "Remove -Wweak-template-vtables"
Turns out there's still some code referencing this. No harm in keeping it in a
bit longer.

> as it was planned for removal in clang 15 and we're now past the branch point
>
> See https://github.com/llvm/llvm-project/issues/19107
>
> Differential revision: https://reviews.llvm.org/D118762

This reverts commit 564f9be11c.
2022-02-07 16:52:23 +01:00
Aaron Ballman 22db4824b9 Use functions with prototypes when appropriate; NFC
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the third batch of tests being updated (there are a significant
number of other tests left to be updated).
2022-02-07 09:25:01 -05:00
Devin Jeanpierre 56d46b36fc [clang] roll-forward "[clang] Mark `trivial_abi` types as "trivially relocatable"".
This reverts commit 852afed5e0.

Changes since D114732:

On PS4, we reverse the expectation that classes whose constructor is deleted are not trivially relocatable. Because, at the moment, only classes which are passed in registers are trivially relocatable, and PS4 allows passing in registers if the copy constructor is deleted, the original assertions were broken on PS4.

(This is kinda similar to DR1734.)

Reviewed By: gribozavr2

Differential Revision: https://reviews.llvm.org/D119017
2022-02-04 20:17:34 +01:00
Dmitri Gribenko 852afed5e0 Revert "[clang] Mark `trivial_abi` types as "trivially relocatable"."
This reverts commit 19aa2db023. It breaks
a PS4 buildbot.
2022-02-03 22:31:44 +01:00
Hans Wennborg 564f9be11c Remove -Wweak-template-vtables
as it was planned for removal in clang 15 and we're now past the branch point

See https://github.com/llvm/llvm-project/issues/19107

Differential revision: https://reviews.llvm.org/D118762
2022-02-03 10:15:16 +01:00
Devin Jeanpierre 19aa2db023 [clang] Mark `trivial_abi` types as "trivially relocatable".
This change enables library code to skip paired move-construction and destruction for `trivial_abi` types, as if they were trivially-movable and trivially-destructible. This offers an extension to the performance fix offered by `trivial_abi`: rather than only offering trivial-type-like performance for pass-by-value, it also offers it for library code that moves values but not as arguments.

For example, if we use `memcpy` for trivially relocatable types inside of vector reallocation, and mark `unique_ptr` as `trivial_abi` (via `_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI` / `_LIBCPP_ABI_UNSTABLE` / etc.), this would speed up `vector<unique_ptr>::push_back` by 40% on my benchmarks. (Though note that in this case, the compiler could have done this anyway, but happens not to due to the inlining horizon.)

If accepted, I intend to follow up with exactly such changes to library code, including and especially `std::vector`, making them use a trivial relocation operation on trivially relocatable types.

**D50119 and P1144:**

This change is very similar to D50119, which was rejected from Clang. (That change was an implementation of P1144, which is not yet part of the C++ standard.)

The intent of this change, rather than trying to pick a winning proposal for trivial relocation operations, is to extend the behavior of `trivial_abi` in a way that could be made compatible with any such proposal. If P1144 or any similar proposal were accepted, then `trivial_abi`, `__is_trivially_relocatable`, and everything else in this change would be redefined in terms of that.

**Safety:**

It's worth pointing out, specifically, that `trivial_abi` already implies trivial relocatability in a narrow sense: a `trivial_abi` type, when passed by value, has its constructor run in one location, and its destructor run in another, after the type has been trivially relocated (through registers).

Trivial relocatability optimizations could change the number of paired constructor/destructor calls, but this seems unlikely to matter for `trivial_abi` types.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D114732
2022-02-02 17:42:20 -08:00
Richard Smith 30baa5d2a4 PR45879: Fix assert when constant evaluating union assignment.
Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.
2022-02-02 17:02:47 -08:00
David Blaikie 275c56226d Disable -Wmissing-prototypes for internal linkage functions that aren't explicitly marked "static"
Some functions can end up non-externally visible despite not being
declared "static" or in an unnamed namespace in C++ - such as by having
parameters that are of non-external types.

Such functions aren't mistakenly intended to be defining some function
that needs a declaration. They could be maybe more legible (except for
the `operator new` example) with an explicit static, but that's a
stylistic thing outside what should be addressed by a warning.
2022-01-31 17:34:51 -08:00
Dávid Bolvanský 623b66eded [Clang][NFC] Added testcase from #49549
The issue is fixed in trunk, so add testcase to avoid regression in the future.
2022-01-31 23:45:56 +01:00
Aaron Ballman a6cabd9802 Revert fad7e491a0 with fixes applied
fad7e491a0 was a revert of
86797fdb6f due to build failures. This
hopefully fixes them.
2022-01-29 08:12:16 -05:00
Jan Korous fad7e491a0 Revert "Add BITINT_MAXWIDTH support"
This reverts commit 86797fdb6f.

Differential Revision: https://reviews.llvm.org/D117238
2022-01-28 15:18:49 -08:00
Aaron Ballman 86797fdb6f Add BITINT_MAXWIDTH support
Part of the _BitInt feature in C2x
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) is a new
macro in limits.h named BITINT_MAXWIDTH that can be used to determine
the maximum width of a bit-precise integer type. This macro must expand
to a value that is at least as large as ULLONG_WIDTH.

This adds an implementation-defined macro named __BITINT_MAXWIDTH__ to
specify that value, which is used by limits.h for the standard macro.

This also limits the maximum bit width to 128 bits because backends do
not currently support all mathematical operations (such as division) on
wider types yet. This maximum is expected to be increased in the future.
2022-01-28 15:04:29 -05:00
David Blaikie 277123376c GCC ABI Compatibility: Preserve alignment of non-pod members in packed structs
This matches GCC: https://godbolt.org/z/sM5q95PGY

I realize this is an API break for clang+clang - so I'm totally open to
discussing how we should deal with that. If Apple wants to keep the
Clang layout indefinitely, if we want to put a flag on this so non-Apple
folks can opt out of this fix/new behavior.

Differential Revision: https://reviews.llvm.org/D117616
2022-01-28 11:04:20 -08:00
Arthur O'Dwyer f9a00b3cbc Revert "[clang] Don't typo-fix an expression in a SFINAE context."
This reverts commit 9be5f4d5af.

I'm not sure if this caused
 https://lab.llvm.org/buildbot/#/builders/60/builds/6350
 https://lab.llvm.org/buildbot/#/builders/119/builds/7433
but I'm acting as if it did.
2022-01-27 17:36:08 -05:00
Arthur O'Dwyer 9be5f4d5af [clang] Don't typo-fix an expression in a SFINAE context.
If this is a SFINAE context, then continuing to look up names
(in particular, to treat a non-function as a function, and then
do ADL) might too-eagerly complete a type that it's not safe to
complete right now. We should just say "okay, that's a substitution
failure" and not do any more work than absolutely required.

Fixes #52970.

Differential Revision: https://reviews.llvm.org/D117603
2022-01-27 14:21:50 -05:00
MuAlphaOmegaEpsilon ccce1a03c9 Don't trigger unused-parameter warnings on naked functions
This commit checks if a function is marked with the naked attribute
and, if it is, will silence the emission of any unused-parameter
warning.

Inside a naked function only the usage of basic ASM instructions is
expected. In this context the parameters can actually be used by
fetching them according to the underlying ABI. Since parameters might
be used through ASM instructions, the linter and the compiler will have
a hard time understanding if one of those is unused or not, therefore
no unused-parameter warning should ever be triggered whenever a
function is marked naked.
2022-01-27 11:40:08 -05:00
Jake Egan 6f0977519d [AIX][ZOS] Handle unsupported builtin function CFStringMakeConstantString
This patch emits an error on AIX and z/OS because XCOFF and GOFF does not currently implement builtin function `CFStringMakeConstantString`. Tests that use this builtin were also disabled.

Reviewed By: SeanP

Differential Revision: https://reviews.llvm.org/D117315
2022-01-17 11:24:16 -05:00
hyeongyu kim 1b1c8d83d3 [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default
Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default.

Test updates are made as a separate patch: D108453

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 18:54:17 +09:00
Chuanqi Xu 4f4340ee2a [NFC] [Coroutines] Refactor implementation in checkFinalSuspendNoThrow
Now when we are checking if the expression `co_await
promise.final_suspend()` is not throw, we would check unconditionally
for its child expressions recursively. It takes unnecessary time. And
the compiler would complains if the implementation in final_suspend()
may throw even if the higher level function signature marked noexcept
already.

This fixes bug48453 too.
2022-01-14 15:37:01 +08:00
Paulo Matos 968be05b8f [clang] Fix crash for sizeof on VLAs
Adds overload of TransformToPotentiallyEvaluated for TypeSourceInfo to
properly deal with VLAs in nested calls of sizeof and typeof. Fixes
PR31042 (https://github.com/llvm/llvm-project/issues/30390).

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D27800
2022-01-12 16:10:58 +01:00
Carlos Galvez c4db521cea [clang] Introduce support for disabling warnings in system macros
Often we run into situations where we want to ignore
warnings from system headers, but Clang will still
give warnings about the contents of a macro defined
in a system header used in user-code.

Introduce a ShowInSystemMacro option to be able to
specify which warnings we do want to keep raising
warnings for. The current behavior is kept in this patch
(i.e. warnings from system macros are enabled by default).
The decision as to whether this should be an opt-in or opt-out
feature can be made in a separate patch.

To put the feature to test, replace duplicated code for
Wshadow and Wold-style-cast with the SuppressInSystemMacro tag.
Also disable the warning for C++20 designators, fixing #52944.

Differential Revision: https://reviews.llvm.org/D116833
2022-01-12 08:18:19 +00:00
Markus Böck 6479f03dae [clang][#47272] Avoid suggesting deprecated version of a declaration over another in typo correction
Prior to this patch, clang might suggest a deprecated name of a declaration over another name as the only mechanism for resolving two typo corrections referring to the same underlying declaration has previously been an alphabetical sort.

This patch adjusts this resolve by also taking into account whether one of two declarations are deprecated. If the new one is deprecated it may not replace a previous correction with a non-deprecated correction and a previous deprecated correction always gets replaced by a non-deprecated new correction.

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

Differential Revision: https://reviews.llvm.org/D116775
2022-01-11 22:58:10 +01:00
Chuanqi Xu d9d63fc108 [AST] lookup in parent DeclContext for transparent DeclContext
The compiler would crash if we lookup for name in transparent decl
context. See the tests attached for example.

I think this should make sense since the member declared in transparent
DeclContext are semantically defined in the enclosing (non-transparent)
DeclContext, this is the definition for transparent DeclContext.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D116792
2022-01-11 10:16:26 +08:00
Chuanqi Xu 86c5b870b2 [AST] Don't consider 'ExportDecl' when calculating DeclContext 'Encloses'
This mimics the style of 90010c2e1 (Don't consider 'LinkageSpec' when
calculating DeclContext 'Encloses'). Since ExportDecl and LinkageSpec
are transparent DeclContext, they share some similarity.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D116911
2022-01-11 09:54:57 +08:00
Sam McCall 27ea0c4e72 [Parse] Use empty RecoveryExpr when if/while/do/switch conditions fail to parse
This allows the body to be parsed.
An special-case that would replace a missing if condition with OpaqueValueExpr
was removed as it's now redundant (unless recovery-expr is disabled).

For loops are not handled at this point, as the parsing is more complicated.

Differential Revision: https://reviews.llvm.org/D113752
2022-01-10 10:38:27 +01:00
Amy Huang 28d2977ff2 [-fms-extensions] Make some exception specification warnings/errors compatible with what cl.exe does
Make clang-cl error when a function definition is missing 'noexcept',
and succeed without warnings when missing '__declspec(nothrow)' or 'throw'.

Fixes pr52860

Differential Revision: https://reviews.llvm.org/D116256
2022-01-07 14:42:16 -08:00
Egor Zhdan c033f0d9b1 [Clang][Sema] Avoid crashing for va_arg expressions with bool argument
This change fixes a compiler crash that was introduced in https://reviews.llvm.org/D103611: `Sema::BuildVAArgExpr` attempted to retrieve a corresponding signed type for `bool` by calling `ASTContext::getCorrespondingSignedType`.

rdar://86580370

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D116272
2022-01-07 10:41:45 +01:00
Yuanfang Chen e902ffe6d7 [Sema] Fix the assertion in Sema::ActOnDependentMemberExpr
617007240c introduced the use of ActOnDependentMemberExpr with
variable template specialization. The assertion inside
ActOnDependentMemberExpr should be adjusted accordingly.

Fixes https://bugs.llvm.org/show_bug.cgi?id=47211

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D113146
2022-01-04 13:08:12 -08:00
David Blaikie e1e74f6cd6 -Wmissing-prototypes: Don't warn in named namespaces nested in anonymous namespaces 2022-01-04 10:08:23 -08:00
Sam McCall 71059f26d3 [AST] Produce ReturnStmt containing RecoveryExpr when type is wrong
Previously we just drop the ReturnStmt and its argument from the AST,
which blocks analysis of broken code.

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

Differential Revision: https://reviews.llvm.org/D116414
2022-01-04 17:07:55 +01:00
Nathan Sidwell b50fea47b6 [clang] Allow using std::coroutine_traits in std::experimental
This is that diff I was aiming for.  When transitioning code from
coroutines-ts to c++20, it can be useful to add a using declaration to
std::experimental pointing to std::coroutine_traits.  This permits
that use by checking whether lookup in std::experimentl finds a
different decl to lookup in std.  You still get a warning about
std::experimental::coroutine_traits being a thing, just not an error.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D115943
2022-01-02 15:48:16 -05:00
Nathan Sidwell d4f09786e0 [clang] More informative mixed namespace diagnostics
First, let's check we get a TemplateDecl, before complaining about
where it might have been found.

Second, if it came from an unexpected place, show where that location is.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D116164
2022-01-02 12:23:13 -05:00
Sam McCall 3ad32df72e
Fix lit feature name in 9dc4af327b 2021-12-29 13:18:11 +01:00
Sam McCall 9dc4af327b Re-land "[clang] Add early exit when checking for const init of arrays."
This reverts commit 6d09aaecdf.

The test uses ulimit and ran into problems on some bots. Run on linux only.
There's nothing platform-specific about the code we're testing, so this
should be enough to ensure correctness.
2021-12-29 13:07:30 +01:00
Chuanqi Xu 097208dbf0 [C++20] [Coroutines] Allow promise_type to not define return_void or return_value
According to [dcl.fct.def.coroutine]p6, the promise_type is allowed to
not define return_void nor return_value:

> If searches for the names return_­void and return_­value in the scope
> of the promise type each find any declarations, the program is
> ill-formed.
> [Note 1: If return_­void is found, flowing off the end of a coroutine is
> equivalent to a co_­return with no operand. Otherwise, flowing off the
> end of a coroutine results in
> undefined behavior ([stmt.return.coroutine]). — end note]

So the program isn't ill-formed if the promise_type doesn't define
return_void nor return_value. It is just a potential UB. So the program
should be allowed to compile.

Reviewed By: urnathan

Differential Revision: https://reviews.llvm.org/D116204
2021-12-24 13:37:51 +08:00
Sami Tolvanen ec2e26eaf6 [Clang] Add __builtin_function_start
Control-Flow Integrity (CFI) replaces references to address-taken
functions with pointers to the CFI jump table. This is a problem
for low-level code, such as operating system kernels, which may
need the address of an actual function body without the jump table
indirection.

This change adds the __builtin_function_start() builtin, which
accepts an argument that can be constant-evaluated to a function,
and returns the address of the function body.

Link: https://github.com/ClangBuiltLinux/linux/issues/1353

Depends on D108478

Reviewed By: pcc, rjmccall

Differential Revision: https://reviews.llvm.org/D108479
2021-12-20 12:55:33 -08:00
Nathan Sidwell 565c17574d [clang] Adjust coroutine namespace diagnostics
The diagnostics concerning mixing std::experimental and std are
somewhat wordy and have some typographical errors.  Diagnostics do not
start with a capital letter nor end with a fullstop.  Usually we try
and link clauses with a semicolon, rather than start a new sentence.
So that's what this patch does.  Along with avoiding repetition about
std::experimental going away.

Differential Revision: https://reviews.llvm.org/D116026
2021-12-20 08:50:16 -08:00
Erich Keane a94f68a2bd Implement some constexpr vector unary operators, fix boolean-ops
As requested in the review, this implements unary +,-,~, and ! for
vector types.

All of our boolean operations on vector types should be using something
like vcmpeqd, which results in a mask of '-1' for the 'truth' type. We are
currently instead using '1', which results in some incorrect
calculations when used later (note that it does NOT result in a boolean
vector, as that is not really a thing).

This patch corrects that 1 to be a -1, and updates the affected tests.

Differential Revision: https://reviews.llvm.org/D115670
2021-12-17 06:08:36 -08:00
Chuanqi Xu 9db8162820 [NFC] Format .cppm files in tests 2021-12-13 23:32:25 +08:00
Nico Weber 45158b1804 Revert "[NFC] format .cppm files in test"
This reverts commit 7c51a12833.
Breaks SemaCXX/modules-ts.cppm in check-clang.
2021-12-13 07:13:17 -05:00
Chuanqi Xu 7c51a12833 [NFC] format .cppm files in test 2021-12-13 19:52:31 +08:00
Jun Zhang 8680f951c2 Add __builtin_elementwise_ceil
This patch implements one of the missing builtin functions specified
in https://reviews.llvm.org/D111529.
2021-12-08 08:29:33 -05:00
Aaron Ballman a18632adc8 Add diagnostic groups for attribute extensions
Some users have a need to control attribute extension diagnostics
independent of other extension diagnostics. Consider something like use
of [[nodiscard]] within C++11:
```
[[nodiscard]]
int f();
```
If compiled with -Wc++17-extensions enabled, this will produce warning:
use of the 'nodiscard' attribute is a C++17 extension. This diagnostic
is correct -- using [[nodiscard]] in C++11 mode is a C++17 extension.
And the behavior of __has_cpp_attribute(nodiscard) is also correct --
we support [[nodiscard]] in C++11 mode as a conforming extension. But
this makes use of -Werror or -pedantic-errors` builds more onerous.

This patch adds diagnostic groups for attribute extensions so that
users can selectively disable attribute extension diagnostics. I
believe this is preferable to requiring users to specify additional
flags because it means -Wc++17-extensions continues to be the way we
enable all C++17-related extension diagnostics. It would be quite easy
for someone to use that flag thinking they're protected from some
portability issues without realizing it skipped attribute extensions if
we went the other way.

This addresses PR33518.
2021-12-07 11:49:53 -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
Corentin Jabot 6eeda06c1d [Clang] Fix nesting of discarded and immediate contexts.
In C++23, discarded statements and if consteval statements can nest
arbitrarily. To support that, we keep track of whether the parent of
the current evaluation context is discarded or immediate.

This is done at the construction of an evaluation context
to improve performance.

Fixes https://bugs.llvm.org/show_bug.cgi?id=52231
2021-12-01 12:58:32 -05:00
Jeroen Dobbelaere a4fbae268f Revert "[Sema] check PseudoObject when rebuilding CXXOperatorCallExpr in template instantiation"
This reverts commit 0c047a8e13.

A number of buildbots started failing. Reverting for now.
2021-12-01 11:18:30 +01:00