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
============================
2025-01-13 11:24:02 +01:00
2025-01-30 05:32:25 +01:00
- The Objective-C ARC migrator (ARCMigrate) has been removed.
2023-02-15 23:53:38 +02:00
C/C++ Language Potentially Breaking Changes
-------------------------------------------
2023-05-23 14:41:43 -07:00
2023-02-15 23:53:38 +02:00
C++ Specific Potentially Breaking Changes
-----------------------------------------
2024-05-22 18:32:25 +02:00
2025-02-06 15:04:23 +01:00
- The type trait builtin `` __is_referenceable `` has been removed, since it has
very few users and all the type traits that could benefit from it in the
standard library already have their own bespoke builtins.
2023-02-15 23:53:38 +02:00
ABI Changes in This Version
---------------------------
2024-07-04 10:17:32 -07:00
2025-02-04 09:42:12 -08:00
- Return larger CXX records in memory instead of using AVX registers. Code compiled with older clang will be incompatible with newer version of the clang unless -fclang-abi-compat=20 is provided. (#GH120670)
2023-10-26 19:28:28 +01:00
AST Dumping Potentially Breaking Changes
----------------------------------------
2024-01-30 09:30:20 -08:00
Clang Frontend Potentially Breaking Changes
-------------------------------------------
2024-05-14 16:09:57 -04:00
2024-06-14 11:19:28 +02:00
Clang Python Bindings Potentially Breaking Changes
--------------------------------------------------
2022-02-01 23:13:01 -08:00
What's New in Clang |release|?
==============================
2020-02-13 22:46:33 +01:00
2023-02-15 23:53:38 +02:00
C++ Language Changes
--------------------
2024-09-22 09:25:52 +02:00
2023-05-12 07:30:21 -07:00
C++2c Feature Support
^^^^^^^^^^^^^^^^^^^^^
2024-08-23 10:51:25 +11:00
C++23 Feature Support
^^^^^^^^^^^^^^^^^^^^^
2025-01-22 00:28:08 -08:00
2024-08-23 10:51:25 +11:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
Reland: [clang] unified CWG2398 and P0522 changes; finishes implementation of P3310 (#124137)
This patch relands the following PRs:
* #111711
* #107350
* #111457
All of these patches were reverted due to an issue reported in
https://github.com/llvm/llvm-project/pull/111711#issuecomment-2406491485,
due to interdependencies.
---
[clang] Finish implementation of P0522
This finishes the clang implementation of P0522, getting rid
of the fallback to the old, pre-P0522 rules.
Before this patch, when partial ordering template template parameters,
we would perform, in order:
* If the old rules would match, we would accept it. Otherwise, don't
generate diagnostics yet.
* If the new rules would match, just accept it. Otherwise, don't
generate any diagnostics yet again.
* Apply the old rules again, this time with diagnostics.
This situation was far from ideal, as we would sometimes:
* Accept some things we shouldn't.
* Reject some things we shouldn't.
* Only diagnose rejection in terms of the old rules.
With this patch, we apply the P0522 rules throughout.
This needed to extend template argument deduction in order
to accept the historial rule for TTP matching pack parameter to non-pack
arguments.
This change also makes us accept some combinations of historical and P0522
allowances we wouldn't before.
It also fixes a bunch of bugs that were documented in the test suite,
which I am not sure there are issues already created for them.
This causes a lot of changes to the way these failures are diagnosed,
with related test suite churn.
The problem here is that the old rules were very simple and
non-recursive, making it easy to provide customized diagnostics,
and to keep them consistent with each other.
The new rules are a lot more complex and rely on template argument
deduction, substitutions, and they are recursive.
The approach taken here is to mostly rely on existing diagnostics,
and create a new instantiation context that keeps track of this context.
So for example when a substitution failure occurs, we use the error
produced there unmodified, and just attach notes to it explaining
that it occurred in the context of partial ordering this template
argument against that template parameter.
This diverges from the old diagnostics, which would lead with an
error pointing to the template argument, explain the problem
in subsequent notes, and produce a final note pointing to the parameter.
---
[clang] CWG2398: improve overload resolution backwards compat
With this change, we discriminate if the primary template and which partial
specializations would have participated in overload resolution prior to
P0522 changes.
We collect those in an initial set. If this set is not empty, or the
primary template would have matched, we proceed with this set as the
candidates for overload resolution.
Otherwise, we build a new overload set with everything else, and proceed
as usual.
---
[clang] Implement TTP 'reversed' pack matching for deduced function template calls.
Clang previously missed implementing P0522 pack matching
for deduced function template calls.
2025-01-23 20:37:33 -03:00
C++17 Feature Support
^^^^^^^^^^^^^^^^^^^^^
2024-08-23 17:24:08 +02:00
2023-02-15 23:53:38 +02:00
Resolutions to C++ Defect Reports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-06-17 18:31:54 +01:00
2025-01-29 16:57:05 -03:00
- The flag `-frelaxed-template-template-args`
and its negation have been removed, having been deprecated since the previous
two releases. The improvements to template template parameter matching implemented
in the previous release, as described in P3310 and P3579, made this flag unnecessary.
2023-02-15 23:53:38 +02:00
C Language Changes
------------------
2025-01-31 13:50:01 -05:00
- Clang now allows an `` inline `` specifier on a typedef declaration of a
function type in Microsoft compatibility mode. #GH124869
2024-07-02 06:58:41 -04:00
C2y Feature Support
^^^^^^^^^^^^^^^^^^^
2023-08-10 14:18:36 -04:00
C23 Feature Support
2023-02-15 23:53:38 +02:00
^^^^^^^^^^^^^^^^^^^
Handle constant "pointers" for `__atomic_always_lock_free`/`__atomic_is_lock_free`. (#99340)
The second argument passed to these builtins is used to validate whether
the object's alignment is sufficient for atomic operations of the given
size.
Currently, the builtins can be folded at compile time only when the
argument is 0/nullptr, or if the _type_ of the pointer guarantees
appropriate alignment.
This change allows the compiler to also evaluate non-null constant
pointers, which enables callers to check a specified alignment, instead
of only the type or an exact object. E.g.:
`__atomic_is_lock_free(sizeof(T), (void*)4)`
can be potentially evaluated to true at compile time, instead of
generating a libcall. This is also supported by GCC, and used by
libstdc++, and is also useful for libc++'s atomic_ref.
Also helps with (but doesn't fix) issue #75081.
This also fixes a crash bug, when the second argument was a non-pointer
implicitly convertible to a pointer (such as an array, or a function).
2024-07-22 14:20:25 -04:00
2024-08-07 16:39:09 +01:00
Non-comprehensive list of changes in this release
-------------------------------------------------
2020-02-13 22:46:33 +01:00
New Compiler Flags
------------------
2024-07-19 13:03:21 +01:00
2020-02-13 22:46:33 +01:00
Deprecated Compiler Flags
-------------------------
Modified Compiler Flags
-----------------------
2024-07-10 08:32:48 -07:00
2020-12-17 09:23:02 -05:00
Removed Compiler Flags
-------------------------
2020-02-13 22:46:33 +01:00
Attribute Changes in Clang
--------------------------
2024-06-24 00:51:31 -10:00
2025-02-05 08:16:00 -06:00
- The `` no_sanitize `` attribute now accepts both `` gnu `` and `` clang `` names.
2023-02-15 23:53:38 +02:00
Improvements to Clang's diagnostics
-----------------------------------
2024-07-11 14:21:21 +02:00
2025-02-03 18:57:37 +00:00
- Improve the diagnostics for deleted default constructor errors for C++ class
initializer lists that don't explicitly list a class member and thus attempt
to implicitly default construct that member.
Warn when unique objects might be duplicated in shared libraries (#125526)
This is attempt 2 to merge this, the first one is #117622. This properly
disables the tests when building for playstation, since the warning is
disabled there.
When a hidden object is built into multiple shared libraries, each
instance of the library will get its own copy. If
the object was supposed to be globally unique (e.g. a global variable or
static data member), this can cause very subtle bugs.
An object might be incorrectly duplicated if it:
Is defined in a header (so it might appear in multiple TUs), and
Has external linkage (otherwise it's supposed to be duplicated), and
Has hidden visibility (or else the dynamic linker will handle it)
The duplication is only a problem semantically if one of the following
is true:
The object is mutable (the copies won't be in sync), or
Its initialization has side effects (it may now run more than once), or
The value of its address is used (different copies have different
addresses).
To detect this, we add a new -Wunique-object-duplication warning. It
warns on cases (1) and (2) above. To be conservative, we only warn in
case (2) if we are certain the initializer has side effects, and we
don't warn on new because the only side effect is some extra memory
usage.
We don't currently warn on case (3) because doing so is prone to false
positives: there are many reasons for taking the address which aren't
inherently problematic (e.g. passing to a function that expects a
pointer). We only run into problems if the code inspects the value of
the address.
The check is currently disabled for windows, which uses its own analogue
of visibility (declimport/declexport). The check is also disabled inside
templates, since it can give false positives if a template is never
instantiated.
Resolving the warning
The warning can be fixed in several ways:
If the object in question doesn't need to be mutable, it should be made
const. Note that the variable must be completely immutable, e.g. we'll
warn on const int* p because the pointer itself is mutable. To silence
the warning, it should instead be const int* const p.
If the object must be mutable, it (or the enclosing function, in the
case of static local variables) should be made visible using
__attribute((visibility("default")))
If the object is supposed to be duplicated, it should be be given
internal linkage.
Testing
I've tested the warning by running it on clang itself, as well as on
chromium. Compiling clang resulted in [10 warnings across 6
files](https://github.com/user-attachments/files/17908069/clang-warnings.txt),
while Chromium resulted in [160 warnings across 85
files](https://github.com/user-attachments/files/17908072/chromium-warnings.txt),
mostly in third-party code. Almost all warnings were due to mutable
variables.
I evaluated the warnings by manual inspection. I believe all the
resulting warnings are true positives, i.e. they represent
potentially-problematic code where duplication might cause a problem.
For the clang warnings, I also validated them by either adding const or
visibility annotations as appropriate.
Limitations
I am aware of four main limitations with the current warning:
We do not warn when the address of a duplicated object is taken, since
doing so is prone to false positives. I'm hopeful that we can create a
refined version in the future, however.
We only warn for side-effectful initialization if we are certain side
effects exist. Warning on potential side effects produced a huge number
of false positives; I don't expect there's much that can be done about
this in modern C++ code bases, since proving a lack of side effects is
difficult.
Windows uses a different system (declexport/import) instead of
visibility. From manual testing, it seems to behave analogously to the
visibility system for the purposes of this warning, but to keep things
simple the warning is disabled on windows for now.
We don't warn on code inside templates. This is unfortuate, since it
masks many real issues, e.g. a templated variable which is implicitly
instantiated the same way in multiple TUs should be globally unique, but
may accidentally be duplicated. Unfortunately, we found some potential
false positives during testing that caused us to disable the warning for
now.
2025-02-03 15:20:47 -05:00
- The `` -Wunique-object-duplication `` warning has been added to warn about objects
which are supposed to only exist once per program, but may get duplicated when
built into a shared library.
2025-02-07 02:01:39 -05:00
- Fixed a bug where Clang's Analysis did not correctly model the destructor behavior of `` union `` members (#GH119415).
2025-02-03 18:57:37 +00:00
2023-09-01 15:30:44 +01:00
Improvements to Clang's time-trace
----------------------------------
2024-06-19 07:15:19 +09:00
Improvements to Coverage Mapping
--------------------------------
2023-02-15 23:53:38 +02:00
Bug Fixes in This Version
-------------------------
2024-07-19 11:00:30 +02:00
2023-02-15 23:53:38 +02:00
Bug Fixes to Compiler Builtins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2022-05-02 17:06:04 -04:00
2025-01-30 20:34:29 +01:00
- The behvaiour of `` __add_pointer `` and `` __remove_pointer `` for Objective-C++'s `` id `` and interfaces has been fixed.
2023-02-15 23:53:38 +02:00
Bug Fixes to Attribute Support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2025-02-04 12:58:44 +01:00
- Fixed crash when a parameter to the `` clang::annotate `` attribute evaluates to `` void `` . See #GH119125
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
2025-02-05 14:12:12 -03:00
- Clang is now better at keeping track of friend function template instance contexts. (#GH55509)
2023-02-15 23:53:38 +02:00
Bug Fixes to AST Handling
^^^^^^^^^^^^^^^^^^^^^^^^^
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
2025-02-05 14:46:14 +01:00
- HTML tags in comments that span multiple lines are now parsed correctly by Clang's comment parser. (#GH120843)
2023-02-15 23:53:38 +02:00
Miscellaneous Clang Crashes Fixed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2022-05-03 14:13:56 -04: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
^^^^^^^^^^^^^^
2024-11-15 11:08:06 -06:00
NVPTX Support
^^^^^^^^^^^^^^
2025-02-03 16:43:27 -06:00
Hexagon Support
^^^^^^^^^^^^^^^
- The default compilation target has been changed from V60 to V68.
2023-02-15 23:53:38 +02:00
X86 Support
^^^^^^^^^^^
2020-02-13 22:46:33 +01:00
2025-01-30 21:13:49 +08:00
- Disable `` -m[no-]avx10.1 `` and switch `` -m[no-]avx10.2 `` to alias of 512 bit
options.
- Change `` -mno-avx10.1-512 `` to alias of `` -mno-avx10.1-256 `` to disable both
256 and 512 bit instructions.
2023-02-15 23:53:38 +02:00
Arm and AArch64 Support
^^^^^^^^^^^^^^^^^^^^^^^
2020-02-13 22:46:33 +01: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
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
2023-02-15 23:53:38 +02:00
CUDA/HIP Language Changes
^^^^^^^^^^^^^^^^^^^^^^^^^
2022-10-18 10:50:37 -07:00
2023-02-15 23:53:38 +02:00
CUDA Support
^^^^^^^^^^^^
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-07-22 19:31:01 -04:00
NetBSD Support
^^^^^^^^^^^^^^
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
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
----------------------------
2020-02-13 22:46:33 +01:00
AST Matchers
------------
clang-format
------------
2025-02-06 01:15:47 -08:00
- Adds `` BreakBeforeTemplateCloser `` option.
2025-02-07 23:10:35 -07:00
- Adds `` BinPackLongBracedList `` option to override bin packing options in
long (20 item or more) braced list initializer lists.
2025-02-06 01:15:47 -08:00
2020-02-13 22:46:33 +01:00
libclang
--------
2025-01-23 01:43:44 -05:00
Code Completion
---------------
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
^^^^^^^^^^^^
2025-02-05 15:15:36 -08:00
A new flag - `-static-libclosure`
the runtime for the Blocks extension on Windows. This flag currently only
changes the code generation, and even then, only on Windows. This does not
impact the linker behaviour like the other `-static-*`
2024-07-10 16:53:12 +02:00
Crash and bug fixes
^^^^^^^^^^^^^^^^^^^
2023-12-28 15:48:59 +01:00
Improvements
^^^^^^^^^^^^
Moved checkers
^^^^^^^^^^^^^^
2025-02-06 17:45:42 +01:00
- After lots of improvements, the checker `` alpha.security.ArrayBoundV2 `` is
renamed to `` security.ArrayBound `` . As this checker is stable now, the old
checker `` alpha.security.ArrayBound `` (which was searching for the same kind
of bugs with an different, simpler and less accurate algorithm) is removed.
2022-09-26 17:41:37 -07:00
.. _release-notes-sanitizers:
Sanitizers
----------
2025-01-09 09:23:23 +01:00
2023-04-04 09:21:04 -04:00
Python Binding Changes
----------------------
2020-02-13 22:46:33 +01:00
2024-03-12 13:42:43 +01:00
OpenMP Support
--------------
2025-02-06 12:41:10 -08:00
- Added support 'no_openmp_constructs' assumption clause.
2024-03-12 13:42:43 +01:00
2024-08-02 17:22:40 -07:00
Improvements
^^^^^^^^^^^^
2024-08-06 10:55:15 -04:00
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> `_.
