mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 13:16:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/docs/ReleaseNotes.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

311 lines
8.7 KiB
ReStructuredText
Raw Normal View History

[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
===========================================
Clang |release| |ReleaseNotesTitle|
===========================================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
.. contents::
:local:
:depth: 2
Written by the `LLVM Team <https://llvm.org/>`_
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
.. only:: PreRelease
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
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
Fix broken link on Clang documentation page While browsing the latest [clang manual](https://clang.llvm.org/docs/ReleaseNotes.html), I came across this warning and clicked, but it leads to a broken page, apparently because it's missing the trailing `/`. Seems to be the only place where it's missing in the whole of LLVM monorepo. {F26690053} {F26690057} Reviewed By: brenoguim, royjacobson Differential Revision: https://reviews.llvm.org/D145047
2023-03-05 00:56:15 +02:00
`the Releases Page <https://llvm.org/releases/>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Introduction
============
This document contains the release notes for the Clang C/C++/Objective-C
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
frontend, part of the LLVM Compiler Infrastructure, release |release|. Here we
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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/>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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>`_.
Add a "Potentially Breaking Changes" section to the Clang release notes Sometimes we make changes to the compiler that we expect may cause disruption for users. For example, we may strengthen a warning to default to be an error, or fix an accepts-invalid bug that's been around for a long time, etc which may cause previously accepted code to now be rejected. Rather than hope users discover that information by reading all of the release notes, it's better that we call these out in one location at the top of the release notes. Based on feedback collected in the discussion at: https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/ Differential Revision: https://reviews.llvm.org/D133771
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.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C/C++ Language Potentially Breaking Changes
-------------------------------------------
Reland: [clang][ExprConstant] fix __builtin_object_size for flexible array members As reported by @kees, GCC treats __builtin_object_size of structures containing flexible array members (aka arrays with incomplete type) not just as the sizeof the underlying type, but additionally the size of the members in a designated initializer list. Fixes: https://github.com/llvm/llvm-project/issues/62789 Reviewed By: erichkeane, efriedma Differential Revision: https://reviews.llvm.org/D150892
2023-05-23 14:41:43 -07:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++ Specific Potentially Breaking Changes
-----------------------------------------
[Clang] [NFC] Add release note about libstdc++ bug (#93059) Adding a release note about this as discussed in #92439. --------- Co-authored-by: cor3ntin <corentinjabot@gmail.com>
2024-05-22 18:32:25 +02:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
ABI Changes in This Version
---------------------------
Fix MSVC 1920+ auto NTTP mangling for pointers to members (#97007) Fixes https://github.com/llvm/llvm-project/issues/70899. This is a continuation of https://github.com/llvm/llvm-project/pull/92477 for pointers to member data and pointers to member functions. The mangled name must be prefixed with `$M <mangled-type>` for the deduced type of the nttp parameter.
2024-07-04 10:17:32 -07:00
[AST] Only dump desugared type when visibly different (#65214) These are an artifact of how types are structured but serve little purpose, merely showing that the type is sugared in some way. For example, ElaboratedType's existence means struct S gets printed as 'struct S':'struct S' in the AST, which is unnecessary visual clutter. Note that skipping the second print when the types have the same string matches what we do for diagnostics, where the aka will be skipped.
2023-10-26 19:28:28 +01:00
AST Dumping Potentially Breaking Changes
----------------------------------------
[Docs] Add release note about Clang-defined target OS macros (#79879)
2024-01-30 09:30:20 -08:00
Clang Frontend Potentially Breaking Changes
-------------------------------------------
Reapply "[Clang] Unify interface for accessing template arguments as written for class/variable template specializations (#81642)" (#91393) Reapplies #81642, fixing the crash which occurs when running the lldb test suite.
2024-05-14 16:09:57 -04:00
[libclang/python] Fix bugs in custom enum implementation and add tests (#95381) Do not allow initialization of enum from negative IDs (e.g. from_id(-1) currently produces the last known variant) Rename duplicate enums: CursorKind.OMP_TEAMS_DISTRIBUTE_DIRECTIVE and TypeKind.OBJCCLASS Add tests to cover these cases
2024-06-14 11:19:28 +02:00
Clang Python Bindings Potentially Breaking Changes
--------------------------------------------------
[docs] Remove hard-coded version numbers from sphinx configs This updates all the non-runtime project release notes to use the version number from CMake instead of the hard-coded version numbers in conf.py. It also hides warnings about pre-releases when the git suffix is dropped from the LLVM version in CMake. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D112181
2022-02-01 23:13:01 -08:00
What's New in Clang |release|?
==============================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++ Language Changes
--------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (#89446) These macros are used by STL implementations to support implementation of std::hardware_destructive_interference_size and std::hardware_constructive_interference_size Fixes #60174 --------- Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2024-04-26 12:05:15 -04:00
C++17 Feature Support
^^^^^^^^^^^^^^^^^^^^^
Reland "[clang] Enable sized deallocation by default in C++14 onwards" (#90373) Since C++14 has been released for about nine years and most standard libraries have implemented sized deallocation functions, it's time to make this feature default again. This is another try of https://reviews.llvm.org/D112921. The original commit cf5a8b4 was reverted by 2e5035a due to some failures (see #83774). Fixes #60061
2024-05-22 12:37:27 +08:00
C++14 Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Clang] Fix Unevaluated Lambdas Unlike other types, when lambdas are instanciated, they are recreated from scratch. When an unevaluated lambdas appear in the type of a function, parameter it is instanciated in the wrong declaration context, as parameters are transformed before the function. To support lambda in function parameters, we try to compute whether they are dependant without looking at the declaration context. This is a short term stopgap solution to avoid clang iceing. A better fix might be to inject some kind of transparent declaration with correctly computed dependency for function parameters, variable templates, etc. Fixes https://github.com/llvm/llvm-project/issues/50376 Fixes https://github.com/llvm/llvm-project/issues/51414 Fixes https://github.com/llvm/llvm-project/issues/51416 Fixes https://github.com/llvm/llvm-project/issues/51641 Fixes https://github.com/llvm/llvm-project/issues/54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532
2022-03-12 20:49:01 +01:00
[clang] Use -std=c++23 instead of -std=c++2b During the ISO C++ Committee meeting plenary session the C++23 Standard has been voted as technical complete. This updates the reference to c++2b to c++23 and updates the __cplusplus macro. Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D149553
2023-04-30 15:27:00 +02:00
C++23 Feature Support
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
^^^^^^^^^^^^^^^^^^^^^
[clang][ExprConst] Allow non-literal types in C++23 (#100062) Instead of diagnosing non-literal types in C++23, allow them and later diagnose them differently, e.g. because they have a non-constexpr constructor, destructor, etc. For this test: ```c++ struct NonLiteral { NonLiteral() {} }; constexpr int foo() { NonLiteral L; return 1; } // static_assert(foo() == 1); ``` The current diagnostics with c++20/c++23 are: ```console ~/code/llvm-project/build » clang -c array.cpp -std=c++20 array.cpp:91:14: error: variable of non-literal type 'NonLiteral' cannot be defined in a constexpr function before C++23 91 | NonLiteral L; | ^ array.cpp:87:8: note: 'NonLiteral' is not literal because it is not an aggregate and has no constexpr constructors other than copy or move constructors 87 | struct NonLiteral { | ^ 1 error generated. ------------------------------------------------------------ ~/code/llvm-project/build » clang -c array.cpp -std=c++23 (no output) ``` With the `static_assert` enabled, compiling with `-std=c++23` prints: ```console array.cpp:95:15: error: static assertion expression is not an integral constant expression 95 | static_assert(foo() == 1); | ^~~~~~~~~~ array.cpp:91:14: note: non-literal type 'NonLiteral' cannot be used in a constant expression 91 | NonLiteral L; | ^ array.cpp:95:15: note: in call to 'foo()' 95 | static_assert(foo() == 1); | ^~~~~ 1 error generated. ``` As mentioned in #60311, this is confusing. The output with c++20 suggests that using c++23 will make the problem go away, but it's diagnosed the same when running the function. With this commit, the output instead diagnoses _why_ the non-literal type can't be used: ```console array.cpp:95:15: error: static assertion expression is not an integral constant expression 95 | static_assert(foo() == 1); | ^~~~~~~~~~ array.cpp:91:14: note: non-constexpr constructor 'NonLiteral' cannot be used in a constant expression 91 | NonLiteral L; | ^ array.cpp:95:15: note: in call to 'foo()' 95 | static_assert(foo() == 1); | ^~~~~ array.cpp:88:3: note: declared here 88 | NonLiteral() {} | ^ 1 error generated. ``` Fixes #60311
2024-07-24 08:09:06 +02:00
- Removed the restriction to literal types in constexpr functions in C++23 mode.
[clang] Add separate C++23 extension flag for attrs on lambda (#74553)
2023-12-07 14:52:10 +01:00
Add C++26 compile flags. Now that we've updated to C++23, we need to add C++26/C++2c command line flags, as discussed in https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383 Differential Revision: https://reviews.llvm.org/D150450
2023-05-12 07:30:21 -07:00
C++2c Feature Support
^^^^^^^^^^^^^^^^^^^^^
[clang] Implement `__builtin_is_virtual_base_of()` intrinsic (#100393) This patch adds compiler support for [P2985R0](https://wg21.link/p2985r0) "A type trait for detecting virtual base classes". Like we recently did with `__is_layout_compatible()` and `__is_pointer_interconvertible_base_of()`, we support it only in C++ mode, and reject VLAs. Resolves #98310.
2024-07-26 11:09:54 +04:00
- Add ``__builtin_is_virtual_base_of`` intrinsic, which supports
`P2985R0 A type trait for detecting virtual base classes <https://wg21.link/p2985r0>`_
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Resolutions to C++ Defect Reports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Clang] Introduce `CXXTypeidExpr::hasNullCheck` (#95718) Used to implement CWG2191 where `typeid` for a polymorphic glvalue only becomes potentially-throwing if the `typeid` operand was already potentially throwing or a `nullptr` check was inserted: https://cplusplus.github.io/CWG/issues/2191.html Also change `Expr::hasSideEffects` for `CXXTypeidExpr` to check the operand for side-effects instead of always reporting that there are side-effects Remove `IsDeref` parameter of `CGCXXABI::shouldTypeidBeNullChecked` because it should never return `true` if `!IsDeref` (we shouldn't add a null check that wasn't there in the first place)
2024-06-17 18:31:54 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
C Language Changes
------------------
[C2y] Add -std=c2y and -std=gnu2y This adds a language standard mode for the latest C standard. While WG14 is hoping for a three-year cycle, it is not clear that the next revision of C will be in 2026 and so a flag was not created for c26 specifically.
2024-07-02 06:58:41 -04:00
C2y Feature Support
^^^^^^^^^^^^^^^^^^^
[C23] Update user-facing docs for C23 This changes some public references of C2x to be C23, corrects standard citations to use the final paragraph numbers, and adds some information about differences between C17 and C23 modes.
2023-08-10 14:18:36 -04:00
C23 Feature Support
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
New Compiler Flags
------------------
Recommit "[TBAA] Emit distinct TBAA tags for pointers with different depths,types. (#76612)" This reverts the revert commit bee240367cc48bbc93fe5eb57d537968dfe4419f. This version includes updates to the tests to use patterns when matching the pointer argument. Original commit message: This patch extends Clang's TBAA generation code to emit distinct tags for incompatible pointer types. Pointers with different element types are incompatible if the pointee types are also incompatible (modulo sugar/modifiers). Express this in TBAA by generating different tags for pointers based on the pointer depth and pointee type. To get the TBAA tag for the pointee type it uses getTypeInfoHelper on the pointee type. (Moved from https://reviews.llvm.org/D122573) PR: https://github.com/llvm/llvm-project/pull/76612
2024-07-19 13:03:21 +01:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Deprecated Compiler Flags
-------------------------
Modified Compiler Flags
-----------------------
[clang][ARM] Fix warning for using VFP from interrupts. (#91870) [clang][ARM] Fix warning for using VFP from interrupts. This warning has three issues: - The interrupt attribute causes the function to return using an exception return instruction. This warning allows calls from one function with the interrupt attribute to another, and the diagnostic text suggests that not having the attribute on the callee is a problem. Actually making such a call will lead to a double exception return, which is unpredictable according to the ARM architecture manual section B9.1.1, "Restrictions on exception return instructions". Even on machines where an exception return from user/system mode is tolerated, if the callee's interrupt type is anything other than a supervisor call or secure monitor call, it will also return to a different address than a normal function would. For example, returning from an "IRQ" handler will return to lr - 4, which will generally result in calling the same function again. - The interrupt attribute currently does not cause caller-saved VFP registers to be saved and restored if they are used, so putting __attribute__((interrupt)) on a called function doesn't prevent it from clobbering VFP state. - It is part of the -Wextra diagnostic group and can't be individually disabled when using -Wextra, which also means the diagnostic text of this specific warning appears in the documentation of -Wextra. This change addresses all three issues by instead generating a warning for any interrupt handler where the vfp feature is enabled. The warning is also given its own diagnostic group. Closes #34876. [clang][ARM] Emit an error when an interrupt handler is called. Closes #95359.
2024-07-10 08:32:48 -07:00
clang-cl: Remove /Zd flag cl.exe doesn't understand Zd (in either MSVC 2017 or 2019), so neiter should we. It used to do the same as `-gline-tables-only` which is exposed as clang-cl flag as well, so if you want this behavior, use `gline-tables-only`. That makes it clear that it's a clang-cl-only flag that won't work with cl.exe. Motivated by the discussion in D92958. Differential Revision: https://reviews.llvm.org/D93458
2020-12-17 09:23:02 -05:00
Removed Compiler Flags
-------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Attribute Changes in Clang
--------------------------
[Clang] Introduce `nonblocking`/`nonallocating` attributes (#84983) Introduce `nonblocking` and `nonallocating` attributes. RFC is here: https://discourse.llvm.org/t/rfc-nolock-and-noalloc-attributes/76837 This PR introduces the attributes, with some changes in Sema to deal with them as extensions to function (proto)types. There are some basic type checks, most importantly, a warning when trying to spoof the attribute (implicitly convert a function without the attribute to one that has it). A second, follow-on pull request will introduce new caller/callee verification. --------- Co-authored-by: Doug Wyatt <dwyatt@apple.com> Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com> Co-authored-by: Aaron Ballman <aaron@aaronballman.com> Co-authored-by: Sirraide <aeternalmail@gmail.com>
2024-06-24 00:51:31 -10:00
[clang][analyzer] Support `ownership_{returns,takes}` attributes (#98941) Add support for checking mismatched ownership_returns/ownership_takes attributes. Closes #76861
2024-07-24 14:15:08 +03:00
- Clang now disallows more than one ``__attribute__((ownership_returns(class, idx)))`` with
different class names attached to one function.
[clang][Sema] Add support for OpenBSD's syslog format attribute (#97366)
2024-07-25 18:57:14 -04:00
- Introduced a new format attribute ``__attribute__((format(syslog, 1, 2)))`` from OpenBSD.
[clang][ARM64EC] Add support for hybrid_patchable attribute. (#99478)
2024-07-27 14:29:05 +02:00
- The ``hybrid_patchable`` attribute is now supported on ARM64EC targets. It can be used to specify
that a function requires an additional x86-64 thunk, which may be patched at runtime.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Improvements to Clang's diagnostics
-----------------------------------
[clang] Emit bad shift warnings (#70307) Diagnose bad shifts and emit warnings
2024-07-11 14:21:21 +02:00
Template Diagnostic Improvements (#99933) It turns out `SemaTemplate` handles this type of diagnostic already, however when template gets encountered, it never gets parsed as a possible statement or declaration, only as an expression. Fixes #17959.
2024-07-23 07:31:49 -04:00
- Some template related diagnostics have been improved.
.. code-block:: c++
void foo() { template <typename> int i; } // error: templates can only be declared in namespace or class scope
struct S {
template <typename> int i; // error: non-static data member 'i' cannot be declared as a template
};
[Clang] Fix confusing diagnositcs related to explicit this parameters (#100351) Fixes #97878. This PR improves diagnostics related to explicit 'this' parameters. Previously, the 'this' parameter would be incorrectly underlined when diagnosing a bad conversion.
2024-07-29 09:40:35 -04:00
- Clang now has improved diagnostics for functions with explicit 'this' parameters. Fixes #GH97878
Fix lifetimebound for field access (#100197) Fixes: https://github.com/llvm/llvm-project/issues/81589 There is no way to switch this off without `-Wno-dangling`.
2024-07-24 15:58:52 +02:00
- Clang now diagnoses dangling references to fields of temporary objects. Fixes #GH81589.
[ExprConstant] Handle shift overflow the same way as other kinds of overflow (#99579) We have a mechanism to allow folding expressions that aren't ICEs as an extension; use it more consistently. This ends up causing bad effects on diagnostics in a few cases, but that's not specific to shifts; it's a general issue with the way those uses handle overflow diagnostics.
2024-07-24 12:36:08 -07:00
- Clang now diagnoses undefined behavior in constant expressions more consistently. This includes invalid shifts, and signed overflow in arithmetic.
[clang] Enable the -Wdangling-assignment-gsl diagnostic by default. (#100708)
2024-07-26 19:28:37 +02:00
- -Wdangling-assignment-gsl is enabled by default.
Add two time-trace scope variables. A time trace scope variable of `ParseDeclarationOrFunctionDefinition` with the function's source location is added to record the time spent parsing the function's declaration or definition. Another time trace scope variable of `ParseFunctionDefinition` is also added to record the name of the defined function. A release note is added as well. Reviewed by: Aaron Ballman Pull request: #65268
2023-09-01 15:30:44 +01:00
Improvements to Clang's time-trace
----------------------------------
Update ReleaseNotes for MC/DC changes. (#95887) Mostly apparent changes (#82448, #95496) are described here.
2024-06-19 07:15:19 +09:00
Improvements to Coverage Mapping
--------------------------------
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes in This Version
-------------------------
[Sema] Fix assertion error in Sema::FindInstantiatedDecl (#96509) ...when looking for a template instantiation with a non-type parameter of unknown type and with a default value. This can happen when a template non-type parameter has a broken expression that gets replaced by a `RecoveryExpr`.
2024-07-19 11:00:30 +02:00
[clang] Define `ATOMIC_FLAG_INIT` correctly for C++. (#97534)
2024-07-24 05:53:39 -07:00
- Fixed the definition of ``ATOMIC_FLAG_INIT`` in ``<stdatomic.h>`` so it can
be used in C++.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to Compiler Builtins
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[clang][AIX] Don't ignore XCOFF visibility by default D87451 added -mignore-xcoff-visibility for AIX targets and made it the default (which mimicked the behaviour of the XL 16.1 compiler on AIX). However, ignoring hidden visibility has unwanted side effects and some libraries depend on visibility to hide non-ABI facing entities from user headers and reserve the right to change these implementation details based on this (https://libcxx.llvm.org/DesignDocs/VisibilityMacros.html). This forces us to use internal linkage fallbacks for these cases on AIX and creates an unwanted divergence in implementations on the plaform. For these reasons, it's preferable to not add -mignore-xcoff-visibility by default, which is what this patch does. Reviewed By: DiggerLin Differential Revision: https://reviews.llvm.org/D125141
2022-05-02 17:06:04 -04:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to Attribute Support
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[clang][Sema] check default argument promotions for printf The main focus of this patch is to make ArgType::matchesType check for possible default parameter promotions when the argType is not a pointer. If so, no warning will be given for `int`, `unsigned int` types as corresponding arguments to %hhd and %hd. However, the usage of %hhd corresponding to short is relatively rare, and it is more likely to be a misuse. This patch keeps the original behavior of clang like this as much as possible, while making it more convenient to consider the default arguments promotion. Fixes https://github.com/llvm/llvm-project/issues/57102 Reviewed By: aaron.ballman, nickdesaulniers, #clang-language-wg Differential Revision: https://reviews.llvm.org/D132568
2022-08-26 19:26:32 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to C++ Support
^^^^^^^^^^^^^^^^^^^^^^^^
Diagnose extensions in 'offsetof' https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm made very clear that it is an UB having type definitions with in offsetof. Clang supports defining a type as the first argument as a conforming extension due to how many projects use the construct in C99 and earlier to calculate the alignment of a type. GCC also supports defining a type as the first argument. This adds extension warnings and documentation for the functionality Clang explicitly supports. Fixes #57065 Reverts the revert of 39da55e8f548a11f7dadefa73ea73d809a5f1729 Co-authored-by: Yingchi Long <i@lyc.dev> Co-authored-by: Aaron Ballman <aaron@aaronballman.com> Differential Revision: https://reviews.llvm.org/D133574
2023-01-18 08:49:45 -05:00
[Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (#98563) Fixes #97646.
2024-07-24 12:02:45 -04:00
- Fixed a crash when an expression with a dependent ``__typeof__`` type is used as the operand of a unary operator. (#GH97646)
[Clang] fix assertion failure in invalid delete operator declaration check (#99308) Fixes #96191
2024-07-25 15:08:18 +03:00
- Fixed a failed assertion when checking invalid delete operator declaration. (#GH96191)
[Clang] prevent checking destructor reference with an invalid initializer (#97860) Fixes #97230
2024-07-29 19:39:30 +03:00
- Fix a crash when checking destructor reference with an invalid initializer. (#GH97230)
[Clang][Parse] Fix ambiguity with nested-name-specifiers that may declarative (#96364) Consider the following: ``` template<typename T> struct A { }; template<typename T> int A<T>::B::* f(); // error: no member named 'B' in 'A<T>' ``` Although this is clearly valid, clang rejects it because the _nested-name-specifier_ `A<T>::` is parsed as-if it was declarative, meaning, we parse it as-if it was the _nested-name-specifier_ in a redeclaration/specialization. However, we don't (and can't) know whether the _nested-name-specifier_ is declarative until we see the '`*`' token, but at that point we have already complained that `A` has no member named `B`! This patch addresses this bug by adding support for _fully_ unannotated _and_ unbounded tentative parsing, which allows for us to parse past tokens without having to cache them until we reach a point where we can guarantee to be past the construct we are disambiguating. I don't know where the approach taken here is ideal -- alternatives are welcome. However, the performance impact (as measured by llvm-compile-time-tracker (https://llvm-compile-time-tracker.com/?config=Overview&stat=instructions%3Au&remote=sdkrystian) is quite minimal (0.09%, which I plan to further improve).
2024-07-29 14:01:00 -04:00
- Clang now correctly parses potentially declarative nested-name-specifiers in pointer-to-member declarators.
[Clang][AST] Don't use canonical type when checking dependence in Type::isOverloadable (#98563) Fixes #97646.
2024-07-24 12:02:45 -04:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Bug Fixes to AST Handling
^^^^^^^^^^^^^^^^^^^^^^^^^
Forbid implicit conversion of constraint expression to bool As reported in https://github.com/llvm/llvm-project/issues/54524, and later in https://github.com/llvm/llvm-project/issues/60038, we were not properly implmenting temp.constr.atomic P3. This patch stops implicitly converting constraints to bool, and ensures the Rvalue conversion takes place as needed. Differential Revision: https://reviews.llvm.org/D141954
2023-01-17 11:29:04 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Miscellaneous Bug Fixes
^^^^^^^^^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Miscellaneous Clang Crashes Fixed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[CUDA][HIP] support __noinline__ as keyword CUDA/HIP programs use __noinline__ like a keyword e.g. __noinline__ void foo() {} since __noinline__ is defined as a macro __attribute__((noinline)) in CUDA/HIP runtime header files. However, gcc and clang supports __attribute__((__noinline__)) the same as __attribute__((noinline)). Some C++ libraries use __attribute__((__noinline__)) in their header files. When CUDA/HIP programs include such header files, clang will emit error about invalid attributes. This patch fixes this issue by supporting __noinline__ as a keyword, so that CUDA/HIP runtime could remove the macro definition. Reviewed by: Aaron Ballman, Artem Belevich Differential Revision: https://reviews.llvm.org/D124866
2022-05-03 14:13:56 -04:00
[Clang] Remove `IDNS_Ordinary` flag in `IndirectFieldDecl::IdentifierNamespace` (#100525) There is a `IDNS_Ordinary` flag in `IndirectFieldDecl::IdentifierNamespace` so that members in nested anonymous struct/union can be found as ordinary identifiers. ```c struct S { struct { int x; }; // Previous behaviour: `x` in previous line is found // Expected: nothing is found int arr[sizeof(x)]; }; ``` This PR fixes this issue. Fixes #31295.
2024-07-26 20:39:46 +08:00
- Fixed a crash in C due to incorrect lookup that members in nested anonymous struct/union
can be found as ordinary identifiers in struct/union definition. (#GH31295)
[OpenACC] Initial commits to support OpenACC (#70234) Initial commits to support OpenACC. This patchset: adds a clang-command line argument '-fopenacc', and starts to define _OPENACC, albeit to '1' instead of the standardized value (since we don't properly implement OpenACC yet). The OpenACC spec defines `_OPENACC` to be equal to the latest standard implemented. However, since we're not done implementing any standard, we've defined this by default to be `1`. As it is useful to run our compiler against existing OpenACC workloads, we're providing a temporary override flag to change the `_OPENACC` value to be any entirely digit value, permitting testing against any existing OpenACC project. Exactly like the OpenMP parser, the OpenACC pragma parser needs to consume and reprocess the tokens. This patch sets up the infrastructure to do so by refactoring the OpenMP version of this into a more general version that works for OpenACC as well. Additionally, this adds a few diagnostics and token kinds to get us started.
2023-11-17 06:29:02 -08:00
OpenACC Specific Changes
------------------------
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Target Specific Changes
-----------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang] Always use --no-undefined when linking AMDGPU images AMDGPU uses ELF shared libraries to implement their executable device images. One downside to this method is that it disables regular warnings on undefined symbols. This is because shared libraries expect these to be resolves by later loads. However, the GPU images do not support dynamic linking so any undefined symbol is going to cause a runtime error. This patch adds `--no-undefined` to the `ld.lld` invocation to guarantee that undefined symbols are always caught as linking errors rather than runtime errors. Reviewed By: arsenm, MaskRay, #amdgpu Differential Revision: https://reviews.llvm.org/D145941
2023-03-13 09:33:08 -05:00
AMDGPU Support
^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
X86 Support
^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (#96540) The MMX instruction set is legacy, and the SSE2 variants are in every way superior, when they are available -- and they have been available since the Pentium 4 was released, 20 years ago. Therefore, we are switching the "MMX" intrinsics to depend on SSE2, unconditionally. This change entirely drops the ability to generate vectorized code using compiler intrinsics for chips with MMX but without SSE2: the Intel Pentium MMX, Pentium, II, and Pentium III (released 1997-1999), as well as AMD K6 and K7 series chips of around the same timeframe. Targeting these older CPUs remains supported -- simply without the ability to use MMX compiler intrinsics. Migrating away from the use of MMX registers also fixes a rather non-obvious requirement. The long-standing programming model for these MMX intrinsics requires that the programmer be aware of the x87/MMX mode-switching semantics, and manually call `_mm_empty()` between using any MMX instruction and any x87 FPU instruction. If you neglect to, then every future x87 operation will return a NaN result. This requirement is not at all obvious to users of these these intrinsic functions, and causes very difficult to detect bugs. Worse, even if the user did write code that correctly calls `_mm_empty()` in the right places, LLVM may sometimes reorder x87 and mmx operations around each-other, unaware of this mode switching issue. Eliminating the use of MMX registers eliminates this problem. This change also deletes the now-unnecessary MMX `__builtin_ia32_*` functions from Clang. Only 3 MMX-related builtins remain in use -- `__builtin_ia32_emms`, used by `_mm_empty`, and `__builtin_ia32_vec_{ext,set}_v4si`, used by `_mm_insert_pi16` and `_mm_extract_pi16`. Note particularly that the latter two lower to generic, non-MMX, IR. Support for the LLVM intrinsics underlying these removed builtins still remains, for the moment. The file `clang/www/builtins.py` has been updated with mappings from the newly-removed `__builtin_ia32` functions to the still-supported equivalents in `mmintrin.h`. (Originally uploaded at https://reviews.llvm.org/D86855 and https://reviews.llvm.org/D94252) Fixes issue #41665 Works towards #98272
2024-07-24 17:00:12 -04:00
- The MMX vector intrinsic functions from ``*mmintrin.h`` which
operate on `__m64` vectors, such as ``_mm_add_pi8``, have been
reimplemented to use the SSE2 instruction-set and XMM registers
unconditionally. These intrinsics are therefore *no longer
supported* if MMX is enabled without SSE2 -- either from targeting
CPUs from the Pentium-MMX through the Pentium 3, or explicitly via
Clang: adjust MMX instrinsics release note.
2024-07-24 18:39:16 -04:00
passing arguments such as ``-mmmx -mno-sse2``. MMX assembly code
remains supported without requiring SSE2, including inside
inline-assembly.
Clang: convert `__m64` intrinsics to unconditionally use SSE2 instead of MMX. (#96540) The MMX instruction set is legacy, and the SSE2 variants are in every way superior, when they are available -- and they have been available since the Pentium 4 was released, 20 years ago. Therefore, we are switching the "MMX" intrinsics to depend on SSE2, unconditionally. This change entirely drops the ability to generate vectorized code using compiler intrinsics for chips with MMX but without SSE2: the Intel Pentium MMX, Pentium, II, and Pentium III (released 1997-1999), as well as AMD K6 and K7 series chips of around the same timeframe. Targeting these older CPUs remains supported -- simply without the ability to use MMX compiler intrinsics. Migrating away from the use of MMX registers also fixes a rather non-obvious requirement. The long-standing programming model for these MMX intrinsics requires that the programmer be aware of the x87/MMX mode-switching semantics, and manually call `_mm_empty()` between using any MMX instruction and any x87 FPU instruction. If you neglect to, then every future x87 operation will return a NaN result. This requirement is not at all obvious to users of these these intrinsic functions, and causes very difficult to detect bugs. Worse, even if the user did write code that correctly calls `_mm_empty()` in the right places, LLVM may sometimes reorder x87 and mmx operations around each-other, unaware of this mode switching issue. Eliminating the use of MMX registers eliminates this problem. This change also deletes the now-unnecessary MMX `__builtin_ia32_*` functions from Clang. Only 3 MMX-related builtins remain in use -- `__builtin_ia32_emms`, used by `_mm_empty`, and `__builtin_ia32_vec_{ext,set}_v4si`, used by `_mm_insert_pi16` and `_mm_extract_pi16`. Note particularly that the latter two lower to generic, non-MMX, IR. Support for the LLVM intrinsics underlying these removed builtins still remains, for the moment. The file `clang/www/builtins.py` has been updated with mappings from the newly-removed `__builtin_ia32` functions to the still-supported equivalents in `mmintrin.h`. (Originally uploaded at https://reviews.llvm.org/D86855 and https://reviews.llvm.org/D94252) Fixes issue #41665 Works towards #98272
2024-07-24 17:00:12 -04:00
- The compiler builtins such as ``__builtin_ia32_paddb`` which
formerly implemented the above MMX intrinsic functions have been
removed. Any uses of these removed functions should migrate to the
functions defined by the ``*mmintrin.h`` headers. A mapping can be
found in the file ``clang/www/builtins.py``.
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
Arm and AArch64 Support
^^^^^^^^^^^^^^^^^^^^^^^
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[driver] Search for compatible Android runtime directories Android triples include a version number, which makes direct triple comparisons for per-target runtime directory searching not always work. Instead, look for the triple with the highest compatible version number and use that per-target runtime directory instead. This maintains the existing fallback to a triple without any version number, but I'm hoping we can remove that in the future. https://discourse.llvm.org/t/62717 discusses this further. The one remaining triple mismatch after this is that Android armv7 triples usually have an environment of `androideabi`, which Clang normalizes to `android`. If you use the `androideabi` triple when building the runtimes with a per-target runtimes dir, the directory will get created with `androideabi` in its name, but Clang's triple search uses the normalized triple and will look for an `android` directory instead. https://reviews.llvm.org/D140925 will fix that by normalizing triples when creating the per-target runtimes directories as well. Reviewed By: phosek, pirama Differential Revision: https://reviews.llvm.org/D158476
2023-08-31 18:04:56 -07:00
Android Support
^^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
LoongArch Support
^^^^^^^^^^^^^^^^^
[docs] Add llvm & clang release notes for LoongArch (#79097)
2024-01-23 15:27:06 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
RISC-V Support
^^^^^^^^^^^^^^
[clang][RISCV] Change default abi with f extension but without d extension (#73489) Now we have default abi lp64 for rv64if and ilp32 for rv32if, which is different with riscv-gnu-toolchain. In https://github.com/riscv-collab/riscv-gnu-toolchain/blob/8e9fb09a0c4b1e566492ee6f42e8c1fa5ef7e0c2/configure#L3385 when have f and not d, it prefers lp64f/ilp32f but no soft float. This patch tries to make their behaviors consistent.
2023-12-15 11:16:05 +08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
CUDA/HIP Language Changes
^^^^^^^^^^^^^^^^^^^^^^^^^
[WebAssembly] Update supported features in the generic CPU configuration Enable sign-ext and mutable-globals in -mcpu=generic. This makes these features enabled by default. These features are all [finished proposals], and all major wasm engines support them. [finished proposals]: https://github.com/WebAssembly/proposals/blob/main/finished-proposals.md Differential Revision: https://reviews.llvm.org/D125728
2022-10-18 10:50:37 -07:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
CUDA Support
^^^^^^^^^^^^
Clang: Change the default DWARF version to 5 (except on platforms that already opt in to specific versions - SCE, Android, and Darwin using DWARFv4 explicitly, for instance)
2022-01-23 20:45:25 -08:00
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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
[Clang] Remove NetBSD/i386 workaround for FP eval method with older versions (#74025) NetBSD 6.x is long EoL. Make 7.x the minimum and even that is EoL.
2024-07-22 19:31:01 -04:00
NetBSD Support
^^^^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
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
[Clang] [AVR] Fix USHRT_MAX for 16-bit int. For AVR, the definition of USHRT_MAX overflows. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D144218
2022-02-06 08:20:54 -05:00
AVR Support
^^^^^^^^^^^
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
DWARF Support in Clang
----------------------
[Clang][LLVM] Enable __arithmetic_fence and fprotect-parens on AArch64 Enable __arithmetic_fence and fprotect-parens on AArch64. Test plan: ninja check-clang check-clang-tools check-llvm Differential revision: https://reviews.llvm.org/D143781
2023-02-13 18:29:16 +00:00
Making the code compliant to the documentation about Floating Point support default values for C/C++. FPP-MODEL=PRECISE enables FFP-CONTRACT(FMA is enabled). Fix for https://bugs.llvm.org/show_bug.cgi?id=50222
2021-11-09 09:35:25 -05:00
Floating Point Support in Clang
-------------------------------
[clang] Add fixed point precision macros (#81207) This defines the builtin macros specified in `7.18a.3 Precision macros` of ISO/IEC TR 18037:2008. These are the `__*__` versions of them and the formal definitions in stdfix.h can use them.
2024-02-14 14:11:56 -08:00
Fixed Point Support in Clang
----------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
AST Matchers
------------
Fix hasName matcher assertion with inline namespaces (#100975) Fix handling of nodes which can be skipped in the fast path for the hasName matcher Fixes #100973
2024-07-29 19:11:02 +01:00
- Fixed an issue with the `hasName` and `hasAnyName` matcher when matching
inline namespaces with an enclosing namespace of the same name.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
clang-format
------------
libclang
--------
SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e. rename CLANG_SONAME to LIBCLANG_SOVERSION [clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION Differential Revision: https://reviews.llvm.org/D132486
2022-08-25 08:35:46 +02:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
Static Analyzer
---------------
[analyzer][docs] Add CSA release notes We'll soon branch off, and start releasing clang-17. Here is a patch, adjusting the release notes for what we achieved since the last release. I used this command to inspect the interesting commits: ``` git log --oneline llvmorg-16.0.0..llvm/main \ clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | \ grep -v NFC | grep -v -i revert ``` This filters in CSA directories and filters out NFC and revert commits. Given that in the release-notes, we usually don't put links to commits, I'll remove them from this patch as well. I just put them there to make it easier to review for you. I tried to group the changes into meaningful chunks, and dropped some of the uninteresting commits. I've also dropped the commits that were backported to clang-16. Check out how it looks, and propose changes like usual. --- FYI the `ninja docs-clang-html` produces the html docs, including the `ReleaseNotes`. And the produced artifact will be at `build/tools/clang/docs/html/ReleaseNotes.html`. Differential Revision: https://reviews.llvm.org/D155445
2023-07-24 08:26:54 +02:00
[analyzer][docs] Add clang-19 release notes for CSA (#97418) The day is coming for creating the release branch for clang-19, [scheduled](https://discourse.llvm.org/t/llvm-19-release-schedule-and-planning/79828) for the 23rd of July. Let's start syncing the ReleaseNotes, and be proud of what we achieved since clang-18. After this is merged, let's try to keep the ReleaseNotes in sync with the changes.
2024-07-10 16:53:12 +02:00
New features
^^^^^^^^^^^^
[clang][analyzer] Support `ownership_{returns,takes}` attributes (#98941) Add support for checking mismatched ownership_returns/ownership_takes attributes. Closes #76861
2024-07-24 14:15:08 +03:00
- MallocChecker now checks for ``ownership_returns(class, idx)`` and ``ownership_takes(class, idx)``
attributes with class names different from "malloc". Clang static analyzer now reports an error
if class of allocation and deallocation function mismatches.
`Documentation <https://clang.llvm.org/docs/analyzer/checkers.html#unix-mismatcheddeallocator-c-c>`__.
[analyzer][docs] Add clang-19 release notes for CSA (#97418) The day is coming for creating the release branch for clang-19, [scheduled](https://discourse.llvm.org/t/llvm-19-release-schedule-and-planning/79828) for the 23rd of July. Let's start syncing the ReleaseNotes, and be proud of what we achieved since clang-18. After this is merged, let's try to keep the ReleaseNotes in sync with the changes.
2024-07-10 16:53:12 +02:00
Crash and bug fixes
^^^^^^^^^^^^^^^^^^^
[analyzer][docs] Update the release notes for llvm-18 (#76446) This PR prepares the release notes of the Clang Static Analyzer for the llvm-18 release branch, due in about a week. See the regular [release schedule](https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule). This patch was written after examining the relevant Static Analyzer commits since the last release. Have a look at the commits, and provide feedback if I missed anything interesting. Note that the release notes is not meant to be an exhaustive list of the changes, but rather a curated list of the relevant changes that might interest our stakeholders, such as tool vendors based on top of CSA or users with custom checkers. See the relevant commits by using this command: ``` git log --oneline llvmorg-18-init..llvm/main clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | grep -v NFC | grep -v -i revert ```
2023-12-28 15:48:59 +01:00
Improvements
^^^^^^^^^^^^
[Clang][Sema] Disallow applying `onwership_returns` to functions that return non-pointers (#99564) `onwership_returns` works only with pointers, since it models user-defined memory allocation functions. Make semantics more clear and report an error if attribute is attached to wrong function. Closes #99501
2024-07-29 19:43:50 +03:00
- Improved the handling of the ``ownership_returns`` attribute. Now, Clang reports an
error if the attribute is attached to a function that returns a non-pointer value.
Fixes (#GH99501)
[analyzer][docs] Update the release notes for llvm-18 (#76446) This PR prepares the release notes of the Clang Static Analyzer for the llvm-18 release branch, due in about a week. See the regular [release schedule](https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule). This patch was written after examining the relevant Static Analyzer commits since the last release. Have a look at the commits, and provide feedback if I missed anything interesting. Note that the release notes is not meant to be an exhaustive list of the changes, but rather a curated list of the relevant changes that might interest our stakeholders, such as tool vendors based on top of CSA or users with custom checkers. See the relevant commits by using this command: ``` git log --oneline llvmorg-18-init..llvm/main clang/{lib/StaticAnalyzer,include/clang/StaticAnalyzer} | grep -v NFC | grep -v -i revert ```
2023-12-28 15:48:59 +01:00
Moved checkers
^^^^^^^^^^^^^^
[clang][msan] Turn on -fsanitize-memory-param-retval by default This eagerly reports use of undef values when passed to noundef parameters or returned from noundef functions. This also decreases binary sizes under msan. To go back to the previous behavior, pass `-fno-sanitize-memory-param-retval`. Reviewed By: vitalybuka, MaskRay Differential Revision: https://reviews.llvm.org/D134669
2022-09-26 17:41:37 -07:00
.. _release-notes-sanitizers:
Sanitizers
----------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[python] Expose clang_Location_isInSystemHeader Add is_in_system_header property for Location class. Corresponding unit test was also added. Differential Revision: https://reviews.llvm.org/D147414
2023-04-04 09:21:04 -04:00
Python Binding Changes
----------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
[Clang] [Parser] Support [[omp::assume]] (#84582) This pr implements the `[[omp::assume]]` spelling for the `__attribute__((assume))` attribute. It does not change anything about how that attribute is handled by the rest of Clang.
2024-03-12 13:42:43 +01:00
OpenMP Support
--------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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
clang/release notes: s/Subversion/git/
2020-03-22 22:18:40 +01:00
API documentation which are up-to-date with the Git version of
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
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
[Clang][docs] Update the release notes page to the new skeleton Was discussed at https://reviews.llvm.org/D142578.
2023-02-15 23:53:38 +02:00
contact us on the `Discourse forums (Clang Frontend category)
Update references to Discourse instead of the mailing lists. Update the references to the old Mailman mailing lists to point to Discourse forums. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D128766
2022-07-01 14:07:48 -07:00
<https://discourse.llvm.org/c/clang/6>`_.
Reference in New Issue Copy Permalink