2022-02-01 23:13:01 -08:00
|
|
|
===========================================
|
|
|
|
Clang |release| |ReleaseNotesTitle|
|
|
|
|
===========================================
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
.. contents::
|
|
|
|
:local:
|
|
|
|
:depth: 2
|
|
|
|
|
|
|
|
Written by the `LLVM Team <https://llvm.org/>`_
|
|
|
|
|
2022-02-01 23:13:01 -08:00
|
|
|
.. only:: PreRelease
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2022-02-01 23:13:01 -08:00
|
|
|
.. warning::
|
|
|
|
These are in-progress notes for the upcoming Clang |version| release.
|
|
|
|
Release notes for previous releases can be found on
|
2023-03-05 00:56:15 +02:00
|
|
|
`the Releases Page <https://llvm.org/releases/>`_.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
Introduction
|
|
|
|
============
|
|
|
|
|
|
|
|
This document contains the release notes for the Clang C/C++/Objective-C
|
2022-02-01 23:13:01 -08:00
|
|
|
frontend, part of the LLVM Compiler Infrastructure, release |release|. Here we
|
2020-02-13 22:46:33 +01:00
|
|
|
describe the status of Clang in some detail, including major
|
|
|
|
improvements from the previous release and new feature work. For the
|
|
|
|
general LLVM release notes, see `the LLVM
|
2023-02-15 23:53:38 +02:00
|
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. For the libc++ release notes,
|
|
|
|
see `this page <https://libcxx.llvm.org/ReleaseNotes.html>`_. All LLVM releases
|
|
|
|
may be downloaded from the `LLVM releases web site <https://llvm.org/releases/>`_.
|
2020-02-13 22:46:33 +01:00
|
|
|
|
|
|
|
For more information about Clang or LLVM, including information about the
|
|
|
|
latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the
|
|
|
|
`LLVM Web Site <https://llvm.org>`_.
|
|
|
|
|
2022-09-15 07:29:49 -04:00
|
|
|
Potentially Breaking Changes
|
|
|
|
============================
|
|
|
|
These changes are ones which we think may surprise users when upgrading to
|
|
|
|
Clang |release| because of the opportunity they pose for disruption to existing
|
|
|
|
code bases.
|
|
|
|
|
2024-03-20 22:45:38 -07:00
|
|
|
- Setting the deprecated CMake variable ``GCC_INSTALL_PREFIX`` (which sets the
|
|
|
|
default ``--gcc-toolchain=``) now leads to a fatal error.
|
|
|
|
|
2024-07-12 06:55:49 -04:00
|
|
|
- The ``le32`` and ``le64`` targets have been removed.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C/C++ Language Potentially Breaking Changes
|
|
|
|
-------------------------------------------
|
2023-05-23 14:41:43 -07:00
|
|
|
|
2024-07-10 12:10:44 +02:00
|
|
|
- Clang now supports raw string literals in ``-std=gnuXY`` mode as an extension in
|
|
|
|
C99 and later. This behaviour can also be overridden using ``-f[no-]raw-string-literals``.
|
|
|
|
Support of raw string literals in C++ is not affected. Fixes (#GH85703).
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C++ Specific Potentially Breaking Changes
|
|
|
|
-----------------------------------------
|
2024-03-04 09:18:21 -05:00
|
|
|
- Clang now diagnoses function/variable templates that shadow their own template parameters, e.g. ``template<class T> void T();``.
|
|
|
|
This error can be disabled via `-Wno-strict-primary-template-shadow` for compatibility with previous versions of clang.
|
2024-01-19 15:08:39 +08:00
|
|
|
|
2024-05-02 02:02:35 -03:00
|
|
|
- The behavior controlled by the `-frelaxed-template-template-args` flag is now
|
|
|
|
on by default, and the flag is deprecated. Until the flag is finally removed,
|
|
|
|
it's negative spelling can be used to obtain compatibility with previous
|
2024-05-15 20:01:17 -03:00
|
|
|
versions of clang. The deprecation warning for the negative spelling can be
|
|
|
|
disabled with `-Wno-deprecated-no-relaxed-template-template-args`.
|
2024-05-02 02:02:35 -03:00
|
|
|
|
2024-05-03 16:20:42 +08:00
|
|
|
- Clang now rejects pointer to member from parenthesized expression in unevaluated context such as ``decltype(&(foo::bar))``. (#GH40906).
|
|
|
|
|
2024-05-15 21:52:59 -04:00
|
|
|
- Clang now performs semantic analysis for unary operators with dependent operands
|
|
|
|
that are known to be of non-class non-enumeration type prior to instantiation.
|
|
|
|
|
2024-05-22 18:32:25 +02:00
|
|
|
This change uncovered a bug in libstdc++ 14.1.0 which may cause compile failures
|
|
|
|
on systems using that version of libstdc++ and Clang 19, with an error that looks
|
|
|
|
something like this:
|
|
|
|
|
|
|
|
.. code-block:: text
|
|
|
|
|
|
|
|
<source>:4:5: error: expression is not assignable
|
|
|
|
4 | ++this;
|
|
|
|
| ^ ~~~~
|
|
|
|
|
|
|
|
To fix this, update libstdc++ to version 14.1.1 or greater.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
ABI Changes in This Version
|
|
|
|
---------------------------
|
2024-03-15 16:12:19 -07:00
|
|
|
- Fixed Microsoft name mangling of implicitly defined variables used for thread
|
|
|
|
safe static initialization of static local variables. This change resolves
|
|
|
|
incompatibilities with code compiled by MSVC but might introduce
|
|
|
|
incompatibilities with code compiled by earlier versions of Clang when an
|
|
|
|
inline member function that contains a static local variable with a dynamic
|
|
|
|
initializer is declared with ``__declspec(dllimport)``. (#GH83616).
|
2023-02-15 23:53:38 +02:00
|
|
|
|
2024-03-25 10:39:05 -04:00
|
|
|
- Fixed Microsoft name mangling of lifetime extended temporary objects. This
|
|
|
|
change corrects missing back reference registrations that could result in
|
|
|
|
incorrect back reference indexes and suprising demangled name results. Since
|
|
|
|
MSVC uses a different mangling for these objects, compatibility is not affected.
|
|
|
|
(#GH85423).
|
|
|
|
|
2024-04-29 12:00:12 -07:00
|
|
|
- Fixed Microsoft calling convention for returning certain classes with a
|
|
|
|
templated constructor. If a class has a templated constructor, it should
|
|
|
|
be returned indirectly even if it meets all the other requirements for
|
|
|
|
returning a class in a register. This affects some uses of std::pair.
|
|
|
|
(#GH86384).
|
|
|
|
|
2024-05-07 19:46:19 -04:00
|
|
|
- Fixed Microsoft calling convention when returning classes that have a deleted
|
|
|
|
copy assignment operator. Such a class should be returned indirectly.
|
|
|
|
|
2024-06-24 12:01:48 +01:00
|
|
|
- Removed the global alias that was pointing to AArch64 Function Multiversioning
|
|
|
|
ifuncs. Its purpose was to preserve backwards compatibility when the ".ifunc"
|
|
|
|
suffix got removed from the name mangling. The alias interacts badly with
|
|
|
|
GlobalOpt (see the issue #96197).
|
2024-07-11 17:58:15 +02:00
|
|
|
|
2024-06-20 19:49:17 -07:00
|
|
|
- Fixed Microsoft name mangling for auto non-type template arguments of pointer
|
|
|
|
type for MSVC 1920+. This change resolves incompatibilities with code compiled
|
|
|
|
by MSVC 1920+ but will introduce incompatibilities with code compiled by
|
|
|
|
earlier versions of Clang unless such code is built with the compiler option
|
|
|
|
`-fms-compatibility-version=19.14` to imitate the MSVC 1914 mangling behavior.
|
|
|
|
|
2024-07-04 10:17:32 -07:00
|
|
|
- Fixed Microsoft name mangling for auto non-type template arguments of pointer
|
|
|
|
to member type for MSVC 1920+. This change resolves incompatibilities with code
|
|
|
|
compiled by MSVC 1920+ but will introduce incompatibilities with code compiled by
|
|
|
|
earlier versions of Clang unless such code is built with the compiler option
|
|
|
|
`-fms-compatibility-version=19.14` to imitate the MSVC 1914 mangling behavior.
|
|
|
|
(GH#70899).
|
|
|
|
|
2023-10-26 19:28:28 +01:00
|
|
|
AST Dumping Potentially Breaking Changes
|
|
|
|
----------------------------------------
|
|
|
|
|
2024-05-29 15:23:44 -03:00
|
|
|
- The text ast-dumper has improved printing of TemplateArguments.
|
2024-06-27 18:49:58 +08:00
|
|
|
- The text decl-dumper prints template parameters' trailing requires expressions now.
|
2024-05-29 15:23:44 -03:00
|
|
|
|
2024-01-30 09:30:20 -08:00
|
|
|
Clang Frontend Potentially Breaking Changes
|
|
|
|
-------------------------------------------
|
2024-04-16 17:26:55 -04:00
|
|
|
- Removed support for constructing on-stack ``TemplateArgumentList``\ s; interfaces should instead
|
2024-02-01 11:50:50 -05:00
|
|
|
use ``ArrayRef<TemplateArgument>`` to pass template arguments. Transitioning internal uses to
|
|
|
|
``ArrayRef<TemplateArgument>`` reduces AST memory usage by 0.4% when compiling clang, and is
|
|
|
|
expected to show similar improvements on other workloads.
|
2024-01-30 09:30:20 -08:00
|
|
|
|
2024-02-14 09:08:28 -05:00
|
|
|
- The ``-Wgnu-binary-literal`` diagnostic group no longer controls any
|
|
|
|
diagnostics. Binary literals are no longer a GNU extension, they're now a C23
|
|
|
|
extension which is controlled via ``-pedantic`` or ``-Wc23-extensions``. Use
|
|
|
|
of ``-Wno-gnu-binary-literal`` will no longer silence this pedantic warning,
|
|
|
|
which may break existing uses with ``-Werror``.
|
|
|
|
|
2024-05-02 08:44:32 +01:00
|
|
|
- The normalization of 3 element target triples where ``-none-`` is the middle
|
|
|
|
element has changed. For example, ``armv7m-none-eabi`` previously normalized
|
|
|
|
to ``armv7m-none-unknown-eabi``, with ``none`` for the vendor and ``unknown``
|
|
|
|
for the operating system. It now normalizes to ``armv7m-unknown-none-eabi``,
|
|
|
|
which has ``unknown`` vendor and ``none`` operating system.
|
|
|
|
|
|
|
|
The affected triples are primarily for bare metal Arm where it is intended
|
|
|
|
that ``none`` means that there is no operating system. As opposed to an unknown
|
|
|
|
type of operating system.
|
|
|
|
|
|
|
|
This change my cause clang to not find libraries, or libraries to be built at
|
|
|
|
different file system locations. This can be fixed by changing your builds to
|
|
|
|
use the new normalized triple. However, we recommend instead getting the
|
|
|
|
normalized triple from clang itself, as this will make your builds more
|
|
|
|
robust in case of future changes::
|
|
|
|
|
|
|
|
$ clang --target=<your target triple> -print-target-triple
|
|
|
|
<the normalized target triple>
|
|
|
|
|
2024-05-14 16:09:57 -04:00
|
|
|
- The ``hasTypeLoc`` AST matcher will no longer match a ``classTemplateSpecializationDecl``;
|
|
|
|
existing uses should switch to ``templateArgumentLoc`` or ``hasAnyTemplateArgumentLoc`` instead.
|
|
|
|
|
2024-06-14 11:19:28 +02:00
|
|
|
Clang Python Bindings Potentially Breaking Changes
|
|
|
|
--------------------------------------------------
|
|
|
|
- Renamed ``CursorKind`` variant 272 from ``OMP_TEAMS_DISTRIBUTE_DIRECTIVE``
|
|
|
|
to ``OMP_TEAMS_DISTRIBUTE_SIMD_DIRECTIVE``. The previous name was incorrect, it was a duplicate
|
|
|
|
of variant 271.
|
|
|
|
- Renamed ``TypeKind`` variant 162 from ``OBJCCLASS`` to ``OBJCTYPEPARAM``.
|
|
|
|
The previous name was incorrect, it was a duplicate of variant 28.
|
2024-07-12 11:03:17 +02:00
|
|
|
- Refactored enum implementation, switching to the standard library `Enum` type.
|
2024-06-14 11:19:28 +02:00
|
|
|
|
2022-02-01 23:13:01 -08:00
|
|
|
What's New in Clang |release|?
|
|
|
|
==============================
|
2020-02-13 22:46:33 +01:00
|
|
|
Some of the major new features and improvements to Clang are listed
|
|
|
|
here. Generic improvements to Clang as a whole or to its underlying
|
|
|
|
infrastructure are described first, followed by language-specific
|
|
|
|
sections with improvements to Clang's support for those languages.
|
|
|
|
|
[Clang][Comments] Support for parsing headers in Doxygen \par commands (#91100)
### Background
Doxygen's `\par` command
([link](https://www.doxygen.nl/manual/commands.html#cmdpar)) has an
optional argument, which denotes the header of the paragraph started by
a given `\par` command.
In short, the paragraph command can be used with a heading, or without
one. The code block below shows both forms and how the current version
of LLVM/Clang parses this code:
```
$ cat test.cpp
/// \par User defined paragraph:
/// Contents of the paragraph.
///
/// \par
/// New paragraph under the same heading.
///
/// \par
/// A second paragraph.
class A {};
$ clang++ -cc1 -ast-dump -fcolor-diagnostics -std=c++20 test.cpp
`-CXXRecordDecl 0x1530f3a78 <test.cpp:11:1, col:10> col:7 class A definition
|-FullComment 0x1530fea38 <line:2:4, line:9:23>
| |-ParagraphComment 0x1530fe7e0 <line:2:4>
| | `-TextComment 0x1530fe7b8 <col:4> Text=" "
| |-BlockCommandComment 0x1530fe800 <col:5, line:3:30> Name="par"
| | `-ParagraphComment 0x1530fe878 <line:2:9, line:3:30>
| | |-TextComment 0x1530fe828 <line:2:9, col:32> Text=" User defined paragraph:"
| | `-TextComment 0x1530fe848 <line:3:4, col:30> Text=" Contents of the paragraph."
| |-ParagraphComment 0x1530fe8c0 <line:5:4>
| | `-TextComment 0x1530fe898 <col:4> Text=" "
| |-BlockCommandComment 0x1530fe8e0 <col:5, line:6:41> Name="par"
| | `-ParagraphComment 0x1530fe930 <col:4, col:41>
| | `-TextComment 0x1530fe908 <col:4, col:41> Text=" New paragraph under the same heading."
| |-ParagraphComment 0x1530fe978 <line:8:4>
| | `-TextComment 0x1530fe950 <col:4> Text=" "
| `-BlockCommandComment 0x1530fe998 <col:5, line:9:23> Name="par"
| `-ParagraphComment 0x1530fe9e8 <col:4, col:23>
| `-TextComment 0x1530fe9c0 <col:4, col:23> Text=" A second paragraph."
`-CXXRecordDecl 0x1530f3bb0 <line:11:1, col:7> col:7 implicit class A
```
As we can see above, the optional paragraph heading (`"User defined
paragraph"`) is not an argument of the `\par` `BlockCommandComment`, but
instead a child `TextComment`.
For documentation generators like [hdoc](https://hdoc.io/), it would be
ideal if we could parse Doxygen documentation comments with these
semantics in mind. Currently that's not possible.
### Change
This change parses `\par` command according to how Doxygen parses them,
making an optional header available as a an argument if it is present.
In addition:
- AST unit tests are defined to test this functionality when an argument
is present, isn't present, with additional spacing, etc.
- TableGen is updated with an `IsParCommand` to support this
functionality
- `lit` tests are updated where needed
2024-06-20 09:14:51 -07:00
|
|
|
- The ``\par`` documentation comment command now supports an optional
|
|
|
|
argument, which denotes the header of the paragraph started by
|
|
|
|
an instance of the ``\par`` command comment. The implementation
|
|
|
|
of the argument handling matches its semantics
|
|
|
|
`in Doxygen <https://www.doxygen.nl/manual/commands.html#cmdpar>`.
|
|
|
|
Namely, any text on the same line as the ``\par`` command will become
|
|
|
|
a header for the paragaph, and if there is no text then the command
|
|
|
|
will start a new paragraph.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C++ Language Changes
|
|
|
|
--------------------
|
2024-05-02 02:02:35 -03:00
|
|
|
- C++17 support is now completed, with the enablement of the
|
|
|
|
relaxed temlate template argument matching rules introduced in P0522,
|
|
|
|
which was retroactively applied as a defect report.
|
|
|
|
While the implementation already existed since Clang 4, it was turned off by
|
|
|
|
default, and was controlled with the `-frelaxed-template-template-args` flag.
|
|
|
|
In this release, we implement provisional wording for a core defect on
|
|
|
|
P0522 (CWG2398), which avoids the most serious compatibility issues caused
|
|
|
|
by it, allowing us to enable it by default in this release.
|
|
|
|
The flag is now deprecated, and will be removed in the next release, but can
|
|
|
|
still be used to turn it off and regain compatibility with previous versions
|
|
|
|
(#GH36505).
|
2024-04-22 14:42:57 -04:00
|
|
|
- Implemented ``_BitInt`` literal suffixes ``__wb`` or ``__WB`` as a Clang extension with ``unsigned`` modifiers also allowed. (#GH85223).
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-04-26 12:05:15 -04:00
|
|
|
C++17 Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE``
|
|
|
|
predefined macros to support standard library implementations of
|
|
|
|
``std::hardware_destructive_interference_size`` and
|
|
|
|
``std::hardware_constructive_interference_size``, respectively. These macros
|
|
|
|
are predefined in all C and C++ language modes. The values the macros
|
|
|
|
expand to are not stable between releases of Clang and do not need to match
|
|
|
|
the values produced by GCC, so these macros should not be used from header
|
|
|
|
files because they may not be stable across multiple TUs (the values may vary
|
|
|
|
based on compiler version as well as CPU tuning). #GH60174
|
|
|
|
|
2024-05-22 12:37:27 +08:00
|
|
|
C++14 Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
- Sized deallocation is enabled by default in C++14 onwards. The user may specify
|
|
|
|
``-fno-sized-deallocation`` to disable it if there are some regressions.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C++20 Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2022-03-12 20:49:01 +01:00
|
|
|
|
2024-01-29 11:42:08 +08:00
|
|
|
- Clang won't perform ODR checks for decls in the global module fragment any
|
|
|
|
more to ease the implementation and improve the user's using experience.
|
2024-02-01 13:44:32 +08:00
|
|
|
This follows the MSVC's behavior. Users interested in testing the more strict
|
|
|
|
behavior can use the flag '-Xclang -fno-skip-odr-check-in-gmf'.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH79240).
|
2024-01-29 11:42:08 +08:00
|
|
|
|
2024-04-13 08:55:09 +04:00
|
|
|
- Implemented the `__is_layout_compatible` and `__is_pointer_interconvertible_base_of`
|
|
|
|
intrinsics to support
|
2024-02-20 16:54:51 +04:00
|
|
|
`P0466R5: Layout-compatibility and Pointer-interconvertibility Traits <https://wg21.link/P0466R5>`_.
|
|
|
|
|
2024-03-06 15:34:37 +08:00
|
|
|
- Clang now implements [module.import]p7 fully. Clang now will import module
|
|
|
|
units transitively for the module units coming from the same module of the
|
2024-04-16 09:00:57 -04:00
|
|
|
current module units. Fixes #GH84002
|
2024-03-06 15:34:37 +08:00
|
|
|
|
2024-03-08 14:24:03 +01:00
|
|
|
- Initial support for class template argument deduction (CTAD) for type alias
|
|
|
|
templates (`P1814R0 <https://wg21.link/p1814r0>`_).
|
|
|
|
(#GH54051).
|
|
|
|
|
2024-04-09 06:59:31 -07:00
|
|
|
- We have sufficient confidence and experience with the concepts implementation
|
|
|
|
to update the ``__cpp_concepts`` macro to `202002L`. This enables
|
|
|
|
``<expected>`` from libstdc++ to work correctly with Clang.
|
|
|
|
|
[Sema][CTAD] Allow user defined conversion for copy-list-initialization (#94752)
Fixes #62925.
The following code:
```cpp
#include <map>
int main() {
std::map m1 = {std::pair{"foo", 2}, {"bar", 3}}; // guide #2
std::map m2(m1.begin(), m1.end()); // guide #1
}
```
Is rejected by clang, but accepted by both gcc and msvc:
https://godbolt.org/z/6v4fvabb5 .
So basically CTAD with copy-list-initialization is rejected.
Note that this exact code is also used in a cppreference article:
https://en.cppreference.com/w/cpp/container/map/deduction_guides
I checked the C++11 and C++20 standard drafts to see whether suppressing
user conversion is the correct thing to do for user conversions. Based
on the standard I don't think that it is correct.
```
13.3.1.4 Copy-initialization of class by user-defined conversion [over.match.copy]
Under the conditions specified in 8.5, as part of a copy-initialization of an object of class type, a user-defined
conversion can be invoked to convert an initializer expression to the type of the object being initialized.
Overload resolution is used to select the user-defined conversion to be invoked
```
So we could use user defined conversions according to the standard.
```
If a narrowing conversion is required to initialize any of the elements, the
program is ill-formed.
```
We should not do narrowing.
```
In copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed.
```
We should not use explicit constructors.
2024-06-18 20:45:23 +02:00
|
|
|
- User defined constructors are allowed for copy-list-initialization with CTAD.
|
|
|
|
(#GH62925).
|
|
|
|
|
2023-04-30 15:27:00 +02:00
|
|
|
C++23 Feature Support
|
2023-02-15 23:53:38 +02:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
2023-12-07 14:52:10 +01:00
|
|
|
|
2024-01-30 06:48:14 +08:00
|
|
|
- Implemented `P2718R0: Lifetime extension in range-based for loops <https://wg21.link/P2718R0>`_. Also
|
|
|
|
materialize temporary object which is a prvalue in discarded-value expression.
|
2024-03-09 12:07:16 +01:00
|
|
|
- Implemented `P1774R8: Portable assumptions <https://wg21.link/P1774R8>`_.
|
2024-01-30 06:48:14 +08:00
|
|
|
|
2024-03-13 16:15:01 -07:00
|
|
|
- Implemented `P2448R2: Relaxing some constexpr restrictions <https://wg21.link/P2448R2>`_.
|
2024-06-04 13:32:11 -04:00
|
|
|
Note, the ``-Winvalid-constexpr`` diagnostic is now disabled in C++23 mode,
|
|
|
|
but can be explicitly specified to retain the old diagnostic checking
|
|
|
|
behavior.
|
2024-03-13 16:15:01 -07:00
|
|
|
|
2024-05-10 08:50:44 +02:00
|
|
|
- Added a ``__reference_converts_from_temporary`` builtin, completing the necessary compiler support for
|
|
|
|
`P2255R2: Type trait to determine if a reference binds to a temporary <https://wg21.link/P2255R2>`_.
|
|
|
|
|
2024-06-05 16:50:42 +02:00
|
|
|
- Implemented `P2797R0: Static and explicit object member functions with the same parameter-type-lists <https://wg21.link/P2797R0>`_.
|
|
|
|
This completes the support for "deducing this".
|
|
|
|
|
2023-05-12 07:30:21 -07:00
|
|
|
C++2c Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
2024-01-27 10:23:38 +01:00
|
|
|
- Implemented `P2662R3 Pack Indexing <https://wg21.link/P2662R3>`_.
|
|
|
|
|
2024-04-14 12:30:01 +02:00
|
|
|
- Implemented `P2573R2: = delete("should have a reason"); <https://wg21.link/P2573R2>`_
|
|
|
|
|
2024-04-28 20:25:44 +02:00
|
|
|
- Implemented `P0609R3: Attributes for Structured Bindings <https://wg21.link/P0609R3>`_
|
|
|
|
|
2024-04-29 22:00:10 +08:00
|
|
|
- Implemented `P2748R5 Disallow Binding a Returned Glvalue to a Temporary <https://wg21.link/P2748R5>`_.
|
2024-01-27 10:23:38 +01:00
|
|
|
|
2024-05-03 14:10:54 +02:00
|
|
|
- Implemented `P2809R3: Trivial infinite loops are not Undefined Behavior <https://wg21.link/P2809R3>`_.
|
|
|
|
|
2024-07-05 22:27:04 +04:00
|
|
|
- Implemented `P3144R2 Deleting a Pointer to an Incomplete Type Should be Ill-formed <https://wg21.link/P3144R2>`_.
|
2024-05-03 14:10:54 +02:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Resolutions to C++ Defect Reports
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
[Sema] Substitute parameter packs when deduced from function arguments (#79371)
This pull request would solve
https://github.com/llvm/llvm-project/issues/78449 .
There is also a discussion about this on stackoverflow:
https://stackoverflow.com/questions/77832658/stdtype-identity-to-support-several-variadic-argument-lists
.
The following program is well formed:
```cpp
#include <type_traits>
template <typename... T>
struct args_tag
{
using type = std::common_type_t<T...>;
};
template <typename... T>
void bar(args_tag<T...>, std::type_identity_t<T>..., int, std::type_identity_t<T>...) {}
// example
int main() {
bar(args_tag<int, int>{}, 4, 8, 15, 16, 23);
}
```
but Clang rejects it, while GCC and MSVC doesn't. The reason for this is
that, in `Sema::DeduceTemplateArguments` we are not prepared for this
case.
# Substitution/deduction of parameter packs
The logic that handles substitution when we have explicit template
arguments (`SubstituteExplicitTemplateArguments`) does not work here,
since the types of the pack are not pushed to `ParamTypes` before the
loop starts that does the deduction.
The other "candidate" that may could have handle this case would be the
loop that does the deduction for trailing packs, but we are not dealing
with trailing packs here.
# Solution proposed in this PR
The solution proposed in this PR works similar to the trailing pack
deduction. The main difference here is the end of the deduction cycle.
When a non-trailing template pack argument is found, whose type is not
explicitly specified and the next type is not a pack type, the length of
the previously deduced pack is retrieved (let that length be `s`). After
that the next `s` arguments are processed in the same way as in the case
of non trailing packs.
# Another possible solution
There is another possible approach that would be less efficient. In the
loop when we get to an element of `ParamTypes` that is a pack and could
be substituted because the type is deduced from a previous argument,
then `s` number of arg types would be inserted before the current
element of `ParamTypes` type. Then we would "cancel" the processing of
the current element, first process the previously inserted elements and
the after that re-process the current element.
Basically we would do what `SubstituteExplicitTemplateArguments` does
but during deduction.
# Adjusted test cases
In
`clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.call/p1-0x.cpp`
there is a test case named `test_pack_not_at_end` that should work, but
still does not. This test case is relevant because the note for the
error message has changed.
This is what the test case looks like currently:
```cpp
template<typename ...Types>
void pack_not_at_end(tuple<Types...>, Types... values, int); // expected-note {{<int *, double *> vs. <int, int>}}
void test_pack_not_at_end(tuple<int*, double*> t2) {
pack_not_at_end(t2, 0, 0, 0); // expected-error {{no match}}
// FIXME: Should the "original argument type must match deduced parameter
// type" rule apply here?
pack_not_at_end<int*, double*>(t2, 0, 0, 0); // ok
}
```
The previous note said (before my changes):
```
deduced conflicting types for parameter 'Types' (<int *, double *> vs. <>)
````
The current note says (after my changesand also clang 14 would say this
if the pack was not trailing):
```
deduced conflicting types for parameter 'Types' (<int *, double *> vs. <int, int>)
```
GCC says:
```
error: no matching function for call to ‘pack_not_at_end(std::tuple<int*, double*>&, int, int, int)’
70 | pack_not_at_end(t2, 0, 0, 9); // expected-error {{no match}}
````
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: Erich Keane <ekeane@nvidia.com>
2024-01-27 10:43:38 +01:00
|
|
|
- Substitute template parameter pack, when it is not explicitly specified
|
2024-04-16 09:00:57 -04:00
|
|
|
in the template parameters, but is deduced from a previous argument. (#GH78449)
|
2024-01-17 06:16:12 +01:00
|
|
|
|
2024-02-21 19:02:20 +04:00
|
|
|
- Type qualifications are now ignored when evaluating layout compatibility
|
|
|
|
of two types.
|
|
|
|
(`CWG1719: Layout compatibility and cv-qualification revisited <https://cplusplus.github.io/CWG/issues/1719.html>`_).
|
|
|
|
|
2024-03-08 11:31:00 +04:00
|
|
|
- Alignment of members is now respected when evaluating layout compatibility
|
|
|
|
of structs.
|
|
|
|
(`CWG2583: Common initial sequence should consider over-alignment <https://cplusplus.github.io/CWG/issues/2583.html>`_).
|
|
|
|
|
2024-02-22 22:30:31 +04:00
|
|
|
- ``[[no_unique_address]]`` is now respected when evaluating layout
|
|
|
|
compatibility of two types.
|
|
|
|
(`CWG2759: [[no_unique_address] and common initial sequence <https://cplusplus.github.io/CWG/issues/2759.html>`_).
|
|
|
|
|
2024-04-11 11:23:24 -04:00
|
|
|
- Clang now diagnoses declarative nested-name-specifiers with pack-index-specifiers.
|
|
|
|
(`CWG2858: Declarative nested-name-specifiers and pack-index-specifiers <https://cplusplus.github.io/CWG/issues/2858.html>`_).
|
|
|
|
|
2024-05-17 16:02:44 +04:00
|
|
|
- Clang now allows attributes on concepts.
|
|
|
|
(`CWG2428: Deprecating a concept <https://cplusplus.github.io/CWG/issues/2428.html>`_).
|
|
|
|
|
2024-05-02 02:02:35 -03:00
|
|
|
- P0522 implementation is enabled by default in all language versions, and
|
|
|
|
provisional wording for CWG2398 is implemented.
|
|
|
|
|
2024-06-21 13:49:43 +04:00
|
|
|
- Clang now performs type-only lookup for the name in ``using enum`` declaration.
|
|
|
|
(`CWG2877: Type-only lookup for using-enum-declarator <https://cplusplus.github.io/CWG/issues/2877.html>`_).
|
|
|
|
|
2024-05-31 11:02:21 -07:00
|
|
|
- Clang now requires a template argument list after a template keyword.
|
|
|
|
(`CWG96: Syntactic disambiguation using the template keyword <https://cplusplus.github.io/CWG/issues/96.html>`_).
|
|
|
|
|
2024-06-17 18:31:54 +01:00
|
|
|
- Clang now considers ``noexcept(typeid(expr))`` more carefully, instead of always assuming that ``std::bad_typeid`` can be thrown.
|
|
|
|
(`CWG2191: Incorrect result for noexcept(typeid(v)) <https://cplusplus.github.io/CWG/issues/2191.html>`_).
|
|
|
|
|
2024-07-11 18:49:35 -04:00
|
|
|
- Clang now correctly implements lookup for the terminal name of a member-qualified nested-name-specifier.
|
|
|
|
(`CWG1835: Dependent member lookup before < <https://cplusplus.github.io/CWG/issues/1835.html>`_).
|
2024-07-12 13:14:41 +02:00
|
|
|
The warning can be disabled via `-Wno-missing-dependent-template-keyword`.
|
2024-07-11 18:49:35 -04:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
C Language Changes
|
|
|
|
------------------
|
|
|
|
|
2024-07-02 06:58:41 -04:00
|
|
|
C2y Feature Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
- Clang now enables C2y mode with ``-std=c2y``. This sets ``__STDC_VERSION__``
|
|
|
|
to ``202400L`` so that it's greater than the value for C23. The value of this
|
|
|
|
macro is subject to change in the future.
|
|
|
|
|
2023-08-10 14:18:36 -04:00
|
|
|
C23 Feature Support
|
2023-02-15 23:53:38 +02:00
|
|
|
^^^^^^^^^^^^^^^^^^^
|
2024-02-14 09:08:28 -05:00
|
|
|
- No longer diagnose use of binary literals as an extension in C23 mode. Fixes
|
2024-03-04 14:22:51 +01:00
|
|
|
#GH72017.
|
2023-11-20 10:52:11 -05:00
|
|
|
|
2024-02-15 07:58:01 -05:00
|
|
|
- Corrected parsing behavior for the ``alignas`` specifier/qualifier in C23. We
|
|
|
|
previously handled it as an attribute as in C++, but there are parsing
|
|
|
|
differences. The behavioral differences are:
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
struct alignas(8) /* was accepted, now rejected */ S {
|
|
|
|
char alignas(8) /* was rejected, now accepted */ C;
|
|
|
|
};
|
|
|
|
int i alignas(8) /* was accepted, now rejected */ ;
|
|
|
|
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH81472).
|
2024-02-15 07:58:01 -05:00
|
|
|
|
2024-02-20 09:32:23 -05:00
|
|
|
- Clang now generates predefined macros of the form ``__TYPE_FMTB__`` and
|
|
|
|
``__TYPE_FMTb__`` (e.g., ``__UINT_FAST64_FMTB__``) in C23 mode for use with
|
2024-04-16 09:00:57 -04:00
|
|
|
macros typically exposed from ``<inttypes.h>``, such as ``PRIb8``. (#GH81896)
|
2024-02-20 09:32:23 -05:00
|
|
|
|
2024-03-06 11:46:35 +03:00
|
|
|
- Clang now supports `N3018 The constexpr specifier for object definitions`
|
|
|
|
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm>`_.
|
|
|
|
|
2024-04-22 11:59:54 -04:00
|
|
|
- Properly promote bit-fields of bit-precise integer types to the field's type
|
|
|
|
rather than to ``int``. #GH87641
|
|
|
|
|
2024-07-03 07:23:44 -04:00
|
|
|
- Added the ``INFINITY`` and ``NAN`` macros to Clang's ``<float.h>``
|
|
|
|
freestanding implementation; these macros were defined in ``<math.h>`` in C99
|
|
|
|
but C23 added them to ``<float.h>`` in
|
|
|
|
`WG14 N2848 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2848.pdf>`_.
|
|
|
|
|
2024-07-09 09:15:46 +02:00
|
|
|
- Clang now supports `N3017 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm>`_
|
|
|
|
``#embed`` - a scannable, tooling-friendly binary resource inclusion mechanism.
|
|
|
|
|
2024-07-10 09:49:21 -04:00
|
|
|
- Added the ``FLT_NORM_MAX``, ``DBL_NORM_MAX``, and ``LDBL_NORM_MAX`` to the
|
|
|
|
freestanding implementation of ``<float.h>`` that ships with Clang.
|
|
|
|
|
2022-08-26 10:04:06 -04:00
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
-------------------------------------------------
|
2022-08-26 09:17:14 -04:00
|
|
|
|
2024-02-13 10:06:25 -06:00
|
|
|
- Added ``__builtin_readsteadycounter`` for reading fixed frequency hardware
|
|
|
|
counters.
|
|
|
|
|
2024-02-15 09:41:19 -06:00
|
|
|
- ``__builtin_addc``, ``__builtin_subc``, and the other sizes of those
|
|
|
|
builtins are now constexpr and may be used in constant expressions.
|
|
|
|
|
2024-03-08 00:01:37 +00:00
|
|
|
- Added ``__builtin_popcountg`` as a type-generic alternative to
|
|
|
|
``__builtin_popcount{,l,ll}`` with support for any unsigned integer type. Like
|
|
|
|
the previous builtins, this new builtin is constexpr and may be used in
|
|
|
|
constant expressions.
|
|
|
|
|
2024-03-21 12:57:24 +01:00
|
|
|
- Lambda expressions are now accepted in C++03 mode as an extension.
|
|
|
|
|
2024-03-26 20:22:47 +00:00
|
|
|
- Added ``__builtin_clzg`` and ``__builtin_ctzg`` as type-generic alternatives
|
|
|
|
to ``__builtin_clz{,s,l,ll}`` and ``__builtin_ctz{,s,l,ll}`` respectively,
|
|
|
|
with support for any unsigned integer type. Like the previous builtins, these
|
|
|
|
new builtins are constexpr and may be used in constant expressions.
|
|
|
|
|
2024-04-03 18:39:53 +02:00
|
|
|
- ``__typeof_unqual__`` is available in all C modes as an extension, which behaves
|
|
|
|
like ``typeof_unqual`` from C23, similar to ``__typeof__`` and ``typeof``.
|
|
|
|
|
2024-04-29 16:45:33 +02:00
|
|
|
- ``__builtin_reduce_{add|mul|xor|or|and|min|max}`` builtins now support scalable vectors.
|
2024-04-25 10:57:32 -07:00
|
|
|
|
|
|
|
* Shared libraries linked with either the ``-ffast-math``, ``-Ofast``, or
|
|
|
|
``-funsafe-math-optimizations`` flags will no longer enable flush-to-zero
|
|
|
|
floating-point mode by default. This decision can be overridden with use of
|
|
|
|
``-mdaz-ftz``. This behavior now matches GCC's behavior.
|
|
|
|
(`#57589 <https://github.com/llvm/llvm-project/issues/57589>`_)
|
|
|
|
|
|
|
|
* ``-fdenormal-fp-math=preserve-sign`` is no longer implied by ``-ffast-math``
|
|
|
|
on x86 systems.
|
|
|
|
|
2024-04-29 08:59:02 -07:00
|
|
|
- Builtins ``__builtin_shufflevector()`` and ``__builtin_convertvector()`` may
|
|
|
|
now be used within constant expressions.
|
|
|
|
|
2024-06-04 13:32:11 -04:00
|
|
|
- When compiling a constexpr function, Clang will check to see whether the
|
|
|
|
function can *never* be used in a constant expression context and issues a
|
|
|
|
diagnostic under the ``-Winvalid-constexpr`` diagostic flag (which defaults
|
|
|
|
to an error). This check can be expensive because the mere presence of a
|
|
|
|
function marked ``constexpr`` will cause us to undergo constant expression
|
|
|
|
evaluation, even if the function is not called within the translation unit
|
|
|
|
being compiled. Due to the expense, Clang no longer checks constexpr function
|
|
|
|
bodies when the function is defined in a system header file or when
|
|
|
|
``-Winvalid-constexpr`` is not enabled for the function definition, which
|
|
|
|
should result in mild compile-time performance improvements.
|
|
|
|
|
2024-06-06 07:28:02 +02:00
|
|
|
- Added ``__is_bitwise_cloneable`` which is used to check whether a type
|
|
|
|
can be safely copied by memcpy/memmove.
|
|
|
|
|
2024-06-14 09:57:21 -07:00
|
|
|
- ``#pragma GCC diagnostic warning "-Wfoo"`` can now downgrade ``-Werror=foo``
|
|
|
|
errors and certain default-to-error ``-W`` diagnostics to warnings.
|
|
|
|
|
2024-07-02 15:58:56 +02:00
|
|
|
- Support importing C++20 modules in clang-repl.
|
|
|
|
|
|
|
|
- Added support for ``TypeLoc::dump()`` for easier debugging, and improved
|
|
|
|
textual and JSON dumping for various ``TypeLoc``-related nodes.
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
New Compiler Flags
|
|
|
|
------------------
|
2024-04-08 21:30:27 +02:00
|
|
|
- ``-fsanitize=implicit-bitfield-conversion`` checks implicit truncation and
|
|
|
|
sign change.
|
|
|
|
- ``-fsanitize=implicit-integer-conversion`` a group that replaces the previous
|
|
|
|
group ``-fsanitize=implicit-conversion``.
|
2023-09-28 07:18:11 -07:00
|
|
|
|
2024-03-05 19:27:58 +03:00
|
|
|
- ``-Wmissing-designated-field-initializers``, grouped under ``-Wmissing-field-initializers``.
|
|
|
|
This diagnostic can be disabled to make ``-Wmissing-field-initializers`` behave
|
2024-04-16 09:00:57 -04:00
|
|
|
like it did before Clang 18.x. Fixes #GH56628
|
2024-03-05 19:27:58 +03:00
|
|
|
|
2024-04-17 10:40:09 +08:00
|
|
|
- ``-fexperimental-modules-reduced-bmi`` enables the Reduced BMI for C++20 named modules.
|
|
|
|
See the document of standard C++ modules for details.
|
|
|
|
|
2024-04-29 18:37:47 -07:00
|
|
|
- ``-fexperimental-late-parse-attributes`` enables an experimental feature to
|
|
|
|
allow late parsing certain attributes in specific contexts where they would
|
2024-05-23 18:35:24 -07:00
|
|
|
not normally be late parsed. Currently this allows late parsing the
|
|
|
|
`counted_by` attribute in C. See `Attribute Changes in Clang`_.
|
2024-04-29 18:37:47 -07:00
|
|
|
|
2024-05-07 09:18:55 -07:00
|
|
|
- ``-fseparate-named-sections`` uses separate unique sections for global
|
|
|
|
symbols in named special sections (i.e. symbols annotated with
|
|
|
|
``__attribute__((section(...)))``. This enables linker GC to collect unused
|
|
|
|
symbols without having to use a per-symbol section.
|
|
|
|
|
2024-05-25 15:48:13 +12:00
|
|
|
- ``-fms-define-stdc`` and its clang-cl counterpart ``/Zc:__STDC__``.
|
|
|
|
Matches MSVC behaviour by defining ``__STDC__`` to ``1`` when
|
|
|
|
MSVC compatibility mode is used. It has no effect for C++ code.
|
|
|
|
|
2024-07-06 15:52:19 +04:00
|
|
|
- ``-Wc++23-compat`` group was added to help migrating existing codebases
|
|
|
|
to C++23.
|
|
|
|
|
2024-07-05 22:27:04 +04:00
|
|
|
- ``-Wc++2c-compat`` group was added to help migrating existing codebases
|
2024-07-06 15:52:19 +04:00
|
|
|
to upcoming C++26.
|
2024-07-05 22:27:04 +04:00
|
|
|
|
2024-07-09 07:18:06 -07:00
|
|
|
- ``-fdisable-block-signature-string`` instructs clang not to emit the signature
|
|
|
|
string for blocks. Disabling the string can potentially break existing code
|
|
|
|
that relies on it. Users should carefully consider this possibiilty when using
|
|
|
|
the flag.
|
|
|
|
|
2024-07-10 08:32:48 -07:00
|
|
|
- For the ARM target, added ``-Warm-interrupt-vfp-clobber`` that will emit a
|
|
|
|
diagnostic when an interrupt handler is declared and VFP is enabled.
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Deprecated Compiler Flags
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
Modified Compiler Flags
|
|
|
|
-----------------------
|
2024-03-11 22:55:32 +05:30
|
|
|
- Added a new diagnostic flag ``-Wreturn-mismatch`` which is grouped under
|
|
|
|
``-Wreturn-type``, and moved some of the diagnostics previously controlled by
|
|
|
|
``-Wreturn-type`` under this new flag. Fixes #GH72116.
|
2024-04-08 21:30:27 +02:00
|
|
|
- ``-fsanitize=implicit-conversion`` is now a group for both
|
|
|
|
``-fsanitize=implicit-integer-conversion`` and
|
|
|
|
``-fsanitize=implicit-bitfield-conversion``.
|
2023-01-23 13:25:55 +02:00
|
|
|
|
2024-03-21 14:18:43 -04:00
|
|
|
- Added ``-Wcast-function-type-mismatch`` under the ``-Wcast-function-type``
|
|
|
|
warning group. Moved the diagnostic previously controlled by
|
|
|
|
``-Wcast-function-type`` to the new warning group and added
|
|
|
|
``-Wcast-function-type-mismatch`` to ``-Wextra``. #GH76872
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
int x(long);
|
|
|
|
typedef int (f2)(void*);
|
|
|
|
typedef int (f3)();
|
|
|
|
|
|
|
|
void func(void) {
|
|
|
|
// Diagnoses under -Wcast-function-type, -Wcast-function-type-mismatch,
|
|
|
|
// -Wcast-function-type-strict, -Wextra
|
|
|
|
f2 *b = (f2 *)x;
|
|
|
|
// Diagnoses under -Wcast-function-type, -Wcast-function-type-strict
|
|
|
|
f3 *c = (f3 *)x;
|
|
|
|
}
|
|
|
|
|
2024-04-22 10:17:12 -07:00
|
|
|
- Carved out ``-Wformat`` warning about scoped enums into a subwarning and
|
|
|
|
make it controlled by ``-Wformat-pedantic``. Fixes #GH88595.
|
2024-03-20 13:34:46 +01:00
|
|
|
|
2024-05-03 14:10:54 +02:00
|
|
|
- Trivial infinite loops (i.e loops with a constant controlling expresion
|
|
|
|
evaluating to ``true`` and an empty body such as ``while(1);``)
|
|
|
|
are considered infinite, even when the ``-ffinite-loop`` flag is set.
|
|
|
|
|
2024-07-06 15:52:19 +04:00
|
|
|
- Diagnostics groups about compatibility with a particular C++ Standard version
|
|
|
|
now include dianostics about C++26 features that are not present in older
|
|
|
|
versions.
|
|
|
|
|
2024-07-10 08:32:48 -07:00
|
|
|
- Removed the "arm interrupt calling convention" warning that was included in
|
|
|
|
``-Wextra`` without its own flag. This warning suggested adding
|
|
|
|
``__attribute__((interrupt))`` to functions that are called from interrupt
|
|
|
|
handlers to prevent clobbering VFP registers. Following this suggestion leads
|
|
|
|
to unpredictable behavior by causing multiple exception returns from one
|
|
|
|
exception. Fixes #GH34876.
|
|
|
|
|
2020-12-17 09:23:02 -05:00
|
|
|
Removed Compiler Flags
|
|
|
|
-------------------------
|
|
|
|
|
2024-02-20 13:50:41 +01:00
|
|
|
- The ``-freroll-loops`` flag has been removed. It had no effect since Clang 13.
|
2024-03-15 10:50:21 -07:00
|
|
|
- ``-m[no-]unaligned-access`` is removed for RISC-V and LoongArch.
|
2024-04-16 09:00:57 -04:00
|
|
|
``-m[no-]strict-align``, also supported by GCC, should be used instead. (#GH85350)
|
2024-02-20 13:50:41 +01:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Attribute Changes in Clang
|
|
|
|
--------------------------
|
2024-03-12 10:30:39 -07:00
|
|
|
- Introduced a new function attribute ``__attribute__((amdgpu_max_num_work_groups(x, y, z)))`` or
|
|
|
|
``[[clang::amdgpu_max_num_work_groups(x, y, z)]]`` for the AMDGPU target. This attribute can be
|
|
|
|
attached to HIP or OpenCL kernel function definitions to provide an optimization hint. The parameters
|
|
|
|
``x``, ``y``, and ``z`` specify the maximum number of workgroups for the respective dimensions,
|
|
|
|
and each must be a positive integer when provided. The parameter ``x`` is required, while ``y`` and
|
|
|
|
``z`` are optional with default value of 1.
|
2023-11-22 12:51:24 +01:00
|
|
|
|
2024-03-20 21:18:57 +09:00
|
|
|
- The ``swiftasynccc`` attribute is now considered to be a Clang extension
|
|
|
|
rather than a language standard feature. Please use
|
|
|
|
``__has_extension(swiftasynccc)`` to check the availability of this attribute
|
|
|
|
for the target platform instead of ``__has_feature(swiftasynccc)``. Also,
|
|
|
|
added a new extension query ``__has_extension(swiftcc)`` corresponding to the
|
|
|
|
``__attribute__((swiftcc))`` attribute.
|
|
|
|
|
2024-04-02 13:48:45 +02:00
|
|
|
- The ``_Nullable`` and ``_Nonnull`` family of type attributes can now apply
|
|
|
|
to certain C++ class types, such as smart pointers:
|
|
|
|
``void useObject(std::unique_ptr<Object> _Nonnull obj);``.
|
|
|
|
|
|
|
|
This works for standard library types including ``unique_ptr``, ``shared_ptr``,
|
|
|
|
and ``function``. See
|
|
|
|
`the attribute reference documentation <https://llvm.org/docs/AttributeReference.html#nullability-attributes>`_
|
|
|
|
for the full list.
|
|
|
|
|
|
|
|
- The ``_Nullable`` attribute can be applied to C++ class declarations:
|
|
|
|
``template <class T> class _Nullable MySmartPointer {};``.
|
|
|
|
|
|
|
|
This allows the ``_Nullable`` and ``_Nonnull`` family of type attributes to
|
|
|
|
apply to this class.
|
|
|
|
|
2024-04-18 07:48:10 -04:00
|
|
|
- Clang now warns that the ``exclude_from_explicit_instantiation`` attribute
|
|
|
|
is ignored when applied to a local class or a member thereof.
|
|
|
|
|
2024-05-17 15:13:32 +02:00
|
|
|
- The ``clspv_libclc_builtin`` attribute has been added to allow clspv
|
|
|
|
(`OpenCL-C to Vulkan SPIR-V compiler <https://github.com/google/clspv>`_) to identify functions coming from libclc
|
|
|
|
(`OpenCL-C builtin library <https://libclc.llvm.org>`_).
|
2024-05-23 18:35:24 -07:00
|
|
|
- The ``counted_by`` attribute is now allowed on pointers that are members of a
|
|
|
|
struct in C.
|
|
|
|
|
|
|
|
- The ``counted_by`` attribute can now be late parsed in C when
|
|
|
|
``-fexperimental-late-parse-attributes`` is passed but only when attribute is
|
|
|
|
used in the declaration attribute position. This allows using the
|
|
|
|
attribute on existing code where it previously impossible to do so without
|
|
|
|
re-ordering struct field declarations would break ABI as shown below.
|
|
|
|
|
|
|
|
.. code-block:: c
|
|
|
|
|
|
|
|
struct BufferTy {
|
|
|
|
/* Refering to `count` requires late parsing */
|
|
|
|
char* buffer __counted_by(count);
|
|
|
|
/* Swapping `buffer` and `count` to avoid late parsing would break ABI */
|
|
|
|
size_t count;
|
|
|
|
};
|
|
|
|
|
2024-07-09 13:58:01 -07:00
|
|
|
- The attributes ``sized_by``, ``counted_by_or_null`` and ``sized_by_or_null```
|
|
|
|
have been added as variants on ``counted_by``, each with slightly different semantics.
|
|
|
|
``sized_by`` takes a byte size parameter instead of an element count, allowing pointees
|
|
|
|
with unknown size. The ``counted_by_or_null`` and ``sized_by_or_null`` variants are equivalent
|
|
|
|
to their base variants, except the pointer can be null regardless of count/size value.
|
|
|
|
If the pointer is null the size is effectively 0. ``sized_by_or_null`` is needed to properly
|
|
|
|
annotate allocator functions like ``malloc`` that return a buffer of a given byte size, but can
|
|
|
|
also return null.
|
|
|
|
|
2024-07-09 16:08:11 +02:00
|
|
|
- The ``guarded_by``, ``pt_guarded_by``, ``acquired_after``, ``acquired_before``
|
|
|
|
attributes now support referencing struct members in C. The arguments are also
|
|
|
|
now late parsed when ``-fexperimental-late-parse-attributes`` is passed like
|
|
|
|
for ``counted_by``.
|
2024-05-17 15:13:32 +02:00
|
|
|
|
2024-06-24 00:51:31 -10:00
|
|
|
- Introduced new function type attributes ``[[clang::nonblocking]]``, ``[[clang::nonallocating]]``,
|
|
|
|
``[[clang::blocking]]``, and ``[[clang::allocating]]``, with GNU-style variants as well.
|
|
|
|
The attributes declare constraints about a function's behavior pertaining to blocking and
|
|
|
|
heap memory allocation.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Improvements to Clang's diagnostics
|
|
|
|
-----------------------------------
|
2024-07-11 13:26:24 -04:00
|
|
|
- Clang now emits an error instead of a warning for ``-Wundefined-internal``
|
|
|
|
when compiling with `-pedantic-errors` to conform to the C standard
|
|
|
|
|
2024-01-27 17:52:20 +01:00
|
|
|
- Clang now applies syntax highlighting to the code snippets it
|
|
|
|
prints.
|
2023-10-25 08:58:28 -07:00
|
|
|
|
2024-02-01 11:19:04 -05:00
|
|
|
- Clang now diagnoses member template declarations with multiple declarators.
|
2024-02-08 13:37:55 +01:00
|
|
|
|
|
|
|
- Clang now diagnoses use of the ``template`` keyword after declarative nested
|
|
|
|
name specifiers.
|
|
|
|
|
|
|
|
- The ``-Wshorten-64-to-32`` diagnostic is now grouped under ``-Wimplicit-int-conversion`` instead
|
2024-03-04 14:22:51 +01:00
|
|
|
of ``-Wconversion``. Fixes #GH69444.
|
2024-02-01 11:19:04 -05:00
|
|
|
|
2024-03-05 04:38:42 -08:00
|
|
|
- Clang now uses thousand separators when printing large numbers in integer overflow diagnostics.
|
|
|
|
Fixes #GH80939.
|
|
|
|
|
2024-02-13 14:25:56 -05:00
|
|
|
- Clang now diagnoses friend declarations with an ``enum`` elaborated-type-specifier in language modes after C++98.
|
|
|
|
|
2024-02-16 15:08:04 -05:00
|
|
|
- Added diagnostics for C11 keywords being incompatible with language standards
|
|
|
|
before C11, under a new warning group: ``-Wpre-c11-compat``.
|
|
|
|
|
2024-02-20 11:58:03 -05:00
|
|
|
- Now diagnoses an enumeration constant whose value is larger than can be
|
|
|
|
represented by ``unsigned long long``, which can happen with a large constant
|
|
|
|
using the ``wb`` or ``uwb`` suffix. The maximal underlying type is currently
|
|
|
|
``unsigned long long``, but this behavior may change in the future when Clang
|
|
|
|
implements
|
|
|
|
`WG14 N3029 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3029.htm>`_.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH69352).
|
2024-02-20 11:58:03 -05:00
|
|
|
|
2024-02-20 13:12:32 -05:00
|
|
|
- Clang now diagnoses extraneous template parameter lists as a language extension.
|
|
|
|
|
2024-02-20 13:25:12 -05:00
|
|
|
- Clang now diagnoses declarative nested name specifiers that name alias templates.
|
|
|
|
|
2024-02-29 19:39:39 +05:30
|
|
|
- Clang now diagnoses lambda function expressions being implicitly cast to boolean values, under ``-Wpointer-bool-conversion``.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes #GH82512.
|
2024-02-29 19:39:39 +05:30
|
|
|
|
2024-03-13 21:58:25 +05:30
|
|
|
- Clang now provides improved warnings for the ``cleanup`` attribute to detect misuse scenarios,
|
2024-04-16 09:00:57 -04:00
|
|
|
such as attempting to call ``free`` on an unallocated object. Fixes #GH79443.
|
2024-03-13 21:58:25 +05:30
|
|
|
|
2024-03-18 17:49:44 +05:30
|
|
|
- Clang no longer warns when the ``bitand`` operator is used with boolean
|
|
|
|
operands, distinguishing it from potential typographical errors or unintended
|
|
|
|
bitwise operations. Fixes #GH77601.
|
|
|
|
|
2024-03-20 19:19:30 +01:00
|
|
|
- Clang now correctly diagnoses no arguments to a variadic macro parameter as a C23/C++20 extension.
|
|
|
|
Fixes #GH84495.
|
|
|
|
|
2024-03-26 13:38:31 +01:00
|
|
|
- Clang no longer emits a ``-Wexit-time destructors`` warning on static variables explicitly
|
|
|
|
annotated with the ``clang::always_destroy`` attribute.
|
|
|
|
Fixes #GH68686, #GH86486
|
|
|
|
|
2024-03-27 15:56:19 -07:00
|
|
|
- ``-Wmicrosoft``, ``-Wgnu``, or ``-pedantic`` is now required to diagnose C99
|
|
|
|
flexible array members in a union or alone in a struct. Fixes GH#84565.
|
|
|
|
|
2024-03-29 17:42:09 +01:00
|
|
|
- Clang now no longer diagnoses type definitions in ``offsetof`` in C23 mode.
|
|
|
|
Fixes #GH83658.
|
|
|
|
|
2024-03-31 11:09:52 +02:00
|
|
|
- New ``-Wformat-signedness`` diagnostic that warn if the format string requires an
|
|
|
|
unsigned argument and the argument is signed and vice versa.
|
|
|
|
|
2024-04-03 16:15:30 +08:00
|
|
|
- Clang now emits ``unused argument`` warning when the -fmodule-output flag is used
|
|
|
|
with an input that is not of type c++-module.
|
|
|
|
|
2024-04-04 20:44:40 -05:00
|
|
|
- Clang emits a ``-Wreturn-stack-address`` warning if a function returns a pointer or
|
|
|
|
reference to a struct literal. Fixes #GH8678
|
|
|
|
|
2024-04-04 20:45:18 -04:00
|
|
|
- Clang emits a ``-Wunused-but-set-variable`` warning on C++ variables whose declaration
|
|
|
|
(with initializer) entirely consist the condition expression of a if/while/for construct
|
|
|
|
but are not actually used in the body of the if/while/for construct. Fixes #GH41447
|
|
|
|
|
2024-04-09 10:38:54 -04:00
|
|
|
- Clang emits a diagnostic when a tentative array definition is assumed to have
|
|
|
|
a single element, but that diagnostic was never given a diagnostic group.
|
|
|
|
Added the ``-Wtentative-definition-array`` warning group to cover this.
|
|
|
|
Fixes #GH87766
|
|
|
|
|
2024-04-11 13:20:05 -04:00
|
|
|
- Clang now uses the correct type-parameter-key (``class`` or ``typename``) when printing
|
|
|
|
template template parameter declarations.
|
|
|
|
|
2024-04-17 11:41:03 -04:00
|
|
|
- Clang now diagnoses requires expressions with explicit object parameters.
|
|
|
|
|
2024-04-30 14:25:09 -04:00
|
|
|
- Clang now looks up members of the current instantiation in the template definition context
|
|
|
|
if the current instantiation has no dependent base classes.
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
struct A {
|
|
|
|
int f() {
|
|
|
|
return this->x; // error: no member named 'x' in 'A<T>'
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2024-05-17 09:29:20 -04:00
|
|
|
- Clang emits a ``-Wparentheses`` warning for expressions with consecutive comparisons like ``x < y < z``.
|
|
|
|
Fixes #GH20456.
|
|
|
|
|
2024-05-28 13:59:49 -04:00
|
|
|
- Clang no longer emits a "declared here" note for a builtin function that has no declaration in source.
|
|
|
|
Fixes #GH93369.
|
|
|
|
|
2024-07-01 15:38:45 +02:00
|
|
|
- Clang now has an improved error message for captures that refer to a class member.
|
|
|
|
Fixes #GH94764.
|
|
|
|
|
2024-06-20 18:44:06 +01:00
|
|
|
- Clang now diagnoses unsupported class declarations for ``std::initializer_list<E>`` when they are
|
|
|
|
used rather than when they are needed for constant evaluation or when code is generated for them.
|
|
|
|
The check is now stricter to prevent crashes for some unsupported declarations (Fixes #GH95495).
|
|
|
|
|
2024-07-01 17:43:07 +02:00
|
|
|
- Clang now diagnoses dangling cases where a pointer is assigned to a temporary
|
|
|
|
that will be destroyed at the end of the full expression.
|
|
|
|
Fixes #GH54492.
|
|
|
|
|
2024-07-02 19:34:48 +08:00
|
|
|
- Clang now shows implicit deduction guides when diagnosing overload resolution failure. #GH92393.
|
|
|
|
|
2024-07-09 18:38:32 -07:00
|
|
|
- Clang no longer emits a "no previous prototype" warning for Win32 entry points under ``-Wmissing-prototypes``.
|
|
|
|
Fixes #GH94366.
|
|
|
|
|
2024-07-10 08:32:48 -07:00
|
|
|
- For the ARM target, calling an interrupt handler from another function is now an error. #GH95359.
|
|
|
|
|
2024-07-11 14:21:21 +02:00
|
|
|
- Clang now diagnoses integer constant expressions that are folded to a constant value as an extension in more circumstances. Fixes #GH59863
|
|
|
|
|
2023-09-01 15:30:44 +01:00
|
|
|
Improvements to Clang's time-trace
|
|
|
|
----------------------------------
|
|
|
|
|
2024-05-16 21:15:25 +02:00
|
|
|
- Clang now specifies that using ``auto`` in a lambda parameter is a C++14 extension when
|
|
|
|
appropriate. (`#46059: <https://github.com/llvm/llvm-project/issues/46059>`_).
|
|
|
|
|
2024-06-19 07:15:19 +09:00
|
|
|
Improvements to Coverage Mapping
|
|
|
|
--------------------------------
|
|
|
|
|
|
|
|
- Macros defined in system headers are not expanded in coverage
|
|
|
|
mapping. Conditional expressions in system header macros are no
|
|
|
|
longer taken into account for branch coverage. They can be included
|
|
|
|
with ``-mllvm -system-headers-coverage``.
|
|
|
|
(`#78920: <https://github.com/llvm/llvm-project/issues/78920>`_)
|
|
|
|
- MC/DC Coverage has been improved.
|
|
|
|
(`#82448: <https://github.com/llvm/llvm-project/pull/82448>`_)
|
|
|
|
|
|
|
|
- The maximum number of conditions is no longer limited to 6. See
|
|
|
|
`this <SourceBasedCodeCoverage.html#mc-dc-instrumentation>` for
|
|
|
|
more details.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes in This Version
|
|
|
|
-------------------------
|
2024-04-09 16:47:11 +03:00
|
|
|
- Clang's ``-Wundefined-func-template`` no longer warns on pure virtual
|
2024-04-16 09:00:57 -04:00
|
|
|
functions. (#GH74016)
|
2024-04-09 16:47:11 +03:00
|
|
|
|
2024-02-27 11:58:59 -03:00
|
|
|
- Fixed missing warnings when comparing mismatched enumeration constants
|
2024-04-16 09:00:57 -04:00
|
|
|
in C (#GH29217)
|
2024-02-27 11:58:59 -03:00
|
|
|
|
2024-01-30 08:28:13 -05:00
|
|
|
- Clang now accepts elaborated-type-specifiers that explicitly specialize
|
|
|
|
a member class template for an implicit instantiation of a class template.
|
2023-10-10 10:25:01 +02:00
|
|
|
|
2024-03-04 14:22:51 +01:00
|
|
|
- Fixed missing warnings when doing bool-like conversions in C23 (#GH79435).
|
2024-02-12 12:44:20 +03:00
|
|
|
- Clang's ``-Wshadow`` no longer warns when an init-capture is named the same as
|
|
|
|
a class field unless the lambda can capture this.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH71976)
|
2024-01-30 19:20:15 +01:00
|
|
|
|
2024-02-02 12:53:34 -05:00
|
|
|
- Clang now accepts qualified partial/explicit specializations of variable templates that
|
|
|
|
are not nominable in the lookup context of the specialization.
|
|
|
|
|
2024-02-06 15:57:35 +03:00
|
|
|
- Clang now doesn't produce false-positive warning `-Wconstant-logical-operand`
|
|
|
|
for logical operators in C23.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH64356).
|
2024-02-06 15:57:35 +03:00
|
|
|
|
2024-03-11 06:53:23 +03:30
|
|
|
- ``__is_trivially_relocatable`` no longer returns ``false`` for volatile-qualified types.
|
|
|
|
Fixes (#GH77091).
|
|
|
|
|
2024-03-01 21:10:46 +05:30
|
|
|
- Clang no longer produces a false-positive `-Wunused-variable` warning
|
|
|
|
for variables created through copy initialization having side-effects in C++17 and later.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH64356) (#GH79518).
|
2024-03-01 21:10:46 +05:30
|
|
|
|
2024-03-19 07:55:49 -07:00
|
|
|
- Fix value of predefined macro ``__FUNCTION__`` in MSVC compatibility mode.
|
|
|
|
Fixes (#GH66114).
|
|
|
|
|
2024-03-08 11:52:42 +03:00
|
|
|
- Clang now emits errors for explicit specializations/instatiations of lambda call
|
|
|
|
operator.
|
|
|
|
Fixes (#GH83267).
|
|
|
|
|
2024-04-24 10:45:38 +04:00
|
|
|
- Fix crash on ill-formed partial specialization with CRTP.
|
|
|
|
Fixes (#GH89374).
|
|
|
|
|
2024-03-12 07:40:27 -04:00
|
|
|
- Clang now correctly generates overloads for bit-precise integer types for
|
|
|
|
builtin operators in C++. Fixes #GH82998.
|
|
|
|
|
2024-05-01 12:43:10 +04:00
|
|
|
- Fix crash when destructor definition is preceded with an equals sign.
|
|
|
|
Fixes (#GH89544).
|
|
|
|
|
[Clang] [Sema] Fix bug in `_Complex float`+`int` arithmetic (#83063)
C23 6.3.1.8 ‘Usual arithmetic conversions’ p1 states (emphasis mine):
> Otherwise, if the corresponding real type of either operand is
`float`, the other operand is converted, *without change of type
domain*, to a type whose corresponding real type is `float`.
‘type domain’ here refers to `_Complex` vs real (i.e. non-`_Complex`);
there is another clause that states the same for `double`.
Consider the following code:
```c++
_Complex float f;
int x;
f / x;
```
After talking this over with @AaronBallman, we came to the conclusion
that `x` should be converted to `float` and *not* `_Complex float` (that
is, we should perform a division of `_Complex float / float`, and *not*
`_Complex float / _Complex float`; the same also applies to `-+*`). This
was already being done correctly for cases where `x` was already a
`float`; it’s just mixed `_Complex float`+`int` operations that
currently suffer from this problem.
This pr removes the extra `FloatingRealToComplex` conversion that we
were erroneously inserting and adds some tests to make sure we’re
actually doing `_Complex float / float` and not `_Complex float /
_Complex float` (and analogously for `double` and `-+*`).
The only exception here is `float / _Complex float`, which calls a
library function (`__divsc3`) that takes 4 `float`s, so we end up having
to convert the `float` to a `_Complex float` after all (and analogously
for `double`); I don’t believe there is a way around this.
Lastly, we were also missing tests for `_Complex` arithmetic at compile
time, so this adds some tests for that as well.
2024-03-13 17:39:23 +01:00
|
|
|
- When performing mixed arithmetic between ``_Complex`` floating-point types and integers,
|
|
|
|
Clang now correctly promotes the integer to its corresponding real floating-point
|
|
|
|
type only rather than to the complex type (e.g. ``_Complex float / int`` is now evaluated
|
|
|
|
as ``_Complex float / float`` rather than ``_Complex float / _Complex float``), as mandated
|
|
|
|
by the C standard. This significantly improves codegen of `*` and `/` especially.
|
2024-04-16 09:00:57 -04:00
|
|
|
Fixes #GH31205.
|
[Clang] [Sema] Fix bug in `_Complex float`+`int` arithmetic (#83063)
C23 6.3.1.8 ‘Usual arithmetic conversions’ p1 states (emphasis mine):
> Otherwise, if the corresponding real type of either operand is
`float`, the other operand is converted, *without change of type
domain*, to a type whose corresponding real type is `float`.
‘type domain’ here refers to `_Complex` vs real (i.e. non-`_Complex`);
there is another clause that states the same for `double`.
Consider the following code:
```c++
_Complex float f;
int x;
f / x;
```
After talking this over with @AaronBallman, we came to the conclusion
that `x` should be converted to `float` and *not* `_Complex float` (that
is, we should perform a division of `_Complex float / float`, and *not*
`_Complex float / _Complex float`; the same also applies to `-+*`). This
was already being done correctly for cases where `x` was already a
`float`; it’s just mixed `_Complex float`+`int` operations that
currently suffer from this problem.
This pr removes the extra `FloatingRealToComplex` conversion that we
were erroneously inserting and adds some tests to make sure we’re
actually doing `_Complex float / float` and not `_Complex float /
_Complex float` (and analogously for `double` and `-+*`).
The only exception here is `float / _Complex float`, which calls a
library function (`__divsc3`) that takes 4 `float`s, so we end up having
to convert the `float` to a `_Complex float` after all (and analogously
for `double`); I don’t believe there is a way around this.
Lastly, we were also missing tests for `_Complex` arithmetic at compile
time, so this adds some tests for that as well.
2024-03-13 17:39:23 +01:00
|
|
|
|
2024-03-16 12:36:33 +01:00
|
|
|
- Fixes an assertion failure on invalid code when trying to define member
|
|
|
|
functions in lambdas.
|
|
|
|
|
2024-03-29 23:28:54 +08:00
|
|
|
- Fixed a regression in CTAD that a friend declaration that befriends itself may cause
|
|
|
|
incorrect constraint substitution. (#GH86769).
|
|
|
|
|
2024-04-16 22:38:27 +08:00
|
|
|
- Fixed an assertion failure on invalid InitListExpr in C89 mode (#GH88008).
|
|
|
|
|
Re-apply "Emit missing cleanups for stmt-expr" and other commits (#89154)
Latest diff:
https://github.com/llvm/llvm-project/pull/89154/files/f1ab4c2677394bbfc985d9680d5eecd7b2e6a882..adf9bc902baddb156c83ce0f8ec03c142e806d45
We address two additional bugs here:
### Problem 1: Deactivated normal cleanup still runs, leading to
double-free
Consider the following:
```cpp
struct A { };
struct B { B(const A&); };
struct S {
A a;
B b;
};
int AcceptS(S s);
void Accept2(int x, int y);
void Test() {
Accept2(AcceptS({.a = A{}, .b = A{}}), ({ return; 0; }));
}
```
We add cleanups as follows:
1. push dtor for field `S::a`
2. push dtor for temp `A{}` (used by ` B(const A&)` in `.b = A{}`)
3. push dtor for field `S::b`
4. Deactivate 3 `S::b`-> This pops the cleanup.
5. Deactivate 1 `S::a` -> Does not pop the cleanup as *2* is top. Should
create _active flag_!!
6. push dtor for `~S()`.
7. ...
It is important to deactivate **5** using active flags. Without the
active flags, the `return` will fallthrough it and would run both `~S()`
and dtor `S::a` leading to **double free** of `~A()`.
In this patch, we unconditionally emit active flags while deactivating
normal cleanups. These flags are deleted later by the `AllocaTracker` if
the cleanup is not emitted.
### Problem 2: Missing cleanup for conditional lifetime extension
We push 2 cleanups for lifetime-extended cleanup. The first cleanup is
useful if we exit from the middle of the expression (stmt-expr/coro
suspensions). This is deactivated after full-expr, and a new cleanup is
pushed, extending the lifetime of the temporaries (to the scope of the
reference being initialized).
If this lifetime extension happens to be conditional, then we use active
flags to remember whether the branch was taken and if the object was
initialized.
Previously, we used a **single** active flag, which was used by both
cleanups. This is wrong because the first cleanup will be forced to
deactivate after the full-expr and therefore this **active** flag will
always be **inactive**. The dtor for the lifetime extended entity would
not run as it always sees an **inactive** flag.
In this patch, we solve this using two separate active flags for both
cleanups. Both of them are activated if the conditional branch is taken,
but only one of them is deactivated after the full-expr.
---
Fixes https://github.com/llvm/llvm-project/issues/63818
Fixes https://github.com/llvm/llvm-project/issues/88478
---
Previous PR logs:
1. https://github.com/llvm/llvm-project/pull/85398
2. https://github.com/llvm/llvm-project/pull/88670
3. https://github.com/llvm/llvm-project/pull/88751
4. https://github.com/llvm/llvm-project/pull/88884
2024-04-29 12:33:46 +02:00
|
|
|
- Fixed missing destructor calls when we branch from middle of an expression.
|
|
|
|
This could happen through a branch in stmt-expr or in an expression containing a coroutine
|
|
|
|
suspension. Fixes (#GH63818) (#GH88478).
|
|
|
|
|
2024-04-18 12:40:51 -07:00
|
|
|
- Clang will no longer diagnose an erroneous non-dependent ``switch`` condition
|
|
|
|
during instantiation, and instead will only diagnose it once, during checking
|
|
|
|
of the function template.
|
|
|
|
|
2024-04-19 11:51:59 +08:00
|
|
|
- Clang now allows the value of unroll count to be zero in ``#pragma GCC unroll`` and ``#pragma unroll``.
|
|
|
|
The values of 0 and 1 block any unrolling of the loop. This keeps the same behavior with GCC.
|
|
|
|
Fixes (`#88624 <https://github.com/llvm/llvm-project/issues/88624>`_).
|
|
|
|
|
2024-05-02 10:10:38 -04:00
|
|
|
- Clang will no longer emit a duplicate -Wunused-value warning for an expression
|
|
|
|
`(A, B)` which evaluates to glvalue `B` that can be converted to non ODR-use. (#GH45783)
|
|
|
|
|
2024-05-16 05:38:15 +02:00
|
|
|
- Clang now correctly disallows VLA type compound literals, e.g. ``(int[size]){}``,
|
|
|
|
as the C standard mandates. (#GH89835)
|
|
|
|
|
2024-05-20 09:36:45 +02:00
|
|
|
- ``__is_array`` and ``__is_bounded_array`` no longer return ``true`` for
|
|
|
|
zero-sized arrays. Fixes (#GH54705).
|
|
|
|
|
2024-05-28 14:55:18 -04:00
|
|
|
- Correctly reject declarations where a statement is required in C.
|
|
|
|
Fixes #GH92775
|
|
|
|
|
2024-06-20 11:03:27 +03:00
|
|
|
- Fixed `static_cast` to array of unknown bound. Fixes (#GH62863).
|
|
|
|
|
2024-07-10 11:24:23 -07:00
|
|
|
- Fixed Clang crashing when failing to perform some C++ Initialization Sequences. (#GH98102)
|
|
|
|
|
2024-07-12 18:29:39 +02:00
|
|
|
- ``__is_trivially_equality_comparable`` no longer returns true for types which
|
|
|
|
have a constrained defaulted comparison operator (#GH89293).
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to Compiler Builtins
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-05-02 17:06:04 -04:00
|
|
|
|
2024-05-27 15:49:28 +02:00
|
|
|
- Fix crash when atomic builtins are called with pointer to zero-size struct (#GH90330)
|
|
|
|
|
2024-06-30 14:09:10 +09:00
|
|
|
- Clang now allows pointee types of atomic builtin arguments to be complete template types
|
|
|
|
that was not instantiated elsewhere.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to Attribute Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-08-26 19:26:32 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to C++ Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
2023-01-18 08:49:45 -05:00
|
|
|
|
2024-02-09 20:59:02 +04:00
|
|
|
- Fix crash when calling the constructor of an invalid class.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH10518) (#GH67914) (#GH78388)
|
2024-01-26 14:26:53 +08:00
|
|
|
- Fix crash when using lifetimebound attribute in function with trailing return.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH73619)
|
2024-01-31 12:17:41 +08:00
|
|
|
- Addressed an issue where constraints involving injected class types are perceived
|
2024-03-04 14:22:51 +01:00
|
|
|
distinct from its specialization types. (#GH56482)
|
2024-01-27 15:42:52 +08:00
|
|
|
- Fixed a bug where variables referenced by requires-clauses inside
|
2024-03-04 14:22:51 +01:00
|
|
|
nested generic lambdas were not properly injected into the constraint scope. (#GH73418)
|
2024-01-30 19:34:52 +08:00
|
|
|
- Fixed a crash where substituting into a requires-expression that refers to function
|
|
|
|
parameters during the equivalence determination of two constraint expressions.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH74447)
|
2024-01-29 06:42:52 +08:00
|
|
|
- Fixed deducing auto& from const int in template parameters of partial
|
2024-03-04 14:22:51 +01:00
|
|
|
specializations. (#GH77189)
|
2024-01-29 10:08:09 -08:00
|
|
|
- Fix for crash when using a erroneous type in a return statement.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH63244) (#GH79745)
|
[clang][Sema] Populate function template depth at AddTemplateOverloadCandidate (#80395)
This is yet another one-line patch to fix crashes on constraint
substitution.
```cpp
template <class, class> struct formatter;
template <class, class> struct basic_format_context {};
template <typename CharType>
concept has_format_function = format(basic_format_context<CharType, CharType>());
template <typename ValueType, typename CharType>
requires has_format_function<CharType>
struct formatter<ValueType, CharType> {
template <typename OutputIt>
CharType format(basic_format_context<OutputIt, CharType>);
};
```
In this case, we would build up a `RecoveryExpr` for a call within a
constraint expression due to the absence of viable functions. The
heuristic algorithm attempted to find such a function inside of a
ClassTemplatePartialSpecialization, from which we started to substitute
its requires-expression, and it succeeded with a FunctionTemplate such
that
1) It has only one parameter, which is dependent.
2) The only one parameter depends on two template parameters. They are,
in canonical form, `<template-parameter-1-0>` and
`<template-parameter-0-1>` respectively.
Before we emit an error, we still want to recover the most viable
functions. This goes downhill to deducing template parameters against
its arguments, where we would collect the argument type with the same
depth as the parameter type into a Deduced set. The size of the set is
presumed to be that of function template parameters, which is 1 in this
case. However, since we haven't yet properly set the template depth
before the dance, we'll end up putting the type for
`<template-parameter-0-1>` to the second position of Deduced set, which
is unfortunately an access violation!
The bug seems to appear since clang 12.0.
This fixes [the
case](https://github.com/llvm/llvm-project/issues/58548#issuecomment-1287935336).
2024-02-03 16:14:48 +08:00
|
|
|
- Fixed an out-of-bounds error caused by building a recovery expression for ill-formed
|
2024-03-04 14:22:51 +01:00
|
|
|
function calls while substituting into constraints. (#GH58548)
|
|
|
|
- Fix incorrect code generation caused by the object argument
|
|
|
|
of ``static operator()`` and ``static operator[]`` calls not being evaluated. (#GH67976)
|
2024-02-02 20:26:54 -08:00
|
|
|
- Fix crash and diagnostic with const qualified member operator new.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH79748)
|
2024-02-06 09:59:16 +08:00
|
|
|
- Fixed a crash where substituting into a requires-expression that involves parameter packs
|
2024-03-04 14:22:51 +01:00
|
|
|
during the equivalence determination of two constraint expressions. (#GH72557)
|
2024-02-03 21:49:09 +08:00
|
|
|
- Fix a crash when specializing an out-of-line member function with a default
|
|
|
|
parameter where we did an incorrect specialization of the initialization of
|
2024-03-04 14:22:51 +01:00
|
|
|
the default parameter. (#GH68490)
|
2024-02-07 15:12:15 +01:00
|
|
|
- Fix a crash when trying to call a varargs function that also has an explicit object parameter.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH80971)
|
|
|
|
- Reject explicit object parameters on `new` and `delete` operators. (#GH82249)
|
|
|
|
- Fix a crash when trying to call a varargs function that also has an explicit object parameter. (#GH80971)
|
2024-02-08 13:04:10 -05:00
|
|
|
- Fixed a bug where abbreviated function templates would append their invented template parameters to
|
|
|
|
an empty template parameter lists.
|
2024-04-16 09:00:57 -04:00
|
|
|
- Fix parsing of abominable function types inside type traits. Fixes #GH77585
|
2024-02-08 14:27:14 -08:00
|
|
|
- Clang now classifies aggregate initialization in C++17 and newer as constant
|
|
|
|
or non-constant more accurately. Previously, only a subset of the initializer
|
2024-03-04 14:22:51 +01:00
|
|
|
elements were considered, misclassifying some initializers as constant. Partially fixes
|
|
|
|
#GH80510.
|
|
|
|
- Clang now ignores top-level cv-qualifiers on function parameters in template partial orderings. (#GH75404)
|
2024-02-16 07:43:55 -05:00
|
|
|
- No longer reject valid use of the ``_Alignas`` specifier when declaring a
|
|
|
|
local variable, which is supported as a C11 extension in C++. Previously, it
|
|
|
|
was only accepted at namespace scope but not at local function scope.
|
2024-03-04 14:22:51 +01:00
|
|
|
- Clang no longer tries to call consteval constructors at runtime when they appear in a member initializer. (#GH82154)
|
|
|
|
- Fix crash when using an immediate-escalated function at global scope. (#GH82258)
|
|
|
|
- Correctly immediate-escalate lambda conversion functions. (#GH82258)
|
2024-02-23 09:36:32 +08:00
|
|
|
- Fixed an issue where template parameters of a nested abbreviated generic lambda within
|
|
|
|
a requires-clause lie at the same depth as those of the surrounding lambda. This,
|
|
|
|
in turn, results in the wrong template argument substitution during constraint checking.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH78524)
|
[Clang][Sema] Defer instantiation of exception specification until after partial ordering when determining primary template (#82417)
Consider the following:
```
struct A {
static constexpr bool x = true;
};
template<typename T, typename U>
void f(T, U) noexcept(T::y); // #1, error: no member named 'y' in 'A'
template<typename T, typename U>
void f(T, U*) noexcept(T::x); // #2
template<>
void f(A, int*) noexcept; // explicit specialization of #2
```
We currently instantiate the exception specification of all candidate
function template specializations when deducting template arguments for
an explicit specialization, which results in a error despite `#1` not
being selected by partial ordering as the most specialized template.
According to [except.spec] p13:
> An exception specification is considered to be needed when:
> - [...]
> - the exception specification is compared to that of another
declaration (e.g., an explicit specialization or an overriding virtual
function);
Assuming that "comparing declarations" means "determining whether the
declarations correspond and declare the same entity" (per [basic.scope.scope] p4 and
[basic.link] p11.1, respectively), the exception specification does _not_ need to be
instantiated until _after_ partial ordering, at which point we determine
whether the implicitly instantiated specialization and the explicit
specialization declare the same entity (the determination of whether two
functions/function templates correspond does not consider the exception
specifications).
This patch defers the instantiation of the exception specification until
a single function template specialization is selected via partial
ordering, matching the behavior of GCC, EDG, and
MSVC: see https://godbolt.org/z/Ebb6GTcWE.
2024-02-26 09:58:55 -05:00
|
|
|
- Clang no longer instantiates the exception specification of discarded candidate function
|
|
|
|
templates when determining the primary template of an explicit specialization.
|
2024-02-26 14:01:48 -05:00
|
|
|
- Fixed a crash in Microsoft compatibility mode where unqualified dependent base class
|
|
|
|
lookup searches the bases of an incomplete class.
|
[Clang] [Sema] Handle placeholders in '.*' expressions (#83103)
When analysing whether we should handle a binary expression as an
overloaded operator call or a builtin operator, we were calling
`checkPlaceholderForOverload()`, which takes care of any placeholders
that are not overload sets—which would usually make sense since those
need to be handled as part of overload resolution.
Unfortunately, we were also doing that for `.*`, which is not
overloadable, and then proceeding to create a builtin operator anyway,
which would crash if the RHS happened to be an unresolved overload set
(due hitting an assertion in `CreateBuiltinBinOp()`—specifically, in one
of its callees—in the `.*` case that makes sure its arguments aren’t
placeholders).
This pr instead makes it so we check for *all* placeholders early if the
operator is `.*`.
It’s worth noting that,
1. In the `.*` case, we now additionally also check for *any*
placeholders (not just non-overload-sets) in the LHS; this shouldn’t
make a difference, however—at least I couldn’t think of a way to trigger
the assertion with an overload set as the LHS of `.*`; it is worth
noting that the assertion in question would also complain if the LHS
happened to be of placeholder type, though.
2. There is another case in which we also don’t perform overload
resolution—namely `=` if the LHS is not of class or enumeration type
after handling non-overload-set placeholders—as in the `.*` case, but
similarly to 1., I first couldn’t think of a way of getting this case to
crash, and secondly, `CreateBuiltinBinOp()` doesn’t seem to care about
placeholders in the LHS or RHS in the `=` case (from what I can tell,
it, or rather one of its callees, only checks that the LHS is not a
pseudo-object type, but those will have already been handled by the call
to `checkPlaceholderForOverload()` by the time we get to this function),
so I don’t think this case suffers from the same problem.
This fixes #53815.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
2024-02-27 20:19:44 +01:00
|
|
|
- Fix a crash when an unresolved overload set is encountered on the RHS of a ``.*`` operator.
|
2024-03-04 14:22:51 +01:00
|
|
|
(#GH53815)
|
2024-02-29 17:43:01 +01:00
|
|
|
- In ``__restrict``-qualified member functions, attach ``__restrict`` to the pointer type of
|
|
|
|
``this`` rather than the pointee type.
|
2024-03-04 14:22:51 +01:00
|
|
|
Fixes (#GH82941), (#GH42411) and (#GH18121).
|
2024-03-01 15:15:11 +01:00
|
|
|
- Clang now properly reports supported C++11 attributes when using
|
2024-03-04 14:22:51 +01:00
|
|
|
``__has_cpp_attribute`` and parses attributes with arguments in C++03 (#GH82995)
|
2024-03-01 07:27:06 -08:00
|
|
|
- Clang now properly diagnoses missing 'default' template arguments on a variety
|
|
|
|
of templates. Previously we were diagnosing on any non-function template
|
|
|
|
instead of only on class, alias, and variable templates, as last updated by
|
2024-03-04 15:16:46 +01:00
|
|
|
CWG2032. Fixes (#GH83461)
|
2024-03-04 09:25:29 -08:00
|
|
|
- Fixed an issue where an attribute on a declarator would cause the attribute to
|
|
|
|
be destructed prematurely. This fixes a pair of Chromium that were brought to
|
2024-03-04 09:52:25 -08:00
|
|
|
our attention by an attempt to fix in (#GH77703). Fixes (#GH83385).
|
2024-03-05 10:04:45 +01:00
|
|
|
- Fix evaluation of some immediate calls in default arguments.
|
|
|
|
Fixes (#GH80630)
|
2024-03-07 09:49:02 +08:00
|
|
|
- Fixed an issue where the ``RequiresExprBody`` was involved in the lambda dependency
|
|
|
|
calculation. (#GH56556), (#GH82849).
|
2024-03-06 15:03:21 +01:00
|
|
|
- Fix a bug where overload resolution falsely reported an ambiguity when it was comparing
|
|
|
|
a member-function against a non member function or a member-function with an
|
|
|
|
explicit object parameter against a member function with no explicit object parameter
|
2024-04-16 09:00:57 -04:00
|
|
|
when one of the function had more specialized templates. Fixes #GH82509 and #GH74494
|
2024-04-05 11:09:33 +08:00
|
|
|
- Clang now supports direct lambda calls inside of a type alias template declarations.
|
|
|
|
This addresses (#GH70601), (#GH76674), (#GH79555), (#GH81145) and (#GH82104).
|
2024-03-13 08:42:22 +08:00
|
|
|
- Allow access to a public template alias declaration that refers to friend's
|
|
|
|
private nested type. (#GH25708).
|
2024-03-13 18:49:44 +01:00
|
|
|
- Fixed a crash in constant evaluation when trying to access a
|
|
|
|
captured ``this`` pointer in a lambda with an explicit object parameter.
|
|
|
|
Fixes (#GH80997)
|
2024-03-14 14:24:27 +08:00
|
|
|
- Fix an issue where missing set friend declaration in template class instantiation.
|
|
|
|
Fixes (#GH84368).
|
2024-03-16 12:56:11 +08:00
|
|
|
- Fixed a crash while checking constraints of a trailing requires-expression of a lambda, that the
|
|
|
|
expression references to an entity declared outside of the lambda. (#GH64808)
|
2024-03-17 09:35:13 -07:00
|
|
|
- Clang's __builtin_bit_cast will now produce a constant value for records with empty bases. See:
|
|
|
|
(#GH82383)
|
2024-03-20 08:33:30 +08:00
|
|
|
- Fix a crash when instantiating a lambda that captures ``this`` outside of its context. Fixes (#GH85343).
|
2024-03-22 19:08:02 -04:00
|
|
|
- Fix an issue where a namespace alias could be defined using a qualified name (all name components
|
|
|
|
following the first `::` were ignored).
|
2024-03-27 15:31:55 +01:00
|
|
|
- Fix an out-of-bounds crash when checking the validity of template partial specializations. (part of #GH86757).
|
2024-03-28 13:10:02 +01:00
|
|
|
- Fix an issue caused by not handling invalid cases when substituting into the parameter mapping of a constraint. Fixes (#GH86757).
|
2024-04-02 08:35:42 -04:00
|
|
|
- Fixed a bug that prevented member function templates of class templates declared with a deduced return type
|
|
|
|
from being explicitly specialized for a given implicit instantiation of the class template.
|
2024-04-22 11:48:13 -04:00
|
|
|
- Fixed a crash when ``this`` is used in a dependent class scope function template specialization
|
|
|
|
that instantiates to a static member function.
|
2024-04-16 09:00:57 -04:00
|
|
|
- Fix crash when inheriting from a cv-qualified type. Fixes #GH35603
|
2024-04-05 15:18:07 +08:00
|
|
|
- Fix a crash when the using enum declaration uses an anonymous enumeration. Fixes (#GH86790).
|
2024-04-10 19:23:32 +08:00
|
|
|
- Handled an edge case in ``getFullyPackExpandedSize`` so that we now avoid a false-positive diagnostic. (#GH84220)
|
[Clang] [Sema] Fix dependence of DREs in lambdas with an explicit object parameter (#84473)
This fixes some problems wrt dependence of captures in lambdas with
an explicit object parameter.
[temp.dep.expr] states that
> An id-expression is type-dependent if [...] its terminal name is
> - associated by name lookup with an entity captured by copy
> ([expr.prim.lambda.capture]) in a lambda-expression that has
> an explicit object parameter whose type is dependent [dcl.fct].
There were several issues with our implementation of this:
1. we were treating by-reference captures as dependent rather than
by-value captures;
2. tree transform wasn't checking whether referring to such a
by-value capture should make a DRE dependent;
3. when checking whether a DRE refers to such a by-value capture, we
were only looking at the immediately enclosing lambda, and not
at any parent lambdas;
4. we also forgot to check for implicit by-value captures;
5. lastly, we were attempting to determine whether a lambda has an
explicit object parameter by checking the `LambdaScopeInfo`'s
`ExplicitObjectParameter`, but it seems that that simply wasn't
set (yet) by the time we got to the check.
All of these should be fixed now.
This fixes #70604, #79754, #84163, #84425, #86054, #86398, and #86399.
2024-04-09 14:52:52 +02:00
|
|
|
- Clang now correctly tracks type dependence of by-value captures in lambdas with an explicit
|
|
|
|
object parameter.
|
|
|
|
Fixes (#GH70604), (#GH79754), (#GH84163), (#GH84425), (#GH86054), (#GH86398), and (#GH86399).
|
2024-04-15 21:38:10 +02:00
|
|
|
- Fix a crash when deducing ``auto`` from an invalid dereference (#GH88329).
|
2024-04-16 09:57:23 +08:00
|
|
|
- Fix a crash in requires expression with templated base class member function. Fixes (#GH84020).
|
2024-04-18 08:52:25 +08:00
|
|
|
- Fix a crash caused by defined struct in a type alias template when the structure
|
|
|
|
has fields with dependent type. Fixes (#GH75221).
|
2024-04-19 17:44:12 +02:00
|
|
|
- Fix the Itanium mangling of lambdas defined in a member of a local class (#GH88906)
|
2024-04-22 18:41:36 +02:00
|
|
|
- Fixed a crash when trying to evaluate a user-defined ``static_assert`` message whose ``size()``
|
|
|
|
function returns a large or negative value. Fixes (#GH89407).
|
2024-04-23 20:34:22 +08:00
|
|
|
- Fixed a use-after-free bug in parsing of type constraints with default arguments that involve lambdas. (#GH67235)
|
2024-04-25 03:41:25 -04:00
|
|
|
- Fixed bug in which the body of a consteval lambda within a template was not parsed as within an
|
|
|
|
immediate function context.
|
2024-04-29 11:17:18 +01:00
|
|
|
- Fix CTAD for ``std::initializer_list``. This allows ``std::initializer_list{1, 2, 3}`` to be deduced as
|
|
|
|
``std::initializer_list<int>`` as intended.
|
2024-04-30 16:09:09 +08:00
|
|
|
- Fix a bug on template partial specialization whose template parameter is `decltype(auto)`.
|
2024-04-30 16:15:06 +08:00
|
|
|
- Fix a bug on template partial specialization with issue on deduction of nontype template parameter
|
|
|
|
whose type is `decltype(auto)`. Fixes (#GH68885).
|
[Clang][Sema][Parse] Delay parsing of noexcept-specifiers in friend function declarations (#90517)
According to [class.mem.general] p8:
> A complete-class context of a class (template) is a
> - function body,
> - default argument,
> - default template argument,
> - _noexcept-specifier_, or
> - default member initializer
>
> within the member-specification of the class or class template.
When testing #90152, it came to my attention that we do _not_ consider
the _noexcept-specifier_ of a friend function declaration to be a
complete-class context (something which the Microsoft standard library
depends on). Although a comment states that this is "consistent with
what other implementations do", the only other implementation that
exhibits this behavior is GCC (MSVC and EDG both late-parse the
_noexcept-specifier_).
This patch changes _noexcept-specifiers_ of friend function declarations
to be late parsed, which is in agreement with the standard & majority of
implementations. Pre-#90152, our existing implementation falls "in
between" the implementation consensus: within non-template classes, we
would not find latter declared members (qualified and unqualified),
while within class templates we would not find latter declared member
when named with a unqualified name, we would find members named with a
qualified name (even when lookup context is the current instantiation).
Therefore, this _shouldn't_ be a breaking change -- any code that didn't
compile will continue to not compile (since a _noexcept-specifier_ is
not part of the deduction substitution
loci (see [temp.deduct.general] p7), and any code which
did compile should continue to do so.
2024-04-30 14:23:02 -04:00
|
|
|
- Clang now correctly treats the noexcept-specifier of a friend function to be a complete-class context.
|
2024-05-02 10:22:59 +03:00
|
|
|
- Fix an assertion failure when parsing an invalid members of an anonymous class. (#GH85447)
|
[clang] Distinguish unresolved templates in UnresolvedLookupExpr (#89019)
This patch revolves around the misuse of UnresolvedLookupExpr in
BuildTemplateIdExpr.
Basically, we build up an UnresolvedLookupExpr not only for function
overloads but for "unresolved" templates wherever we need an expression
for template decls. For example, a dependent VarTemplateDecl can be
wrapped with such an expression before template instantiation. (See
https://github.com/llvm/llvm-project/commit/617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9)
Also, one important thing is that UnresolvedLookupExpr uses a
"canonical"
QualType to describe the containing unresolved decls: a DependentTy is
for dependent expressions and an OverloadTy otherwise. Therefore, this
modeling for non-dependent templates leaves a problem in that the
expression
is marked and perceived as if describing overload functions. The
consumer then
expects functions for every such expression, although the fact is the
reverse.
Hence, we run into crashes.
As to the patch, I added a new canonical type "UnresolvedTemplateTy" to
model these cases. Given that we have been using this model
(intentionally or
accidentally) and it is pretty baked in throughout the code, I think
extending the role of UnresolvedLookupExpr is reasonable. Further, I
added
some diagnostics for the direct occurrence of these expressions, which
are supposed to be ill-formed.
As a bonus, this patch also fixes some typos in the diagnostics and
creates
RecoveryExprs rather than nothing in the hope of a better error-recovery
for clangd.
Fixes https://github.com/llvm/llvm-project/issues/88832
Fixes https://github.com/llvm/llvm-project/issues/63243
Fixes https://github.com/llvm/llvm-project/issues/48673
2024-05-05 11:38:49 +08:00
|
|
|
- Fixed a misuse of ``UnresolvedLookupExpr`` for ill-formed templated expressions. Fixes (#GH48673), (#GH63243)
|
|
|
|
and (#GH88832).
|
[Clang][Sema] Explicit template arguments are not substituted into the exception specification of a function (#90760)
[temp.deduct.general] p6 states:
> At certain points in the template argument deduction process it is
necessary to take a function type that makes use of template parameters
and replace those template parameters with the corresponding template
arguments.
This is done at the beginning of template argument deduction when any
explicitly specified template arguments are substituted into the
function type, and again at the end of template argument deduction when
any template arguments that were deduced or obtained from default
arguments are substituted.
[temp.deduct.general] p7 goes on to say:
> The _deduction substitution loci_ are
> - the function type outside of the _noexcept-specifier_,
> - the explicit-specifier,
> - the template parameter declarations, and
> - the template argument list of a partial specialization
>
> The substitution occurs in all types and expressions that are used in
the deduction substitution loci. [...]
Consider the following:
```cpp
struct A
{
static constexpr bool x = true;
};
template<typename T, typename U>
void f(T, U) noexcept(T::x); // #1
template<typename T, typename U>
void f(T, U*) noexcept(T::y); // #2
template<>
void f<A>(A, int*) noexcept; // clang currently accepts, GCC and EDG reject
```
Currently, `Sema::SubstituteExplicitTemplateArguments` will substitute
into the _noexcept-specifier_ when deducing template arguments from a
function declaration or when deducing template arguments for taking the
address of a function template (and the substitution is treated as a
SFINAE context). In the above example, `#1` is selected as the primary
template because substitution of the explicit template arguments into
the _noexcept-specifier_ of `#2` failed, which resulted in the candidate
being ignored.
This behavior is incorrect ([temp.deduct.general] note 4 says as much), and
this patch corrects it by deferring all substitution into the
_noexcept-specifier_ until it is instantiated.
As part of the necessary changes to make this patch work, the
instantiation of the exception specification of a function template
specialization when taking the address of a function template is changed
to only occur for the function selected by overload resolution per
[except.spec] p13.1 (as opposed to being instantiated for every candidate).
2024-05-07 20:04:57 -04:00
|
|
|
- Clang now defers all substitution into the exception specification of a function template specialization
|
|
|
|
until the noexcept-specifier is instantiated.
|
2024-05-07 20:09:19 -04:00
|
|
|
- Fix a crash when an implicitly declared ``operator==`` function with a trailing requires-clause has its
|
|
|
|
constraints compared to that of another declaration.
|
[Clang][Sema] Improve support for explicit specializations of constrained member functions & member function templates (#88963)
Consider the following snippet from the discussion of CWG2847 on the core reflector:
```
template<typename T>
concept C = sizeof(T) <= sizeof(long);
template<typename T>
struct A
{
template<typename U>
void f(U) requires C<U>; // #1, declares a function template
void g() requires C<T>; // #2, declares a function
template<>
void f(char); // #3, an explicit specialization of a function template that declares a function
};
template<>
template<typename U>
void A<short>::f(U) requires C<U>; // #4, an explicit specialization of a function template that declares a function template
template<>
template<>
void A<int>::f(int); // #5, an explicit specialization of a function template that declares a function
template<>
void A<long>::g(); // #6, an explicit specialization of a function that declares a function
```
A number of problems exist:
- Clang rejects `#4` because the trailing _requires-clause_ has `U`
substituted with the wrong template parameter depth when
`Sema::AreConstraintExpressionsEqual` is called to determine whether it
matches the trailing _requires-clause_ of the implicitly instantiated
function template.
- Clang rejects `#5` because the function template specialization
instantiated from `A<int>::f` has a trailing _requires-clause_, but `#5`
does not (nor can it have one as it isn't a templated function).
- Clang rejects `#6` for the same reasons it rejects `#5`.
This patch resolves these issues by making the following changes:
- To fix `#4`, `Sema::AreConstraintExpressionsEqual` is passed
`FunctionTemplateDecl`s when comparing the trailing _requires-clauses_
of `#4` and the function template instantiated from `#1`.
- To fix `#5` and `#6`, the trailing _requires-clauses_ are not compared
for explicit specializations that declare functions.
In addition to these changes, `CheckMemberSpecialization` now considers
constraint satisfaction/constraint partial ordering when determining
which member function is specialized by an explicit specialization of a
member function for an implicit instantiation of a class template (we
previously would select the first function that has the same type as the
explicit specialization). With constraints taken under consideration, we
match EDG's behavior for these declarations.
2024-05-07 21:41:33 -04:00
|
|
|
- Fix a bug where explicit specializations of member functions/function templates would have substitution
|
|
|
|
performed incorrectly when checking constraints. Fixes (#GH90349).
|
|
|
|
- Clang now allows constrained member functions to be explicitly specialized for an implicit instantiation
|
|
|
|
of a class template.
|
[Clang] Fix P2564 handling of variable initializers (#89565)
The following program produces a diagnostic in Clang and EDG, but
compiles correctly in GCC and MSVC:
```cpp
#include <vector>
consteval std::vector<int> fn() { return {1,2,3}; }
constexpr int a = fn()[1];
```
Clang's diagnostic is as follows:
```cpp
<source>:6:19: error: call to consteval function 'fn' is not a constant expression
6 | constexpr int a = fn()[1];
| ^
<source>:6:19: note: pointer to subobject of heap-allocated object is not a constant expression
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.1/../../../../include/c++/14.0.1/bits/allocator.h:193:31: note: heap allocation performed here
193 | return static_cast<_Tp*>(::operator new(__n));
| ^
1 error generated.
Compiler returned: 1
```
Based on my understanding of
[`[dcl.constexpr]/6`](https://eel.is/c++draft/dcl.constexpr#6):
> In any constexpr variable declaration, the full-expression of the
initialization shall be a constant expression
It seems to me that GCC and MSVC are correct: the initializer `fn()[1]`
does not evaluate to an lvalue referencing a heap-allocated value within
the `vector` returned by `fn()`; it evaluates to an lvalue-to-rvalue
conversion _from_ that heap-allocated value.
This PR turns out to be a bug fix on the implementation of
[P2564R3](https://wg21.link/p2564r3); as such, it only applies to C++23
and later. The core problem is that the definition of a
constant-initialized variable
([`[expr.const/2]`](https://eel.is/c++draft/expr.const#2)) is contingent
on whether the initializer can be evaluated as a constant expression:
> A variable or temporary object o is _constant-initialized_ if [...]
the full-expression of its initialization is a constant expression when
interpreted as a _constant-expression_, [...]
That can't be known until we've finished parsing the initializer, by
which time we've already added immediate invocations and consteval
references to the current expression evaluation context. This will have
the effect of evaluating said invocations as full expressions when the
context is popped, even if they're subexpressions of a larger constant
expression initializer. If, however, the variable _is_
constant-initialized, then its initializer is [manifestly
constant-evaluated](https://eel.is/c++draft/expr.const#20):
> An expression or conversion is _manifestly constant-evaluated_ if it
is [...] **the initializer of a variable that is usable in constant
expressions or has constant initialization** [...]
which in turn means that any subexpressions naming an immediate function
are in an [immediate function
context](https://eel.is/c++draft/expr.const#16):
> An expression or conversion is in an immediate function context if it
is potentially evaluated and either [...] it is a **subexpression of a
manifestly constant-evaluated expression** or conversion
and therefore _are not to be considered [immediate
invocations](https://eel.is/c++draft/expr.const#16) or
[immediate-escalating
expressions](https://eel.is/c++draft/expr.const#17) in the first place_:
> An invocation is an _immediate invocation_ if it is a
potentially-evaluated explicit or implicit invocation of an immediate
function and **is not in an immediate function context**.
> An expression or conversion is _immediate-escalating_ if **it is not
initially in an immediate function context** and [...]
The approach that I'm therefore proposing is:
1. Create a new expression evaluation context for _every_ variable
initializer (rather than only nonlocal ones).
2. Attach initializers to `VarDecl`s _prior_ to popping the expression
evaluation context / scope / etc. This sequences the determination of
whether the initializer is in an immediate function context _before_ any
contained immediate invocations are evaluated.
3. When popping an expression evaluation context, elide all evaluations
of constant invocations, and all checks for consteval references, if the
context is an immediate function context. Note that if it could be
ascertained that this was an immediate function context at parse-time,
we [would never have
registered](https://github.com/llvm/llvm-project/blob/760910ddb918d77e7632be1678f69909384d69ae/clang/lib/Sema/SemaExpr.cpp#L17799)
these immediate invocations or consteval references in the first place.
Most of the test changes previously made for this PR are now reverted
and passing as-is. The only test updates needed are now as follows:
- A few diagnostics in `consteval-cxx2a.cpp` are updated to reflect that
it is the `consteval tester::tester` constructor, not the more narrow
`make_name` function call, which fails to be evaluated as a constant
expression.
- The reclassification of `warn_impcast_integer_precision_constant` as a
compile-time diagnostic adds a (somewhat duplicative) warning when
attempting to define an enum constant using a narrowing conversion. It
also, however, retains the existing diagnostics which @erichkeane
(rightly) objected to being lost from an earlier revision of this PR.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
2024-05-09 03:22:11 -04:00
|
|
|
- Fix a C++23 bug in implementation of P2564R3 which evaluates immediate invocations in place
|
|
|
|
within initializers for variables that are usable in constant expressions or are constant
|
|
|
|
initialized, rather than evaluating them as a part of the larger manifestly constant evaluated
|
|
|
|
expression.
|
2024-05-10 20:14:08 +08:00
|
|
|
- Fix a bug in access control checking due to dealyed checking of friend declaration. Fixes (#GH12361).
|
2024-05-13 16:04:20 +02:00
|
|
|
- Correctly treat the compound statement of an ``if consteval`` as an immediate context. Fixes (#GH91509).
|
2024-05-13 14:28:05 -03:00
|
|
|
- When partial ordering alias templates against template template parameters,
|
|
|
|
allow pack expansions when the alias has a fixed-size parameter list. Fixes (#GH62529).
|
2024-05-15 18:55:53 -04:00
|
|
|
- Clang now ignores template parameters only used within the exception specification of candidate function
|
|
|
|
templates during partial ordering when deducing template arguments from a function declaration or when
|
|
|
|
taking the address of a function template.
|
2024-05-16 14:10:46 -04:00
|
|
|
- Fix a bug with checking constrained non-type template parameters for equivalence. Fixes (#GH77377).
|
2024-05-17 17:00:43 +01:00
|
|
|
- Fix a bug where the last argument was not considered when considering the most viable function for
|
|
|
|
explicit object argument member functions. Fixes (#GH92188).
|
2024-05-20 12:04:07 -04:00
|
|
|
- Fix a C++11 crash when a non-const non-static member function is defined out-of-line with
|
|
|
|
the ``constexpr`` specifier. Fixes (#GH61004).
|
2024-05-20 13:55:01 -04:00
|
|
|
- Clang no longer transforms dependent qualified names into implicit class member access expressions
|
|
|
|
until it can be determined whether the name is that of a non-static member.
|
2024-05-20 14:44:59 -04:00
|
|
|
- Clang now correctly diagnoses when the current instantiation is used as an incomplete base class.
|
2024-05-20 14:50:58 -04:00
|
|
|
- Clang no longer treats ``constexpr`` class scope function template specializations of non-static members
|
|
|
|
as implicitly ``const`` in language modes after C++11.
|
2024-05-22 20:15:44 +02:00
|
|
|
- Fixed a crash when trying to emit captures in a lambda call operator with an explicit object
|
|
|
|
parameter that is called on a derived type of the lambda.
|
|
|
|
Fixes (#GH87210), (GH89541).
|
2024-05-23 17:53:07 +02:00
|
|
|
- Clang no longer tries to check if an expression is immediate-escalating in an unevaluated context.
|
|
|
|
Fixes (#GH91308).
|
2024-05-26 09:18:33 +02:00
|
|
|
- Fix a crash caused by a regression in the handling of ``source_location``
|
|
|
|
in dependent contexts. Fixes (#GH92680).
|
2024-05-27 12:18:15 +02:00
|
|
|
- Fixed a crash when diagnosing failed conversions involving template parameter
|
|
|
|
packs. (#GH93076)
|
2024-05-27 14:17:10 +02:00
|
|
|
- Fixed a regression introduced in Clang 18 causing a static function overloading a non-static function
|
|
|
|
with the same parameters not to be diagnosed. (Fixes #GH93456).
|
2024-05-27 18:17:07 +02:00
|
|
|
- Clang now diagnoses unexpanded parameter packs in attributes. (Fixes #GH93269).
|
2024-05-28 15:38:02 +02:00
|
|
|
- Clang now allows ``@$``` in raw string literals. Fixes (#GH93130).
|
2024-05-28 19:08:38 +03:00
|
|
|
- Fix an assertion failure when checking invalid ``this`` usage in the wrong context. (Fixes #GH91536).
|
2024-05-29 12:58:44 +08:00
|
|
|
- Clang no longer models dependent NTTP arguments as ``TemplateParamObjectDecl`` s. Fixes (#GH84052).
|
2024-05-30 03:43:27 -03:00
|
|
|
- Fix incorrect merging of modules which contain using declarations which shadow
|
|
|
|
other declarations. This could manifest as ODR checker false positives.
|
|
|
|
Fixes (`#80252 <https://github.com/llvm/llvm-project/issues/80252>`_)
|
2024-05-30 17:22:07 +02:00
|
|
|
- Fix a regression introduced in Clang 18 causing incorrect overload resolution in the presence of functions only
|
|
|
|
differering by their constraints when only one of these function was variadic.
|
2024-05-30 16:52:37 -07:00
|
|
|
- Fix a crash when a variable is captured by a block nested inside a lambda. (Fixes #GH93625).
|
2024-06-01 16:16:15 +08:00
|
|
|
- Fixed a type constraint substitution issue involving a generic lambda expression. (#GH93821)
|
2024-06-03 16:28:14 +03:00
|
|
|
- Fix a crash caused by improper use of ``__array_extent``. (#GH80474)
|
2024-06-04 12:44:01 +08:00
|
|
|
- Fixed several bugs in capturing variables within unevaluated contexts. (#GH63845), (#GH67260), (#GH69307),
|
2024-07-12 09:51:46 +08:00
|
|
|
(#GH88081), (#GH89496), (#GH90669), (#GH91633) and (#GH97453).
|
2024-07-09 16:39:50 +08:00
|
|
|
- Fixed a crash in constraint instantiation under nested lambdas with dependent parameters.
|
[Clang] Fix handling of brace ellison when building deduction guides (#94889)
Fixes two issues in two ways:
1) The `braced-init-list` consisted of `initializer-list` and
`designated-initializer-list`, and thus the designated initializer is
subject to [over.match.class.deduct]p1.8, which means the brace elision
is also applicable on it for CTAD deduction guides.
2) When forming a deduction guide where the brace elision is applicable,
we should also consider the presence of braces within the initializer.
For example, given
template <class T, class U> struct X {
T t[2];
U u[3];
};
X x = {{1, 2}, 3, 4, 5};
we should establish such deduction guide AFAIU: `X(T (&&)[2], U, U, U) -> X<T, U>`.
Fixes https://github.com/llvm/llvm-project/issues/64625
Fixes https://github.com/llvm/llvm-project/issues/83368
2024-06-13 17:47:03 +08:00
|
|
|
- Fixed handling of brace ellison when building deduction guides. (#GH64625), (#GH83368).
|
2024-06-16 21:54:19 +08:00
|
|
|
- Clang now instantiates local constexpr functions eagerly for constant evaluators. (#GH35052), (#GH94849)
|
2024-06-17 20:29:28 +03:00
|
|
|
- Fixed a failed assertion when attempting to convert an integer representing the difference
|
|
|
|
between the addresses of two labels (a GNU extension) to a pointer within a constant expression. (#GH95366).
|
2024-06-18 15:40:25 +02:00
|
|
|
- Fix immediate escalation bugs in the presence of dependent call arguments. (#GH94935)
|
2024-06-18 13:40:31 -04:00
|
|
|
- Clang now diagnoses explicit specializations with storage class specifiers in all contexts.
|
2024-06-21 15:18:14 +03:00
|
|
|
- Fix an assertion failure caused by parsing a lambda used as a default argument for the value of a
|
|
|
|
forward-declared class. (#GH93512).
|
2024-06-22 15:31:03 +08:00
|
|
|
- Fixed a bug in access checking inside return-type-requirement of compound requirements. (#GH93788).
|
2024-06-28 22:28:20 +08:00
|
|
|
- Fixed an assertion failure about invalid conversion when calling lambda. (#GH96205).
|
2024-07-03 18:19:58 -04:00
|
|
|
- Fixed a bug where the first operand of binary ``operator&`` would be transformed as if it was the operand
|
|
|
|
of the address of operator. (#GH97483).
|
2024-07-06 16:28:23 +08:00
|
|
|
- Fixed an assertion failure about a constant expression which is a known integer but is not
|
|
|
|
evaluated to an integer. (#GH96670).
|
2024-07-07 09:46:38 +08:00
|
|
|
- Fixed a bug where references to lambda capture inside a ``noexcept`` specifier were not correctly
|
|
|
|
instantiated. (#GH95735).
|
2024-07-10 12:51:27 +08:00
|
|
|
- Fixed a CTAD substitution bug involving type aliases that reference outer template parameters. (#GH94614).
|
2024-07-11 17:58:15 +02:00
|
|
|
- Clang now correctly handles unexpanded packs in the template parameter list of a generic lambda expression
|
|
|
|
(#GH48937)
|
2024-07-12 13:12:14 +02:00
|
|
|
- Fix a crash when parsing an invalid type-requirement in a requires expression. (#GH51868)
|
2024-07-13 08:53:02 +02:00
|
|
|
- Fix parsing of built-in type-traits such as ``__is_pointer`` in libstdc++ headers. (#GH95598)
|
2024-04-02 21:36:56 +05:30
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Bug Fixes to AST Handling
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
2024-03-14 10:09:47 +08:00
|
|
|
- Clang now properly preserves ``FoundDecls`` within a ``ConceptReference``. (#GH82628)
|
2024-04-11 13:20:05 -04:00
|
|
|
- The presence of the ``typename`` keyword is now stored in ``TemplateTemplateParmDecl``.
|
[Clang][Sema] Fix malformed AST for anonymous class access in template. (#90842)
# Observed erroneous behavior
Prior to this change, a `MemberExpr` that accesses an anonymous class
might have a prvalue as its base (even though C++ mandates that the base
of a `MemberExpr` must be a glvalue), if the code containing the
`MemberExpr` was in a template.
Here's an example on [godbolt](https://godbolt.org/z/Gz1Mer9oz) (that is
essentially identical to the new test this patch adds).
This example sets up a struct containing an anonymous struct:
```cxx
struct S {
struct {
int i;
};
};
```
It then accesses the member `i` using the expression `S().i`.
When we do this in a non-template function, we get the following AST:
```
`-ExprWithCleanups <col:10, col:14> 'int'
`-ImplicitCastExpr <col:10, col:14> 'int' <LValueToRValue>
`-MemberExpr <col:10, col:14> 'int' xvalue .i 0xbdcb3c0
`-MemberExpr <col:10, col:14> 'S::(anonymous struct at line:2:3)' xvalue .S::(anonymous struct at line:2:3) 0xbdcb488
`-MaterializeTemporaryExpr <col:10, col:12> 'S' xvalue
`-CXXTemporaryObjectExpr <col:10, col:12> 'S' 'void () noexcept' zeroing
```
As expected, the AST contains a `MaterializeTemporarExpr` to materialize
the prvalue `S()` before accessing its members.
When we perform this access in a function template (that doesn't
actually even use its template parameter), the AST for the template
itself looks the same as above. However, the AST for an instantiation of
the template looks different:
```
`-ExprWithCleanups <col:10, col:14> 'int'
`-ImplicitCastExpr <col:10, col:14> 'int' <LValueToRValue>
`-MemberExpr <col:10, col:14> 'int' xvalue .i 0xbdcb3c0
`-MaterializeTemporaryExpr <col:10, col:14> 'S::(anonymous struct at line:2:3)' xvalue
`-MemberExpr <col:10, col:14> 'S::(anonymous struct at line:2:3)' .S::(anonymous struct at line:2:3) 0xbdcb488
`-CXXTemporaryObjectExpr <col:10, col:12> 'S' 'void () noexcept' zeroing
```
Note how the inner `MemberExpr` (the one accessing the anonymous struct)
acts on a prvalue.
Interestingly, this does not appear to cause any problems for CodeGen,
probably because CodeGen is set up to deal with `MemberExpr`s on rvalues
in C. However, it does cause issues in the dataflow framework, which
only supports C++ today and expects the base of a `MemberExpr` to be a
glvalue.
Beyond the issues with the dataflow framework, I think this issue should
be fixed because it goes contrary to what the C++ standard mandates, and
the AST produced for the non-template case indicates that we want to
follow the C++ rules here.
# Reasons for erroneous behavior
Here's why we're getting this malformed AST.
First of all, `TreeTransform` [strips any
`MaterializeTemporaryExpr`s](https://github.com/llvm/llvm-project/blob/cd132dcbeb0fc79fd657bd5e0a8e9244c3fb5da6/clang/lib/Sema/TreeTransform.h#L14853)
from the AST.
It is therefore up to
[`TreeTransform::RebuildMemberExpr()`](https://github.com/llvm/llvm-project/blob/cd132dcbeb0fc79fd657bd5e0a8e9244c3fb5da6/clang/lib/Sema/TreeTransform.h#L2853)
to recreate a `MaterializeTemporaryExpr` if needed. In the [general
case](https://github.com/llvm/llvm-project/blob/cd132dcbeb0fc79fd657bd5e0a8e9244c3fb5da6/clang/lib/Sema/TreeTransform.h#L2915),
it does this: It calls `Sema::BuildMemberReferenceExpr()`, which ensures
that the base is a glvalue by [materializing a
temporary](https://github.com/llvm/llvm-project/blob/cd132dcbeb0fc79fd657bd5e0a8e9244c3fb5da6/clang/lib/Sema/SemaExprMember.cpp#L1016)
if needed. However, when `TreeTransform::RebuildMemberExpr()` encounters
an anonymous class, it [calls
`Sema::BuildFieldReferenceExpr()`](https://github.com/llvm/llvm-project/blob/cd132dcbeb0fc79fd657bd5e0a8e9244c3fb5da6/clang/lib/Sema/TreeTransform.h#L2880),
which, unlike `Sema::BuildMemberReferenceExpr()`, does not make sure
that the base is a glvalue.
# Proposed fix
I considered several possible ways to fix this issue:
- Add logic to `Sema::BuildFieldReferenceExpr()` that materializes a
temporary if needed. This appears to work, but it feels like the fix is
in the wrong place:
- AFAIU, other callers of `Sema::BuildFieldReferenceExpr()` don't need
this logic.
- The issue is caused by `TreeTransform` removing the
`MaterializeTemporaryExpr`, so it seems the fix should also be in
`TreeTransform`
- Materialize the temporary directly in
`TreeTransform::RebuildMemberExpr()` if needed (within the case that
deals with anonymous classes).
This would work, too, but it would duplicate logic that already exists
in `Sema::BuildMemberReferenceExpr()` (which we leverage for the general
case).
- Use `Sema::BuildMemberReferenceExpr()` instead of
`Sema::BuildFieldReferenceExpr()` for the anonymous class case, so that
it also uses the existing logic for materializing the temporary.
This is the option I've decided to go with here. There's a slight
wrinkle in that we create a `LookupResult` that claims we looked up the
unnamed field for the anonymous class -- even though we would obviously
never be able to look up an unnamed field. I think this is defensible
and still better than the other alternatives, but I would welcome
feedback on this from others who know the code better.
2024-05-14 09:45:54 +02:00
|
|
|
- Fixed malformed AST generated for anonymous union access in templates. (#GH90842)
|
2024-05-29 17:02:15 -03:00
|
|
|
- Improved preservation of qualifiers and sugar in `TemplateNames`, including
|
|
|
|
template keyword.
|
2023-01-17 11:29:04 -08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Miscellaneous Bug Fixes
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-04-20 10:11:02 +08:00
|
|
|
- Fixed an infinite recursion in ASTImporter, on return type declared inside
|
|
|
|
body of C++11 lambda without trailing return (#GH68775).
|
2024-05-22 17:41:31 +02:00
|
|
|
- Fixed declaration name source location of instantiated function definitions (GH71161).
|
2024-05-24 11:38:22 -03:00
|
|
|
- Improve diagnostic output to print an expression instead of 'no argument` when comparing Values as template arguments.
|
2024-04-20 10:11:02 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Miscellaneous Clang Crashes Fixed
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-05-03 14:13:56 -04:00
|
|
|
|
2024-03-04 14:04:35 +01:00
|
|
|
- Do not attempt to dump the layout of dependent types or invalid declarations
|
2024-04-16 09:00:57 -04:00
|
|
|
when ``-fdump-record-layouts-complete`` is passed. Fixes #GH83684.
|
2024-05-24 11:33:16 -03:00
|
|
|
- Unhandled StructuralValues in the template differ (#GH93068).
|
2024-03-04 14:04:35 +01:00
|
|
|
|
2023-11-17 06:29:02 -08:00
|
|
|
OpenACC Specific Changes
|
|
|
|
------------------------
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Target Specific Changes
|
|
|
|
-----------------------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2023-03-13 09:33:08 -05:00
|
|
|
AMDGPU Support
|
|
|
|
^^^^^^^^^^^^^^
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
X86 Support
|
|
|
|
^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-05-24 13:46:34 +08:00
|
|
|
- Remove knl/knm specific ISA supports: AVX512PF, AVX512ER, PREFETCHWT1
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Arm and AArch64 Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-02-22 14:26:11 -08:00
|
|
|
- ARMv7+ targets now default to allowing unaligned access, except Armv6-M, and
|
|
|
|
Armv8-M without the Main Extension. Baremetal targets should check that the
|
|
|
|
new default will work with their system configurations, since it requires
|
|
|
|
that SCTLR.A is 0, SCTLR.U is 1, and that the memory in question is
|
|
|
|
configured as "normal" memory. This brings Clang in-line with the default
|
|
|
|
settings for GCC and Arm Compiler. Aside from making Clang align with other
|
|
|
|
compilers, changing the default brings major performance and code size
|
|
|
|
improvements for most targets. We have not changed the default behavior for
|
|
|
|
ARMv6, but may revisit that decision in the future. Users can restore the old
|
|
|
|
behavior with -m[no-]unaligned-access.
|
2024-03-01 21:06:08 +00:00
|
|
|
- An alias identifier (rdma) has been added for targeting the AArch64
|
|
|
|
Architecture Extension which uses Rounding Doubling Multiply Accumulate
|
|
|
|
instructions (rdm). The identifier is available on the command line as
|
|
|
|
a feature modifier for -march and -mcpu as well as via target attributes
|
|
|
|
like ``target_version`` or ``target_clones``.
|
2024-03-08 16:11:36 +00:00
|
|
|
- Support has been added for the following processors (-mcpu identifiers in parenthesis):
|
2024-06-13 00:00:57 +01:00
|
|
|
* Arm Cortex-R52+ (cortex-r52plus).
|
|
|
|
* Arm Cortex-R82AE (cortex-r82ae).
|
2024-03-08 16:11:36 +00:00
|
|
|
* Arm Cortex-A78AE (cortex-a78ae).
|
2024-03-19 10:04:51 +00:00
|
|
|
* Arm Cortex-A520AE (cortex-a520ae).
|
|
|
|
* Arm Cortex-A720AE (cortex-a720ae).
|
2024-06-13 00:00:57 +01:00
|
|
|
* Arm Cortex-A725 (cortex-a725).
|
|
|
|
* Arm Cortex-X925 (cortex-x925).
|
2024-04-26 13:04:35 +01:00
|
|
|
* Arm Neoverse-N3 (neoverse-n3).
|
|
|
|
* Arm Neoverse-V3 (neoverse-v3).
|
|
|
|
* Arm Neoverse-V3AE (neoverse-v3ae).
|
2024-02-22 14:26:11 -08:00
|
|
|
|
2023-08-31 18:04:56 -07:00
|
|
|
Android Support
|
|
|
|
^^^^^^^^^^^^^^^
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
Windows Support
|
|
|
|
^^^^^^^^^^^^^^^
|
[clang] [MinGW] Add the option -fno-auto-import
In GCC, the .refptr stubs are only generated for x86_64, and only
for code models medium and larger (and medium is the default for
x86_64 since this was introduced). They can be omitted for
projects that are conscious about performance and size, and don't
need automatically importing dll data members, by passing -mcmodel=small.
In Clang/LLVM, such .refptr stubs are generated for any potentially
symbol reference that might end up autoimported. The .refptr stubs
are emitted for three separate reasons:
- Without .refptr stubs, undefined symbols are mostly referenced
with 32 bit wide relocations. If the symbol ends up autoimported
from a different DLL, a 32 bit relative offset might not be
enough to reference data in a different DLL, depending on runtime
loader layout.
- Without .refptr stubs, the runtime pseudo relocation mechanism
will need to temporarily make sections read-write-executable
if there are such relocations in the text section
- On ARM and AArch64, the immediate addressing encoded into
instructions isn't in the form of a plain 32 bit relative offset,
but is expressed with various bits scattered throughout two
instructions - the mingw runtime pseudo relocation mechanism
doesn't support updating offsets in that form.
If autoimporting is known not to be needed, the user can now
compile with -fno-auto-import, avoiding the extra overhead of
the .refptr stubs.
However, omitting them is potentially fragile as the code
might still rely on automatically importing some symbol without
the developer knowing. If this happens, linking still usually
will succeed, but users may encounter issues at runtime.
Therefore, if the new option -fno-auto-import is passed to the compiler
when driving linking, it passes the flag --disable-auto-import to
the linker, making sure that no symbols actually are autoimported
when the generated code doesn't expect it.
Differential Revision: https://reviews.llvm.org/D61670
2019-05-08 11:45:26 +03:00
|
|
|
|
2024-06-14 10:23:33 +02:00
|
|
|
- The clang-cl ``/Ot`` compiler option ("optimize for speed", also implied by
|
|
|
|
``/O2``) now maps to clang's ``-O3`` optimizataztion level instead of ``-O2``.
|
|
|
|
Users who prefer the old behavior can use ``clang-cl /Ot /clang:-O2 ...``.
|
|
|
|
|
2024-03-19 08:30:54 -04:00
|
|
|
- Clang-cl now supports function targets with intrinsic headers. This allows
|
|
|
|
for runtime feature detection of intrinsics. Previously under clang-cl
|
|
|
|
``immintrin.h`` and similar intrinsic headers would only include the intrinsics
|
|
|
|
if building with that feature enabled at compile time, e.g. ``avxintrin.h``
|
|
|
|
would only be included if AVX was enabled at compile time. This was done to work
|
|
|
|
around include times from MSVC STL including ``intrin.h`` under clang-cl.
|
|
|
|
Clang-cl now provides ``intrin0.h`` for MSVC STL and therefore all intrinsic
|
2024-04-16 09:00:57 -04:00
|
|
|
features without requiring enablement at compile time. Fixes #GH53520
|
2024-03-19 08:30:54 -04:00
|
|
|
|
|
|
|
- Improved compile times with MSVC STL. MSVC provides ``intrin0.h`` which is a
|
|
|
|
header that only includes intrinsics that are used by MSVC STL to avoid the
|
|
|
|
use of ``intrin.h``. MSVC STL when compiled under clang uses ``intrin.h``
|
|
|
|
instead. Clang-cl now provides ``intrin0.h`` for the same compiler throughput
|
|
|
|
purposes as MSVC. Clang-cl also provides ``yvals_core.h`` to redefine
|
|
|
|
``_STL_INTRIN_HEADER`` to expand to ``intrin0.h`` instead of ``intrin.h``.
|
|
|
|
This also means that if all intrinsic features are enabled at compile time
|
|
|
|
including STL headers will no longer slow down compile times since ``intrin.h``
|
|
|
|
is not included from MSVC STL.
|
|
|
|
|
2024-05-24 19:12:38 -04:00
|
|
|
- When the target triple is `*-windows-msvc` strict aliasing is now disabled by default
|
|
|
|
to ensure compatibility with msvc. Previously strict aliasing was only disabled if the
|
|
|
|
driver mode was cl.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
LoongArch Support
|
|
|
|
^^^^^^^^^^^^^^^^^
|
2024-01-23 15:27:06 +08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
RISC-V Support
|
|
|
|
^^^^^^^^^^^^^^
|
2023-12-15 11:16:05 +08:00
|
|
|
|
2024-01-25 19:19:28 -08:00
|
|
|
- ``__attribute__((rvv_vector_bits(N)))`` is now supported for RVV vbool*_t types.
|
2024-03-22 18:24:23 +08:00
|
|
|
- Profile names in ``-march`` option are now supported.
|
2024-07-09 06:47:51 +05:30
|
|
|
- Passing empty structs/unions as arguments in C++ is now handled correctly. The behavior is similar to GCC's.
|
2024-07-14 13:39:17 -07:00
|
|
|
- ``-m[no-]scalar-strict-align`` and ``-m[no-]vector-strict-align`` options have
|
|
|
|
been added to give separate control of whether scalar or vector misaligned
|
|
|
|
accesses may be created. ``-m[no-]strict-align`` applies to both scalar and
|
|
|
|
vector.
|
2024-01-25 09:39:29 -08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
CUDA/HIP Language Changes
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
2022-10-18 10:50:37 -07:00
|
|
|
|
2024-03-09 20:47:29 +03:30
|
|
|
- PTX is no longer included by default when compiling for CUDA. Using
|
2024-03-07 16:53:41 -06:00
|
|
|
``--cuda-include-ptx=all`` will return the old behavior.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
CUDA Support
|
|
|
|
^^^^^^^^^^^^
|
2024-06-05 13:09:24 -04:00
|
|
|
- Clang now supports CUDA SDK up to 12.5
|
2022-01-23 20:45:25 -08:00
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
AIX Support
|
|
|
|
^^^^^^^^^^^
|
[Clang][AArch64] Support AArch64 target(..) attribute formats.
This adds support under AArch64 for the target("..") attributes. The
current parsing is very X86-shaped, this patch attempts to bring it line
with the GCC implementation from
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes.
The supported formats are:
- "arch=<arch>" strings, that specify the architecture features for a
function as per the -march=arch+feature option.
- "cpu=<cpu>" strings, that specify the target-cpu and any implied
atributes as per the -mcpu=cpu+feature option.
- "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as
per -mtune.
- "+<feature>", "+no<feature>" enables/disables the specific feature, for
compatibility with GCC target attributes.
- "<feature>", "no-<feature>" enabled/disables the specific feature, for
backward compatibility with previous releases.
To do this, the parsing of target attributes has been moved into
TargetInfo to give the target the opportunity to override the existing
parsing. The only non-aarch64 change should be a minor alteration to the
error message, specifying using "CPU" to describe the cpu, not
"architecture", and the DuplicateArch/Tune from ParsedTargetAttr have
been combined into a single option.
Differential Revision: https://reviews.llvm.org/D133848
2022-10-01 15:40:59 +01:00
|
|
|
|
2024-04-23 08:44:25 +08:00
|
|
|
- Introduced the ``-maix-small-local-dynamic-tls`` option to produce a faster
|
|
|
|
access sequence for local-dynamic TLS variables where the offset from the TLS
|
|
|
|
base is encoded as an immediate operand.
|
|
|
|
This access sequence is not used for TLS variables larger than 32KB, and is
|
|
|
|
currently only supported on 64-bit mode.
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
WebAssembly Support
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
[ARM] Allow selecting hard-float ABI in integer-only MVE.
Armv8.1-M can be configured to support the integer subset of the MVE
vector instructions, and no floating point. In that situation, the FP
and vector registers still exist, and so do the load, store and move
instructions that transfer data in and out of them. So there's no
reason the hard floating point ABI can't be supported, and you might
reasonably want to use it, for the sake of intrinsics-based code
passing explicit MVE vector types between functions.
But the selection of the hard float ABI in the backend was gated on
Subtarget->hasVFP2Base(), which is false in the case of integer MVE
and no FP.
As a result, you'd silently get the soft float ABI even if you
deliberately tried to select it, e.g. with clang options such as
--target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+nofp+mve
The hard float ABI should have been gated on the weaker condition
Subtarget->hasFPRegs(), because the only requirement for being able to
pass arguments in the FP registers is that the registers themselves
should exist.
I haven't added a new test, because changing the existing
CodeGen/Thumb2/float-ops.ll test seemed sufficient. But I've added a
comment explaining why the results are expected to be what they are.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D142703
2023-01-31 17:31:33 +00:00
|
|
|
|
2024-06-20 13:03:36 -07:00
|
|
|
The -mcpu=generic configuration now enables multivalue and reference-types.
|
|
|
|
These proposals are standardized and available in all major engines. Enabling
|
|
|
|
multivalue here only enables the language feature but does not turn on the
|
|
|
|
multivalue ABI (this enables non-ABI uses of multivalue, like exnref).
|
2024-04-29 14:23:08 -07:00
|
|
|
|
2022-02-06 08:20:54 -05:00
|
|
|
AVR Support
|
|
|
|
^^^^^^^^^^^
|
|
|
|
|
2023-02-15 23:53:38 +02:00
|
|
|
DWARF Support in Clang
|
|
|
|
----------------------
|
2023-02-13 18:29:16 +00:00
|
|
|
|
2021-11-09 09:35:25 -05:00
|
|
|
Floating Point Support in Clang
|
|
|
|
-------------------------------
|
|
|
|
|
2024-02-14 14:11:56 -08:00
|
|
|
Fixed Point Support in Clang
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
- Support fixed point precision macros according to ``7.18a.3`` of
|
|
|
|
`ISO/IEC TR 18037:2008 <https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip>`_.
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
AST Matchers
|
|
|
|
------------
|
|
|
|
|
2024-04-10 13:24:19 -04:00
|
|
|
- Fixes a long-standing performance issue in parent map generation for
|
|
|
|
ancestry-based matchers such as ``hasParent`` and ``hasAncestor``, making
|
|
|
|
them significantly faster.
|
2024-02-15 14:55:25 +01:00
|
|
|
- ``isInStdNamespace`` now supports Decl declared with ``extern "C++"``.
|
2024-03-08 13:57:27 +01:00
|
|
|
- Add ``isExplicitObjectMemberFunction``.
|
2024-03-12 17:31:22 +01:00
|
|
|
- Fixed ``forEachArgumentWithParam`` and ``forEachArgumentWithParamType`` to
|
|
|
|
not skip the explicit object parameter for operator calls.
|
2024-04-09 15:11:29 +08:00
|
|
|
- Fixed captureVars assertion failure if not capturesVariables. (#GH76425)
|
2024-06-05 10:20:37 +02:00
|
|
|
- ``forCallable`` now properly preserves binding on successful match. (#GH89657)
|
2024-02-15 14:55:25 +01:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
clang-format
|
|
|
|
------------
|
|
|
|
|
2024-02-09 19:53:04 -08:00
|
|
|
- ``AlwaysBreakTemplateDeclarations`` is deprecated and renamed to
|
|
|
|
``BreakTemplateDeclarations``.
|
2024-02-13 14:58:33 +10:30
|
|
|
- ``AlwaysBreakAfterReturnType`` is deprecated and renamed to
|
|
|
|
``BreakAfterReturnType``.
|
2024-05-27 15:20:58 -07:00
|
|
|
- Handles Java switch expressions.
|
2024-05-06 19:55:55 -07:00
|
|
|
- Adds ``AllowShortCaseExpressionOnASingleLine`` option.
|
|
|
|
- Adds ``AlignCaseArrows`` suboption to ``AlignConsecutiveShortCaseStatements``.
|
2024-05-27 15:20:58 -07:00
|
|
|
- Adds ``LeftWithLastLine`` suboption to ``AlignEscapedNewlines``.
|
2024-06-30 00:45:25 +00:00
|
|
|
- Adds ``KeepEmptyLines`` option to deprecate ``KeepEmptyLinesAtEOF``
|
|
|
|
and ``KeepEmptyLinesAtTheStartOfBlocks``.
|
2024-07-02 01:00:14 -06:00
|
|
|
- Add ``ExceptDoubleParentheses`` sub-option for ``SpacesInParensOptions``
|
|
|
|
to override addition of spaces between multiple, non-redundant parentheses
|
|
|
|
similar to the rules used for ``RemoveParentheses``.
|
2024-02-09 19:53:04 -08:00
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
libclang
|
|
|
|
--------
|
2022-08-25 08:35:46 +02:00
|
|
|
|
2024-04-24 20:01:19 +02:00
|
|
|
- ``clang_getSpellingLocation`` now correctly resolves macro expansions; that
|
|
|
|
is, it returns the spelling location instead of the expansion location.
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Static Analyzer
|
|
|
|
---------------
|
2023-07-24 08:26:54 +02:00
|
|
|
|
2024-07-10 16:53:12 +02:00
|
|
|
New features
|
|
|
|
^^^^^^^^^^^^
|
|
|
|
|
|
|
|
- The attribute ``[[clang::suppress]]`` can now be applied to declarations.
|
|
|
|
(#GH80371)
|
|
|
|
|
|
|
|
- Support C++23 static operator calls. (#GH84972)
|
|
|
|
|
|
|
|
Crash and bug fixes
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
2024-03-14 16:16:40 +08:00
|
|
|
- Fixed crashing on loops if the loop variable was declared in switch blocks
|
|
|
|
but not under any case blocks if ``unroll-loops=true`` analyzer config is
|
|
|
|
set. (#GH68819)
|
2024-07-10 16:53:12 +02:00
|
|
|
|
2024-04-17 08:02:49 +02:00
|
|
|
- Fixed a crash in ``security.cert.env.InvalidPtr`` checker when accidentally
|
2024-07-10 16:53:12 +02:00
|
|
|
matched user-defined ``strerror`` and similar library functions. (#GH88181)
|
2024-03-14 16:16:40 +08:00
|
|
|
|
2024-07-10 16:53:12 +02:00
|
|
|
- Fixed a crash when storing through an address that refers to the address of
|
|
|
|
a label. (#GH89185)
|
2023-12-28 15:48:59 +01:00
|
|
|
|
2024-07-10 16:53:12 +02:00
|
|
|
- Z3 crosschecking (aka. Z3 refutation) is now bounded, and can't consume
|
|
|
|
more total time than the eymbolic execution itself. (#GH97298)
|
2023-12-28 15:48:59 +01:00
|
|
|
|
|
|
|
Improvements
|
|
|
|
^^^^^^^^^^^^
|
|
|
|
|
|
|
|
Moved checkers
|
|
|
|
^^^^^^^^^^^^^^
|
|
|
|
|
2024-07-10 16:53:12 +02:00
|
|
|
- Moved ``alpha.cplusplus.ArrayDelete`` out of the ``alpha`` package
|
|
|
|
to ``cplusplus.ArrayDelete``. (#GH83985)
|
|
|
|
`Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#cplusplus-arraydelete-c>`__.
|
|
|
|
|
|
|
|
- Moved ``alpha.unix.Stream`` out of the ``alpha`` package to
|
|
|
|
``unix.Stream``. (#GH89247)
|
|
|
|
`Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#unix-stream-c>`__.
|
|
|
|
|
|
|
|
- Moved ``alpha.unix.BlockInCriticalSection`` out of the ``alpha`` package to
|
|
|
|
``unix.BlockInCriticalSection``. (#GH93815)
|
|
|
|
`Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#unix-blockincriticalsection-c-c>`__.
|
|
|
|
|
|
|
|
- Moved ``alpha.security.cert.pos.34c`` out of the ``alpha`` package to
|
|
|
|
``security.PutenvStackArray``. (#GH92424, #GH93815)
|
|
|
|
`Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#security-putenvstackarray-c>`__.
|
|
|
|
|
|
|
|
- Moved ``alpha.core.SizeofPtr`` into ``clang-tidy``
|
|
|
|
``bugprone-sizeof-expression``. (#GH95118, #GH94356)
|
|
|
|
`Documentation <https://clang.llvm.org/extra/clang-tidy/checks/bugprone/sizeof-expression.html>`__.
|
|
|
|
|
2022-09-26 17:41:37 -07:00
|
|
|
.. _release-notes-sanitizers:
|
|
|
|
|
|
|
|
Sanitizers
|
|
|
|
----------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-02-21 13:00:08 -08:00
|
|
|
- ``-fsanitize=signed-integer-overflow`` now instruments signed arithmetic even
|
|
|
|
when ``-fwrapv`` is enabled. Previously, only division checks were enabled.
|
|
|
|
|
|
|
|
Users with ``-fwrapv`` as well as a sanitizer group like
|
|
|
|
``-fsanitize=undefined`` or ``-fsanitize=integer`` enabled may want to
|
|
|
|
manually disable potentially noisy signed integer overflow checks with
|
|
|
|
``-fno-sanitize=signed-integer-overflow``
|
|
|
|
|
2024-03-27 03:25:33 +03:00
|
|
|
- ``-fsanitize=cfi -fsanitize-cfi-cross-dso`` (cross-DSO CFI instrumentation)
|
|
|
|
now generates the ``__cfi_check`` function with proper target-specific
|
|
|
|
attributes, for example allowing unwind table generation.
|
|
|
|
|
2023-04-04 09:21:04 -04:00
|
|
|
Python Binding Changes
|
|
|
|
----------------------
|
2020-02-13 22:46:33 +01:00
|
|
|
|
2024-01-29 11:19:34 -05:00
|
|
|
- Exposed `CXRewriter` API as `class Rewriter`.
|
2024-03-18 22:13:10 +08:00
|
|
|
- Add some missing kinds from Index.h (CursorKind: 149-156, 272-320, 420-437.
|
|
|
|
TemplateArgumentKind: 5-9. TypeKind: 161-175 and 178).
|
2024-01-29 11:19:34 -05:00
|
|
|
|
2024-03-12 13:42:43 +01:00
|
|
|
OpenMP Support
|
|
|
|
--------------
|
|
|
|
|
|
|
|
- Added support for the `[[omp::assume]]` attribute.
|
|
|
|
|
2020-02-13 22:46:33 +01:00
|
|
|
Additional Information
|
|
|
|
======================
|
|
|
|
|
|
|
|
A wide variety of additional information is available on the `Clang web
|
|
|
|
page <https://clang.llvm.org/>`_. The web page contains versions of the
|
2020-03-22 22:18:40 +01:00
|
|
|
API documentation which are up-to-date with the Git version of
|
2020-02-13 22:46:33 +01:00
|
|
|
the source code. You can access versions of these documents specific to
|
|
|
|
this release by going into the "``clang/docs/``" directory in the Clang
|
|
|
|
tree.
|
|
|
|
|
|
|
|
If you have any questions or comments about Clang, please feel free to
|
2023-02-15 23:53:38 +02:00
|
|
|
contact us on the `Discourse forums (Clang Frontend category)
|
2022-07-01 14:07:48 -07:00
|
|
|
<https://discourse.llvm.org/c/clang/6>`_.
|