2340 Commits

Author SHA1 Message Date
Tom Weaver
ea79b3bc39 Revert "[Sema] setInvalidDecl for error deduction declaration"
This reverts commit eb5902ffc97163338bab95d2fd84a953ee76e96f.

Caused buildbot failures on:
  https://lab.llvm.org/buildbot/#/builders/139/builds/41248
  https://lab.llvm.org/buildbot/#/builders/216/builds/21637
2023-05-23 11:44:51 +01:00
Congcong Cai
eb5902ffc9 [Sema] setInvalidDecl for error deduction declaration
Fixed: https://github.com/llvm/llvm-project/issues/62408
`setInvalidDecl` for invalid `CXXDeductionGuideDecl` to
avoid crashes during semantic analysis.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D149516
2023-05-23 09:07:05 +02:00
Alan Zhao
d1d35f04c6 [clang] Fix initializer_list matching failures with modules
Previously, if a class with a defined public virtual destructor is
declared before including <initializer_list> and initializer_list is
provided via a Clang module, then overload resolution would fail for
std::initializer_list. This is because when Clang sees the virtual
destructor, Clang creates an implicit NamespaceDecl for std to
implicitly declare a std::bad_alloc. That NamespaceDecl is not added to
the translation unit's lookup table, so when the module containing
std::initializer_list is imported later, that module's std NamespaceDecl
can't find the previous std NamespaceDecl during redeclaration lookup,
causing overload resolution to fail.

To fix this, implicitly created std NamespaceDecls are now added to the
lookup map. At the same time, their IdentifierNamespace members are
cleared to prevent regular name lookups from finding it.

Fixes 60929

Reviewed By: ChuanqiXu, #clang-language-wg, inclyc

Differential Revision: https://reviews.llvm.org/D150001
2023-05-09 10:31:43 -07:00
Elizabeth Andrews
ca06638bbb [SYCL][NFC] Remove dead code 2023-05-08 13:08:23 -07:00
Peter Kasting
dd6a58babc [Sema] Avoid emitting warnings for constant destruction.
Fixes https://github.com/llvm/llvm-project/issues/62436.

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D149713
2023-05-06 20:54:22 +05:30
Shafik Yaghmour
7887af027e Fix build bots due to missing a commit thay change 2b to 23
Fixing build bot breaks due to b4692f29263006c7ea519c7b11c9082384f0af53
2023-05-04 11:33:58 -07:00
Michael Liao
058f04ea7d [clang] Fix another case where CPlusPlus2b is still used. 2023-05-04 14:27:33 -04:00
Shafik Yaghmour
b4692f2926 [Clang] Updating handling of defaulted comparison operators to reflect changes from P2448R2
Prior to P2448R2 we were more aggressive in diagnosing ill-formed
constexpr functions. Many of these restrictions were relaxed and now it
is not required for defaulted comparison operators to call constexpr
functions.

This behavior is extended to before C++23 and diagnostic for it's use
can be enabled w/ -pedantic or -Wc++2b-default-comp-relaxed-constexpr

This fixes: https://github.com/llvm/llvm-project/issues/61238

Differential Revision: https://reviews.llvm.org/D146090
2023-05-04 11:07:16 -07:00
Mark de Wever
ba15d186e5 [clang] Use -std=c++23 instead of -std=c++2b
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.

Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D149553
2023-05-04 19:19:52 +02:00
David Stone
6d6880554c [clang][Sema][NFC] Move EnterExpressionEvaluationContext to its own file
Sema.h is huge. This makes a small reduction to it by moving
EnterExpressionEvaluationContext into a new header, since it is an
independent component.

Differential Revision: https://reviews.llvm.org/D149796
2023-05-04 13:06:53 -04:00
Manna, Soumi
ff4d2207db [NFC][clang] Fix static analyzer concerns
Reported by Coverity:

AUTO_CAUSES_COPY
Unnecessary object copies can affect performance.

1. Inside "SemaDeclCXX.cpp" file, in <unnamed>::DiagnoseUninitializedFields(clang::Sema &, clang::CXXConstructorDecl const *): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

2. Inside "ClangAttrEmitter.cpp" file, in clang::EmitClangAttrParsedAttrImpl(llvm::RecordKeeper &, llvm::raw_ostream &): Using the auto keyword without an & causes the copy of an object of type pair.

3. Inside "Marshallers.h" file, in clang::ast_matchers::dynamic::internal::MapAnyOfBuilderDescriptor::buildMatcherCtor(clang::ast_matchers::dynamic::SourceRange, llvm::ArrayRef<clang::ast_matchers::dynamic::ParserValue>, clang::ast_matchers::dynamic::Diagnostics *): Using the auto keyword without an & causes the copy of an object of type ParserValue.

4. Inside "CGVTables.cpp" file, in clang::CodeGen::CodeGenModule::GetVCallVisibilityLevel(clang::CXXRecordDecl const *, llvm::DenseSet<clang::CXXRecordDecl const *, llvm::DenseMapInfo<clang::CXXRecordDecl const *, void>> &): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

5. Inside "ASTContext.cpp" file, in hasTemplateSpecializationInEncodedString(clang::Type const *, bool): Using the auto keyword without an & causes the copy of an object of type CXXBaseSpecifier.

6. Inside "ComputeDependence.cpp" file, in clang::computeDependence(clang::DependentScopeDeclRefExpr *): Using the auto keyword without an & causes the copy of an object of type TemplateArgumentLoc.

Reviewed By: tahonermann, erichkeane

Differential Revision: https://reviews.llvm.org/D148812
2023-04-23 18:19:55 -04:00
Shafik Yaghmour
6d0fab467e [Clang] Fix defaulted equality operator so that it does not attempt to compare unnamed bit-fields
If we look at class.bit p2 it tells us that that unnamed bit-fields are not
members and class.compare.default p5 tells us that we should only compare
non-static data members of the class.

This fixes: https://github.com/llvm/llvm-project/issues/61335 and https://github.com/llvm/llvm-project/issues/61417

Differential Revision: https://reviews.llvm.org/D146329
2023-04-14 15:01:00 -07:00
Jorge Pinto Sousa
66202d83b5 Make 'static assertion failed' diagnostics point to the static assertion expression
"static assertion failed" pointed to the static_assert token and
then underlined the static assertion expression:

<source>:3:1: error: static assertion failed
    static_assert(false);
    ^             ~~~~~
    1 error generated.
See Godbolt: https://godbolt.org/z/r38booz59

Now it points to and highlights the assertion expression.

Fixes https://github.com/llvm/llvm-project/issues/61951
Differential Revision: https://reviews.llvm.org/D147745
2023-04-13 08:15:13 -04:00
Richard Sandiford
b6d4d51f8f [clang] Specify attribute syntax & spelling with a single argument
When constructing an attribute, the syntactic form was specified
using two arguments: an attribute-independent syntax type and an
attribute-specific spelling index.  This patch replaces them with
a single argument.

In most cases, that's done using a new Form class that combines the
syntax and spelling into a single object.  This has the minor benefit
of removing a couple of constructors.  But the main purpose is to allow
additional information to be stored as well, beyond just the syntax and
spelling enums.

In the case of the attribute-specific Create and CreateImplicit
functions, the patch instead uses the attribute-specific spelling
enum.  This helps to ensure that the syntax and spelling are
consistent with each other and with the Attr.td definition.

If a Create or CreateImplicit caller specified a syntax and
a spelling, the patch drops the syntax argument and keeps the
spelling.  If the caller instead specified only a syntax
(so that the spelling was SpellingNotCalculated), the patch
simply drops the syntax argument.

There were two cases of the latter: TargetVersion and Weak.
TargetVersionAttrs were created with GNU syntax, which matches
their definition in Attr.td, but which is also the default.
WeakAttrs were created with Pragma syntax, which does not match
their definition in Attr.td.  Dropping the argument switches
them to AS_GNU too (to match [GCC<"weak">]).

Differential Revision: https://reviews.llvm.org/D148102
2023-04-13 10:14:49 +01:00
Richard Sandiford
e841d50926 [clang] Ensure that Attr::Create(Implicit) chooses a valid syntax
The purpose of this patch and follow-on patches is to ensure that
AttributeCommonInfos always have a syntax that is appropriate for
their kind (i.e. that it matches one of the entries in Attr.td).

The attribute-specific Create and CreateImplicit methods had four
overloads, based on their tail arguments:

(1) no extra arguments
(2) an AttributeCommonInfo
(3) a SourceRange
(4) a SourceRange, a syntax, and (where necessary) a spelling

When (4) had a spelling argument, it defaulted to
SpellingNotCalculated.

One disadvantage of this was that (1) and (3) zero-initialized
the syntax field of the AttributeCommonInfo, which corresponds
to AS_GNU.  But AS_GNU isn't always listed as a possibility
in Attr.td.

This patch therefore removes (1) and (3) and instead provides
the same functionality using default arguments on (4) (a bit
like the existing default argument for the spelling).
The default syntax is taken from the attribute's first valid
spelling.

Doing that raises the question: what should happen for attributes
like AlignNatural and CUDAInvalidTarget that are only ever created
implicitly, and so have no source-code manifestation at all?
The patch adds a new AS_Implicit "syntax" for that case.
The patch also removes the syntax argument for these attributes,
since the syntax must always be AS_Implicit.

For similar reasons, the patch removes the syntax argument if
there is exactly one valid spelling.

Doing this means that AttributeCommonInfo no longer needs the
single-argument constructors.  It is always given a syntax instead.

Differential Revision: https://reviews.llvm.org/D148101
2023-04-13 10:14:48 +01:00
Krishna Narayanan
06c6fac696 Update static_assert message for redundant cases
There are some simple messages where an expansion isn't particularly
helpful or needed. We aim to eliminate expansions that don't add much
value for user (this will give us slightly more room or prioritise to
have longer diagnostics elsewhere).

The test case for which it has been tested:
```
constexpr auto is_gitlab = false;
constexpr auto is_weekend = false;
static_assert(is_gitlab or is_weekend);
```

Previous warning/error message:
```
<source>:4:1: error: static assertion failed due to requirement 'is_gitlab || is_weekend'
static_assert(is_gitlab or is_weekend);
^             ~~~~~~~~~~~~~~~~~~~~~~~
<source>:4:25: note: expression evaluates to 'false || false'
static_assert(is_gitlab or is_weekend);
              ~~~~~~~~~~^~~~~~~~~~~~~
```
Currrent warning/error message:
```
<source>:4:1: error: static assertion failed due to requirement 'is_gitlab'
static_assert(is_gitlab or is_weekend);
^             ~~~~~~~~~
```
This patch aims to remove some redundant cases of static assert messages
where the expansions are particularly unhelpful. In this particular
patch, we have ignored the printing of diagnostic warnings for binary
operators with logical OR operations.

This is done to prioritise and prefer to emit longer diagnostic
warnings for more important concerns elsewhere.

Differential Revision: https://reviews.llvm.org/D146376
2023-04-07 08:22:04 -04:00
Ilya Biryukov
f27b77e5c5 [Sema] Populate declarations inside TypeLocs for some invalid types
This also reverts 282cae0b9a602267ad7ef622f770066491332a11 as the
particular crash is now handled by the new code.

Before this change Clang would always leave declarations inside the
type-locs as `null` if the declarator had an invalid type. This patch
populates declarations even for invalid types if the structure of the
type and the type-locs match.

There are certain cases that may still cause crashes. These happen when
Clang recovers the type in a way that is not reflected in the
declarator's structure, e.g. adding a pointer when it was not present in
the code for ObjC interfaces or ignoring pointers written in the code
in C++ with auto return type (`auto* foo() -> int`). Those cases look
fixable with a better recovery strategy and I plan to follow up with
more patches to address those.

The first attempt caused 31 tests from `check-clang` to crash due to
different structure of the types and type-locs after certain errors. The
good news is that the failure is localized and mismatch in structures is
discovered by assertions inside `DeclaratorLocFiller`. Some notable
cases caught by existing tests:
- Invalid chunks when type is fully ignored and replace with int or now.
  Crashed in `C/C2x/n2838.c`.
- Invalid return types in lambdas. Crashed in `CXX/drs/dr6xx.cpp`.
- Invalid member pointers. Crashed in `CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p3-generic-lambda-1y.cpp`
- ObjC recovery that adds pointers. Crashed in `SemaObjC/blocks.m`

This change also updates the output of `Index/complete-blocks.m`.
Not entirely sure what causes the change, but the new function signature
is closer to the source code, so this seems like an improvement.

Reviewed By: aaron.ballman, erichkeane

Differential Revision: https://reviews.llvm.org/D146971
2023-04-06 19:02:41 +02:00
Mike Rice
57caadc57a [MSVC] Allow declaration of multi-dim 'property' array fields
MSVC allows declaration of multi-dim arrays like this:

__declspec(property(get=GetX, put=PutX)) int x[][][];

This syntax can appear in generated typelib headers.

Currently clang errors on declarators like this since it forms an array
type of incomplete array. Rather than try to handle such a type, ignore
adjacent empty chunks so this is treated as if there was only one empty
array chunk (i.e. int x[]).

The functionality to handle multi-dim subscripts of property fields
already works, but only if declared as a single-dim array.
2023-04-05 10:29:37 -07:00
Wolfgang Pieb
477f9cea77 [MSCV][dllexport/dllimport][PS] Allow UniqueExternal linkage classes with dllexport/dllimport
MSVC allows instantiations of exported or imported template classes with template
parameters that have internal linkage. Clang now allows it in Microsoft mode and for
the Playstation platform. This partially addresses issue 56068.

Note that MSVC also allows explicit dllexport/dllimport attributes on classes
with internal linkage (e.g. local classes or classes declared in anonymous name spaces).
Clang continues to reject such declarations.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D146338
2023-03-29 18:15:04 +00:00
Ilya Biryukov
282cae0b9a [Sema] Fix crash on __fp16 parameters in template instantiations
Fixes #61441.

Currently, Clang stores `nullptr` in the parameter lists inside
`FunctionProtoTypeLoc` if `__fp16` is used without pointer qualifiers.

Any code path that calls `Declarator::setInvalidType()` before
`GetFullTypeForDeclarator` will lead to the same problem downstream.

The relevant code is:
```cpp
if (D.isInvalidType())
  return Context.getTrivialTypeSourceInfo(T);

return GetTypeSourceInfoForDeclarator(state, T, TInfo);
```

`GetTypeSourceInfoForDeclarator` sets the parameter `Decl`, but we can't
call it when `isInvalidType() == true` as this causes other assertion
failures that seem harder to fix.

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.org/D146426
2023-03-21 14:06:46 +01:00
Roy Jacobson
765d8a1921 [Clang][Sema] Fix incorrect deletion of default constructors for some unions
If a union has explicit initializers for some members, we shouldn't delete
its default constructor.
Fixes https://github.com/llvm/llvm-project/issues/48416.

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D145851
2023-03-15 23:55:52 +02:00
Wolfgang Pieb
634430d585 [MSVC][dllexport/dllimport] Propagate a dllexport/dllimport attribute to template baseclass
For the Playstation platform, mimick MSVC in propagating dllexport/dllimport attributes
to an instantiated template base class.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D145970
2023-03-15 11:47:54 -07:00
Chuanqi Xu
5828692f70 [C++20] [Modules] Make TheImplicitGlobalModuleFragment and TheExportedImplicitGlobalModuleFragment to be useable modules
The unexported language linkage become unvisible to the current module
unit after the previous commit bf52ead24ca4. This patch fixes the issue.
2023-03-03 11:15:29 +08:00
Chuanqi Xu
bf52ead24c [C++20] [Modules] Support to export declarations in language linkage
Close https://github.com/llvm/llvm-project/issues/60405

See the discussion in the above link for the background.

What the patch does:
- Rename `Module::ModuleKind::GlobalModuleFragment` to
  `Module::ModuleKind::ExplicitGlobalModuleFragment`.
- Add another module kind `ImplicitGlobalModuleFragment` to
  `ModuleKind`.
- Create an implicit global module fragment for the language linkage
  declarations inside a module purview.
    - If the language linkage lives inside the scope of an export decl,
      the created modules is marked as exported to outer modules.
- In fact, Sema will only create at most 2 implicit global module
  fragments to avoid creating a lot of unnecessary modules in the edging
case.

Reviewed By: iains

Differential Revision: https://reviews.llvm.org/D144367
2023-03-03 10:31:48 +08:00
Stephan Bergmann
d812488d3c Call MarkVirtualMembersReferenced on an actual class definition
...rather than on potentially just a declaration.

Without the fix, the newly added clang/test/SemaCXX/warn-undefined-internal.cpp
failed with

> error: 'warning' diagnostics expected but not seen:
>   File /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp Line 12 (directive at /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp:13): function 'test2()::S::f' has internal linkage but is not defined
> error: 'note' diagnostics expected but not seen:
>   File /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp Line 14 (directive at /home/sbergman/github.com/llvm/llvm-project/clang/test/SemaCXX/warn-undefined-internal.cpp:15): used here

(I ran into this when two LibreOffice Clang plugins produced false positive
warnings, as they relied on Decl::isReferenced() returning true for such virtual
member functions of local classes.)

Differential Revision: https://reviews.llvm.org/D145123
2023-03-02 15:50:12 +01:00
Corentin Jabot
00e2098bf4 [Clang] Implement CWG2518 - static_assert(false)
This allows `static_assert(false)` to not be ill-formed
in template definitions.

This change is applied as a DR in all C++ modes.

Of notes, a couple of tests were relying of the eager nature
of static_assert

* test/SemaTemplate/instantiation-dependence.cpp
* test/SemaTemplate/instantiate-var-template.cpp

I don't know if the changes to `static_assert`
still allow that sort of tests to be expressed.

Reviewed By: #clang-language-wg, erichkeane, aaron.ballman

Differential Revision: https://reviews.llvm.org/D144285
2023-02-28 17:21:40 +01:00
Chuanqi Xu
2dfa957f12 [NFC] Remove the unused parameter in Sema::PushGlobalModuleFragment
The `IsImplicit` parameter should be removed since it is not used now.
2023-02-20 15:37:55 +08:00
Chuanqi Xu
55900a0d20 Recommit [Coroutines] Stop supportting std::experimental::coroutine_traits
As we discussed before, we should stop supporting
std::experimental::coroutine_traits in clang17. Now the clang16 is
branched so we can clean them now.

All the removed tests have been duplicated before.
2023-02-20 10:27:02 +08:00
Chuanqi Xu
6d5ea6b123 Revert "[Coroutines] Stop supportting std::experimental::coroutine_traits"
This reverts commit c4e6e771f255fb1da3d505534997b6a88195b012.

Since clang-tools-extra contains the use for
std::experimental::coroutine_traits, the previsou commit breaks the
build bot. Revert this one to make the bot green.
2023-02-17 15:50:54 +08:00
Chuanqi Xu
c4e6e771f2 [Coroutines] Stop supportting std::experimental::coroutine_traits
As we discussed before, we should stop supporting
std::experimental::coroutine_traits in clang17. Now the clang16 is
branched so we can clean them now.

All the removed tests have been duplicated before.
2023-02-17 15:35:17 +08:00
Haojian Wu
e400c63cc3 Revert "[clang] Build UsingType for elaborated type specifiers."
This reverts commit e70ca7b35319a3621f9d9c6475926428f8c5c000 and the
followup patch "[clang] Fix the location of UsingTypeLoc"
(ebbeb164c25a40cb6ba9c6b18dce5dcd06c0bb07).

The patch causes an incorrect lookup result:

```
namespace ns { struct Foo { };}

using ns::Foo;
void test() {
  struct Foo {
  } k; // the type of k refers to ns::Foo, rather than the local Foo!
}
```
2023-01-26 11:37:41 +01:00
Brad King
028d13b156 [clang] Add ElaboratedType sugaring for types on implicit special members
Extend the change from commit 15f3cd6bfc67 ([clang] Implement
ElaboratedType sugaring for types written bare, 2021-10-11, D112374)
to cover types in the signatures of implicit copy-constructor,
copy-assignment, move-constructor, and move-assignment members in
C++ record types.

With this fix, diagnostic messages print types of special members
consistently whether they are explicitly or implicitly defined.

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

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D141441
2023-01-20 15:51:32 -08:00
Kadir Cetinkaya
ebd9a2477e
[clang] Fix typos in member initializers
This was regressed in ca619613801233ef2def8c3cc7d311d5ed0033cb. As we
attached InitExprs as-is to the AST, without performing transformations.

Differential Revision: https://reviews.llvm.org/D142187
2023-01-20 15:20:31 +01:00
Haojian Wu
e70ca7b353 [clang] Build UsingType for elaborated type specifiers.
Support building UsingType for elaborated type specifiers:

```
namespace ns { class Foo {}; }

using ns::Foo;

// The TypeLoc of `Foo` below should be a ElaboratedTypeLoc with an
// inner UsingTypeLoc rather than the underlying `CXXRecordTypeLoc`
class Foo foo;
```

Differential Revision: https://reviews.llvm.org/D141280
2023-01-19 14:20:38 +01:00
Aaron Ballman
e7300e75b5 Diagnose extensions in 'offsetof'
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.

This adds extension warnings and documentation for the functionality
Clang explicitly supports.

Fixes #57065
Reverts the revert of 39da55e8f548a11f7dadefa73ea73d809a5f1729

Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>

Differential Revision: https://reviews.llvm.org/D133574
2023-01-18 08:51:21 -05:00
Haojian Wu
6898d8413f Reland "nullptr returned from ActOnTag() is not a valid result"
The commit was reverted in 346e1c43a11b8af5a818dac321f83f043862c1ec as
part of the f1f0a0d8e8fdd2e534d9423b2e64c6b8aaa53aee revert.
2023-01-18 12:41:44 +01:00
Arthur Eubanks
39da55e8f5 Revert "Diagnose extensions in 'offsetof'"
This reverts commit f1f0a0d8e8fdd2e534d9423b2e64c6b8aaa53aee.

Causes crashes on

$ echo 'typedef int a; void c() { __builtin_offsetof(struct {a b}, b); }' | bin/clang -cc1 -emit-llvm -o /dev/null - -x c
2023-01-17 22:35:21 -08:00
Arthur Eubanks
346e1c43a1 Revert "nullptr returned from ActOnTag() is not a valid result"
This reverts commit 3925fbc80019f72bf3f5174736f348acfb5768b0.

Dependent commit to be reverted.
2023-01-17 22:35:20 -08:00
Aaron Ballman
3925fbc800 nullptr returned from ActOnTag() is not a valid result
DeclResult tracks two states: valid/invalid and usable/unusable.
Passing a null pointer to the constructor creates a valid but unusable
result and we wanted an invalid result instead. This changes some
functions to return a DeclResult rather than a Decl * to make it harder
to get this incorrect in callers.

Discovered when working on https://reviews.llvm.org/D141280.

Co-authored-by: Haojian Wu <hokein@google.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>

Differential Revision: https://reviews.llvm.org/D141580
2023-01-17 16:04:35 -05:00
Roy Jacobson
6a763343e2 [Clang] Reject in-class defaulting of previously declared comparison operators
Comparison operators are not allowed to be defaulted if they were previously declared outside the class.
Pretty low-impact, but it's nice to reject this without a linking error.
Fixes https://github.com/llvm/llvm-project/issues/51227.

Reviewed By: #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D141803
2023-01-17 22:29:51 +02:00
Aaron Ballman
f1f0a0d8e8 Diagnose extensions in 'offsetof'
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof.
Clang supports defining a type as the first argument as a conforming
extension due to how many projects use the construct in C99 and earlier
to calculate the alignment of a type. GCC also supports defining a type
as the first argument.

This adds extension warnings and documentation for the functionality
Clang explicitly supports.

Fixes #57065

Co-authored-by: Yingchi Long <i@lyc.dev>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2023-01-17 14:30:57 -05:00
Yingchi Long
596f76a799
Revert "[C2x] reject type definitions in offsetof"
This reverts commit e327b52766ed497e4779f4e652b9ad237dfda8e6.
2023-01-16 16:52:50 +08:00
Kazu Hirata
6ad0788c33 [clang] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<.  I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 12:31:01 -08:00
Kazu Hirata
a1580d7b59 [clang] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-14 11:07:21 -08:00
Yingchi Long
e327b52766
[C2x] reject type definitions in offsetof
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very
clear that it is an UB having type definitions with in offsetof. After
this patch clang will reject any type definitions in __builtin_offsetof.

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

```
local/offsetof.c:10:38: error: 'struct S' cannot be defined in '__builtin_offsetof'
    return __builtin_offsetof(struct S{ int a, b;}, a);
                                     ^
```

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D133574
2023-01-13 15:33:26 +08:00
Corentin Jabot
e1111e2056 [Clang] Correctly capture bindings in dependent lambdas.
Structured bindings were not properly marked odr-used
and therefore captured in generic lambddas.

Fixes #57826

It is unclear to me if further simplification can be gained
through the allowance described in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0588r1.html.

Either way, I think this makes support for P0588 completes,
but we probably want to add test for that in a separate PR.
(and I lack confidence I understand P0588 sufficiently to assert
the completeness of our cnformance).

Reviewed By: aaron.ballman, #clang-language-wg

Differential Revision: https://reviews.llvm.org/D137244
2023-01-09 21:20:57 +01:00
serge-sans-paille
a3c248db87
Move from llvm::makeArrayRef to ArrayRef deduction guides - clang/ part
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.

Differential Revision: https://reviews.llvm.org/D141139
2023-01-09 12:15:24 +01:00
Corentin Jabot
ca61961380 Implement CWG2631
Implement https://cplusplus.github.io/CWG/issues/2631.html.

Immediate calls in default arguments and defaults members
are not evaluated.

Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.

The immediate calls are executed by doing a
transform on the initializing expression.

Note that lambdas are not considering subexpressions so
we do not need to transform them.

As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.

Reviewed By: aaron.ballman, #clang-language-wg, rupprecht

Differential Revision: https://reviews.llvm.org/D136554
2023-01-08 10:35:26 +01:00
Roy Jacobson
91fefaa62e Revert "[Sema] Don't mark deleted special member functions as non-trivial"
This reverts commit d5dd37ac139a74701e16f084eb2609ff58893770.

Apparently there's some ABI difference in the Sony builder that fails a test.
Will hopefully investigate tomorrow. https://lab.llvm.org/buildbot/#/builders/139/builds/33769
2023-01-04 22:39:04 +02:00
Roy Jacobson
d5dd37ac13 [Sema] Don't mark deleted special member functions as non-trivial
As noted in https://github.com/llvm/llvm-project/issues/59624, we sometimes mark implicitly
deleted special member functions as non-trivial. This is unnecessary work and leads to some
weird type traits errors.

This fixes the problem by making the implicitly deleted special member functions always
trivial.

Reviewed By: #clang-language-wg, erichkeane

Differential Revision: https://reviews.llvm.org/D140664
2023-01-04 21:27:04 +02:00