mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 13:26:07 +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.

238 lines
5.8 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
-----------------------------------------
[Release Notes] [C++20] [Modules] Summarize modules related change to the release note for clang 18 Given clang18 is going to be released, this patch collects the modules related change to release notes to make users have a clear vision for modules.
2024-01-19 15:08:39 +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
ABI Changes in This Version
---------------------------
[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] 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
[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] 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][C++26] Implement Pack Indexing (P2662R3). (#72644) Implements https://isocpp.org/files/papers/P2662R3.pdf The feature is exposed as an extension in older language modes. Mangling is not yet supported and that is something we will have to do before release.
2024-01-27 10:23:38 +01:00
- Implemented `P2662R3 Pack Indexing <https://wg21.link/P2662R3>`_.
[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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[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
in the template parameters, but is deduced from a previous argument.
(`#78449: <https://github.com/llvm/llvm-project/issues/78449>`_).
[Clang] Implement CWG2598: Union of non-literal types (#78195) A union is considered a literal type unless it has no non-literal member. This resolves CWG2096 (which makes unions with literal members literal) and CWG2598 (empty unions are literal types). Fixes #77924
2024-01-17 06:16:12 +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
------------------
[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
^^^^^^^^^^^^^^^^^^^
[C23] Complete support for WG14 N2508 (#71398) In Clang 16, we implemented the ability to add a label at the end of a compound statement. These changes complete the implementation by allowing a label to be followed by a declaration in C. Note, this seems to have fixed an issue with some OpenMP stand-alone directives not being properly diagnosed as per: https://www.openmp.org/spec-html/5.1/openmpsu19.html#x34-330002.1.3 (The same requirement exists in OpenMP 5.2 as well.)
2023-11-20 10:52:11 -05:00
Fix the Sphinx build bot This addresses an accidental break from 41667a8b9b624e282e7c08fadf7091223728d1c1
2022-08-26 10:04:06 -04:00
Non-comprehensive list of changes in this release
-------------------------------------------------
Diagnosing the Future Keywords The patch diagnoses an identifier as a future keyword if it exists in a future language mode, such as: int restrict; in C modes earlier than C99. We now give a warning to the user that such an identifier is a future keyword. Handles keywords from C as well as C++. Differential Revision: https://reviews.llvm.org/D131683
2022-08-26 09:17:14 -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
------------------
Add -fkeep-system-includes modifier for -E This option will cause -E to preserve the #include directives for system headers, rather than expanding them into the output. This can greatly reduce the volume of preprocessed source text in a test case, making test case reduction simpler. Note that -fkeep-system-includes is not always appropriate. For example, if the problem you want to reproduce is induced by a system header file, it's better to expand those headers fully. If your source defines symbols that influence the content of a system header (e.g., _POSIX_SOURCE) then -E will eliminate the definition, potentially changing the meaning of the preprocessed source. If you use -isystem to point to non-system headers, for example to suppress warnings in third-party software, those will not be expanded and might make the preprocessed source less useful as a test case.
2023-09-28 07:18:11 -07: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
-----------------------
[docs] Add release notes for news in 16.x done by me, or otherwise relating to MinGW targets Differential Revision: https://reviews.llvm.org/D142346
2023-01-23 13:25:55 +02: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
--------------------------
[coroutines] Introduce [[clang::coro_lifetimebound]] (#72851) Adds attribute `[[clang::coro_lifetimebound]]`. All arguments to a function are considered to be **lifetime bound** if the function returns a type annotated with ``[[clang::coro_lifetimebound]]`` and ``[[clang::coro_return_type]]``.
2023-11-22 12:51:24 +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
Improvements to Clang's diagnostics
-----------------------------------
[Sema] -Wzero-as-null-pointer-constant: don't warn for __null (#69126) The implementation of -Wzero-as-null-pointer-constant was done before the following fix has been committed to GCC: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=752e7593b0f19af233a0b7e72daab8413662b605;hp=298434c916c14e8adca2cab8a746aee29038c5b3 As a result, clang and gcc diverge on the use of `__null` and, consequently, on the use of `NULL` on systems like Linux/macOS where `NULL` is defined as `__null`. This is a problem for compatibility between gcc and clang, particularly for code bases that support C++98 or for single-source libraries that are implemented in C, but compiled as C++ via inclusion into a C++ translation unit. Code like this can not be changed to use `nullptr`, as it needs to maintain compatibility with C before C23 or C++ before C++11, but warns on the use of `NULL` in clang. The warning `Wzero-as-null-pointer-constant` is still useful with this change, as it allows to change `0` to `NULL`, which fixes gcc warnings and helps the reader distinguish between pointers and non-pointers. Users who require a full C++11 modernization pass can still use clang-tidy for that purpose.
2023-10-25 08:58:28 -07:00
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
----------------------------------
[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] Handle large shift counts in GetExprRange (#68590) GetExprRange did not expect that very large shift counts when narrowing the range based on logical right shifts. So with inputs such as *a >> 123456789012345678901uwb it would hit assertions about trying to convert a too large APInt into uint64_t. This patch fixes that by using the APInt value when determining if we should reduce the range by the shift count or not.
2023-10-10 10:25:01 +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
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][Sema] fix crash of attribute transform (#78088) Try to fix [issue](https://github.com/llvm/llvm-project/issues/73619) 1. During transforming `FunctionProtoType`, if `ThisContext` is `nullptr` and `CurrentContext` is `ClassTemplateSpecializationDecl`, Constructor of `CXXThisScopeRAII` and `Sema::getCurrentThisType` won't set `CXXThisTypeOverride` of Sema. This will lead to building `this` in `RebuildCXXThisExpr` with a invalid type(NULL type) and cause crash. 2. During transforming attribute type, if `modifiedType` of attribute type is changed, `EquivalentType` need to be transformed. If `EquivalentType` is `FunctionProtoType`, its `ParamVarDecl` will not be copyed(but parameter num does) and will not be instanced in `TransformFunctionTypeParams` since `ParamVarDecl` is `nullptr`. This will lead to crash in `findInstantiationOf`(can't find the instance of `ParamVarDecl`). This patch tries to fix these issues above. 1. If `CurrentContext` is `ClassTemplateSpecializationDecl`, Use it. 2. Use `EquivalentTypeLoc` instead of `EquivalentType` since it has parameter info. But, if use current `TypeLocBuilder`, it will crash in `TypeLocBuilder::push` since `LastType` is mismatch. Use an auxiliary `TypeLocBuilder` instead and get transformed `EquivalentType`. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-26 14:26:53 +08:00
- Fix crash when using lifetimebound attribute in function with trailing return.
Fixes (`#73619 <https://github.com/llvm/llvm-project/issues/73619>`_)
[Clang][Sema] fix outline member function template with default align crash (#78400) Try to fix [issue](https://github.com/llvm/llvm-project/issues/68490) and some extented problem. Root cause of current issue is that error handling in instantiation of function parameter with default initialization on sizeof or align expression. When instance an out-of-line template member function, depth of `TemplateTypeParmDecl` in default initialization doesn't change while depth of other template parameter does and this will lead to some template parameter uninstanced. Also, sometime it will leader to wrong instantiation when it uses the template parameter of class. Fix it by add template args of context when it's out-of-line. This will make `MultiLevelTemplateArgumentList::getNumLevels` matching the depth of template parameter. Testcase with some `static_assert` demonstrates the template parameter has been instanced correctly. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-26 14:46:42 +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
the default parameter.
Fixes (`#68490 <https://github.com/llvm/llvm-project/issues/68490>`_)
[Concepts] Traverse the instantiation chain for parameter injection inside a constraint scope (#79568) We preserve the trailing requires-expression during the lambda expression transformation. In order to get those referenced parameters inside a requires-expression properly resolved to the instantiated decls, we intended to inject these 'original' `ParmVarDecls` to the current instantiaion scope, at `Sema::SetupConstraintScope`. The previous approach seems to overlook nested instantiation chains, leading to the crash within a nested lambda followed by a requires clause. This fixes https://github.com/llvm/llvm-project/issues/73418.
2024-01-27 15:42:52 +08:00
- Fixed a bug where variables referenced by requires-clauses inside
nested generic lambdas were not properly injected into the constraint scope.
(`#73418 <https://github.com/llvm/llvm-project/issues/73418>`_)
[Clang][Sema] fix crash of attribute transform (#78088) Try to fix [issue](https://github.com/llvm/llvm-project/issues/73619) 1. During transforming `FunctionProtoType`, if `ThisContext` is `nullptr` and `CurrentContext` is `ClassTemplateSpecializationDecl`, Constructor of `CXXThisScopeRAII` and `Sema::getCurrentThisType` won't set `CXXThisTypeOverride` of Sema. This will lead to building `this` in `RebuildCXXThisExpr` with a invalid type(NULL type) and cause crash. 2. During transforming attribute type, if `modifiedType` of attribute type is changed, `EquivalentType` need to be transformed. If `EquivalentType` is `FunctionProtoType`, its `ParamVarDecl` will not be copyed(but parameter num does) and will not be instanced in `TransformFunctionTypeParams` since `ParamVarDecl` is `nullptr`. This will lead to crash in `findInstantiationOf`(can't find the instance of `ParamVarDecl`). This patch tries to fix these issues above. 1. If `CurrentContext` is `ClassTemplateSpecializationDecl`, Use it. 2. Use `EquivalentTypeLoc` instead of `EquivalentType` since it has parameter info. But, if use current `TypeLocBuilder`, it will crash in `TypeLocBuilder::push` since `LastType` is mismatch. Use an auxiliary `TypeLocBuilder` instead and get transformed `EquivalentType`. Co-authored-by: huqizhi <836744285@qq.com>
2024-01-26 14:26:53 +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 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
[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][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
[Docs] Fix documentation build. Missing ending `` after c92ad411f2f94d8521cd18abcb37285f9a390ecb
2024-01-25 19:19:28 -08:00
- ``__attribute__((rvv_vector_bits(N)))`` is now supported for RVV vbool*_t types.
Recommit "[RISCV] Support __riscv_v_fixed_vlen for vbool types. (#76551)" Test updated to expect i8 gep. Original message: This adopts a similar behavior to AArch64 SVE, where bool vectors are represented as a vector of chars with 1/8 the number of elements. This ensures the vector always occupies a power of 2 number of bytes. A consequence of this is that vbool64_t, vbool32_t, and vool16_t can only be used with a vector length that guarantees at least 8 bits.
2024-01-25 09:39:29 -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][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] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-13 22:46:33 +01:00
AST Matchers
------------
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] 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
New features
^^^^^^^^^^^^
Crash and bug fixes
^^^^^^^^^^^^^^^^^^^
Improvements
^^^^^^^^^^^^
Support C++20 Modules in clang-repl (#79261) This comes from when I playing around clang-repl with moduels : ) I succeeded to import std with https://libcxx.llvm.org/Modules.html and calling `std::printf` after this patch. I want to put the documentation part to https://clang.llvm.org/docs/StandardCPlusPlusModules.html in a separate commit.
2024-01-24 15:45:05 +08:00
- Support importing C++20 modules in clang-repl.
[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
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