maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages 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.

253 lines
7.9 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-02 15:13:01 +08:00
===========================================
Clang |release| |ReleaseNotesTitle|
===========================================
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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-02 15:13:01 +08:00
.. only:: PreRelease
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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-02 15: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
`the Download Page <https://releases.llvm.org/download.html>`_.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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-02 15: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-14 05:46:33 +08: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
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
releases may be downloaded from the `LLVM releases web
site <https://llvm.org/releases/>`_.
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>`_.
Note that if you are reading this file from a Git checkout or the
main Clang web page, this document applies to the *next* release, not
the current one. To see the release notes for a specific release, please
see the `releases page <https://llvm.org/releases/>`_.
[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-02 15: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-14 05:46:33 +08: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.
Major New Features
------------------
[clang] Never wrap a nullptr in CXXNewExpr::getArraySize() Otherwise callers of these functions have to check both the return value for and the contents of the returned llvm::Optional. Fixes #53742 Differential Revision: https://reviews.llvm.org/D119525
2022-02-11 15:27:33 +08:00
Bug Fixes
Fix underlining length; NFC
2022-05-06 20:47:19 +08:00
---------
Diagnose use of _Noreturn on a struct/union field C99 6.7.4p2 clarifies that a function specifier can only be used in the declaration of a function. _Noreturn is a function specifier, so it is a constraint violation to write it on a structure or union field, but we missed that case. Fixes #56800
2022-07-30 01:16:10 +08:00
- Fixes an accepts-invalid bug in C when using a ``_Noreturn`` function
specifier on something other than a function declaration. This fixes
`Issue 56800 <https://github.com/llvm/llvm-project/issues/56800>`_.
[SemaCXX] Validate destructor is valid for dependent classes We didn't check that a destructor's name matches the directly enclosing class if the class was dependent. I enabled the check we already had for non-dependent types, which seems to work. Added appropriate tests. Fixes GitHub issue #56772 Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D130936
2022-08-02 04:47:30 +08:00
- Fix `#56772 <https://github.com/llvm/llvm-project/issues/56772>`_ - invalid
destructor names were incorrectly accepted on template classes.
[clang] Short-circuit trivial constructors when evaluating arrays VisitCXXConstructExpr() will later do something similar, but for large arrays, we should try to do it once an not for every element. Fixes #56774 Differential Revision: https://reviews.llvm.org/D130791
2022-07-29 22:12:49 +08:00
- Improve compile-times with large dynamic array allocations with trivial
constructors. This fixes
[clang][NFC] Try to fix the docs build
2022-08-03 16:51:34 +08:00
`Issue 56774 <https://github.com/llvm/llvm-project/issues/56774>`_.
Error instead of assert when making a _BitInt vector We already correctly rejected: typedef __attribute__((vector_size(16))) _BitInt(4) Ty; but we would assert with: typedef __attribute__((ext_vector_type(4))) _BitInt(4) Ty; Now we issue the same error in both cases.
2022-08-04 02:05:09 +08:00
- No longer assert/miscompile when trying to make a vectorized ``_BitInt`` type
using the ``ext_vector_type`` attribute (the ``vector_size`` attribute was
already properly diagnosing this case).
[clang][sema] Fix collectConjunctionTerms() Consider: A == 5 && A != 5 IfA is 5, the old collectConjunctionTerms() would call itself again for the LHS (which it ignores), then the RHS (which it also ignores) and then just return without ever adding anything to the Terms array. Differential Revision: https://reviews.llvm.org/D131070
2022-08-03 23:05:07 +08:00
- Fix clang not properly diagnosing the failing subexpression when chained
binary operators are used in a ``static_assert`` expression.
[clang] Consider array filler in MaybeElementDependentArrayfiller() Any InitListExpr may have an array filler and since we may be evaluating the array filler as well, we need to take into account that the array filler expression might make the InitListExpr element dependent. Fixes https://github.com/llvm/llvm-project/issues/56016 Differential Revision: https://reviews.llvm.org/D131155
2022-08-04 18:53:06 +08:00
- Fix a crash when evaluating a multi-dimensional array's array filler
expression is element-dependent. This fixes
`Issue 50601 <https://github.com/llvm/llvm-project/issues/56016>`_.
[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-13 03:49:01 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Improvements to Clang's diagnostics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values DR2338 clarified that it was undefined behavior to set the value outside the range of the enumerations values for an enum without a fixed underlying type. We should diagnose this with a constant expression context. Differential Revision: https://reviews.llvm.org/D130058
2022-07-29 06:26:15 +08:00
- Clang will now correctly diagnose as ill-formed a constant expression where an
enum without a fixed underlying type is set to a value outside the range of
[Clang] Allow downgrading to a warning the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values In D130058 we diagnose the undefined behavior of setting the value outside the range of the enumerations values for an enum without a fixed underlying type. Based on feedback we will provide users to the ability to downgrade this diagnostic to a waring to allow for a transition period. We expect to turn this diagnostic to an error in the next release. Differential Revision: https://reviews.llvm.org/D131307
2022-08-09 06:17:34 +08:00
the enumeration's values. Due to the extended period of time this bug was
present in major C++ implementations (including Clang), this error has the
ability to be downgraded into a warning (via: -Wno-error=enum-constexpr-conversion)
to provide a transition period for users. This diagnostic is expected to turn
into an error-only diagnostic in the next Clang release. Fixes
[Clang] Diagnose ill-formed constant expression when setting a non fixed enum to a value outside the range of the enumeration values DR2338 clarified that it was undefined behavior to set the value outside the range of the enumerations values for an enum without a fixed underlying type. We should diagnose this with a constant expression context. Differential Revision: https://reviews.llvm.org/D130058
2022-07-29 06:26:15 +08:00
`Issue 50055: <https://github.com/llvm/llvm-project/issues/50055>`_.
[clang] format string checking for conpile-time evaluated str literal This patch enhances clang's ability to check compile-time determinable string literals as format strings, and can give FixIt hints at literals (unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805 mentiond two compile-time string cases. And this patch partially fixes one. ``` constexpr const char* foo() { return "%s %d"; } int main() { printf(foo(), "abc", "def"); return 0; } ``` This patch enables clang check format string for this: ``` <source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat] printf(foo(), "abc", "def"); ~~~~~ ^~~~~ <source>:2:42: note: format string is defined here constexpr const char *foo() { return "%s %d"; } ^~ %s 1 warning generated. ``` Reviewed By: aaron.ballman Signed-off-by: YingChi Long <me@inclyc.cn> Differential Revision: https://reviews.llvm.org/D130906
2022-08-03 10:07:31 +08:00
- Clang will now check compile-time determinable string literals as format strings.
[clang][docs] use `Fixes` instead of `This fixes` in ReleaseNotes [NFC]
2022-08-07 12:42:15 +08:00
Fixes `Issue 55805: <https://github.com/llvm/llvm-project/issues/55805>`_.
[Sema] -Wformat: support C23 format specifier %b %B Close #56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions and %B for the printf family of functions. glibc 2.35 and latest Android bionic added %b/%B printf support. From https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available yet. Like GCC, we don't test library support. GCC 12 -Wformat -pedantic emits a warning: > warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=] The behavior is not ported. Note: `freebsd_kernel_printf` uses %b differently. Reviewed By: aaron.ballman, dim, enh Differential Revision: https://reviews.llvm.org/D131057
2022-08-05 01:26:31 +08:00
- ``-Wformat`` now recognizes ``%b`` for the ``printf``/``scanf`` family of
functions and ``%B`` for the ``printf`` family of functions. Fixes
`Issue 56885: <https://github.com/llvm/llvm-project/issues/56885>`_.
Fix -Wbitfield-constant-conversion on 1-bit signed bitfield A one-bit signed bit-field can only hold the values 0 and -1; this corrects the diagnostic behavior accordingly. Fixes #53253 Differential Revision: https://reviews.llvm.org/D131255
2022-08-09 23:42:39 +08:00
- ``-Wbitfield-constant-conversion`` now diagnoses implicit truncation when 1 is
assigned to a 1-bit signed integer bitfield. This fixes
`Issue 53253 <https://github.com/llvm/llvm-project/issues/53253>`_.
Default implicit function pointer conversions diagnostic to be an error Implicitly converting between incompatible function pointers in C is currently a default-on warning (it is an error in C++). However, this is very poor security posture. A mismatch in parameters or return types, or a mismatch in calling conventions, etc can lead to exploitable security vulnerabilities. Rather than allow this unsafe practice with a warning, this patch strengthens the warning to be an error (while still allowing users the ability to disable the error or the warning entirely to ease migration). Users should either ensure the signatures are correctly compatible or they should use an explicit cast if they believe that's more reasonable. Differential Revision: https://reviews.llvm.org/D131351
2022-08-11 01:52:33 +08:00
- ``-Wincompatible-function-pointer-types`` now defaults to an error in all C
language modes. It may be downgraded to a warning with
``-Wno-error=incompatible-function-pointer-types`` or disabled entirely with
``-Wno-implicit-function-pointer-types``.
[clang] Require strict matches for defines for PCH in GCC style directories When clang includes a PCH, it tolerates some amount of differences between the defines used when creating and when including the PCH - this seems to be intentionally allowed in c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in b63687519610a73dd565be1fec28332211b4df5b). When using a PCH (or when picking a PCH out of a directory containing multiple candidates) Clang used to accept the header if there were defines on the command line when creating the PCH that are missing when using the PCH, or vice versa, defines only set when using the PCH. The only cases where Clang explicitly rejected the use of a PCH is if there was an explicit conflict between the options, e.g. -DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO. The latter commit added a FIXME that we really should check whether mismatched defines actually were used somewhere in the PCH, so that the define would affect the outcome. This FIXME has stood unaddressed since 2012. This differs from GCC, which rejects PCH files if the defines differ at all. When explicitly including a single PCH file, the relaxed policy of allowing minor differences is harmless for correct use cases (but may fail to diagnose mismtaches), and potentially allow using PCHs in wider cases (where the user intentionally know that the differences in defines are harmless for the PCH). However, for GCC style PCH directories, with a directory containing multiple PCH variants and the compiler should pick the correct match out of them, Clang's relaxed logic was problematic. The directory could contain two otherwise identical PCHs, but one built with -DFOO and one without. When attempting to include a PCH and iterating over the candidates in the directory, Clang would essentially pick the first one out of the two, even if there existed a better, exact match in the directory. Keep the relaxed checking when specificlly including one named PCH file, but require strict matches when trying to pick the right candidate out of a GCC style directory with alternatives. This fixes https://github.com/lhmouse/mcfgthread/issues/63. Differential Revision: https://reviews.llvm.org/D126676
2022-05-25 20:07:18 +08:00
- When including a PCH from a GCC style directory with multiple alternative PCH
files, Clang now requires all defines set on the command line while generating
the PCH and when including it to match. This matches GCC's behaviour.
Previously Clang would tolerate defines to be set when creating the PCH but
missing when used, or vice versa. This makes sure that Clang picks the
correct one, where it previously would consider multiple ones as potentially
acceptable (and erroneously use whichever one is tried first).
[clang][sema] Print more information about failed static assertions For failed static assertions, try to take the expression apart and print useful information about why it failed. In particular, look at binary operators and print the compile-time evaluated value of the LHS/RHS. Differential Revision: https://reviews.llvm.org/D130894
2022-08-01 20:12:32 +08:00
- Clang will now print more information about failed static assertions. In
particular, simple static assertion expressions are evaluated to their
compile-time value and printed out if the assertion fails.
[misexpect] Re-implement MisExpect Diagnostics Reimplements MisExpect diagnostics from D66324 to reconstruct its original checking methodology only using MD_prof branch_weights metadata. New checks rely on 2 invariants: 1) For frontend instrumentation, MD_prof branch_weights will always be populated before llvm.expect intrinsics are lowered. 2) for IR and sample profiling, llvm.expect intrinsics will always be lowered before branch_weights are populated from the IR profiles. These invariants allow the checking to assume how the existing branch weights are populated depending on the profiling method used, and emit the correct diagnostics. If these invariants are ever invalidated, the MisExpect related checks would need to be updated, potentially by re-introducing MD_misexpect metadata, and ensuring it always will be transformed the same way as branch_weights in other optimization passes. Frontend based profiling is now enabled without using LLVM Args, by introducing a new CodeGen option, and checking if the -Wmisexpect flag has been passed on the command line. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D115907
2022-04-02 06:03:48 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Non-comprehensive list of changes in this release
Fix clang Sphinx build bot
2022-03-25 19:13:26 +08:00
-------------------------------------------------
[docs] Add blank lines to help Sphinx parse nested bullets.
2022-05-06 06:57:17 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
New Compiler Flags
------------------
Deprecated Compiler Flags
-------------------------
Modified Compiler Flags
-----------------------
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 22:23:02 +08:00
Removed Compiler Flags
-------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
New Pragmas in Clang
--------------------
- ...
Attribute Changes in Clang
--------------------------
Windows Support
---------------
[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-03 05:06:04 +08:00
AIX Support
-----------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
C Language Changes in Clang
---------------------------
Implement WG14 N2764 the [[noreturn]] attribute This adds support for http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf, which was adopted at the Feb 2022 WG14 meeting. That paper adds [[noreturn]] and [[_Noreturn]] to the list of supported attributes in C2x. These attributes have the same semantics as the [[noreturn]] attribute in C++. The [[_Noreturn]] attribute was added as a deprecated feature so that translation units which include <stdnoreturn.h> do not get an error on use of [[noreturn]] because the macro expands to _Noreturn. Users can use -Wno-deprecated-attributes to silence the diagnostic. Use of <stdnotreturn.h> or the noreturn macro were both deprecated. Users can define the _CLANG_DISABLE_CRT_DEPRECATION_WARNINGS macro to suppress the deprecation diagnostics coming from the header file.
2022-02-14 22:33:48 +08:00
C2x Feature Support
-------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
C++ Language Changes in Clang
-----------------------------
clang: libstdc++ LWM is 4.8.3 Document oldest libstdc++ as 4.8.3, remove a hack for a 4.6 issue. Differential Revision: https://reviews.llvm.org/D100465
2021-04-14 19:18:23 +08:00
C++20 Feature Support
^^^^^^^^^^^^^^^^^^^^^
[Concepts] Implement overload resolution for destructors (P0848) This patch implements a necessary part of P0848, the overload resolution for destructors. It is now possible to overload destructors based on constraints, and the eligible destructor will be selected at the end of the class. The approach this patch takes is to perform the overload resolution in Sema::ActOnFields and to mark the selected destructor using a new property in FunctionDeclBitfields. CXXRecordDecl::getDestructor is then modified to use this property to return the correct destructor. This closes https://github.com/llvm/llvm-project/issues/45614. Reviewed By: #clang-language-wg, erichkeane Differential Revision: https://reviews.llvm.org/D126194
2022-06-17 01:52:12 +08:00
[Clang][C++20] Support capturing structured bindings in lambdas This completes the implementation of P1091R3 and P1381R1. This patch allow the capture of structured bindings both for C++20+ and C++17, with extension/compat warning. In addition, capturing an anonymous union member, a bitfield, or a structured binding thereof now has a better diagnostic. We only support structured bindings - as opposed to other kinds of structured statements/blocks. We still emit an error for those. In addition, support for structured bindings capture is entirely disabled in OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there. Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented. at the request of @shafik, i can confirm the correct behavior of lldb wit this change. Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/54300 Fixes https://github.com/llvm/llvm-project/issues/52720 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D122768
2022-03-30 20:27:44 +08:00
- Support capturing structured bindings in lambdas
(`P1091R3 <https://wg21.link/p1091r3>`_ and `P1381R1 <https://wg21.link/P1381R1>`).
This fixes issues `GH52720 <https://github.com/llvm/llvm-project/issues/52720>`_,
`GH54300 <https://github.com/llvm/llvm-project/issues/54300>`_,
`GH54301 <https://github.com/llvm/llvm-project/issues/54301>`_,
and `GH49430 <https://github.com/llvm/llvm-project/issues/49430>`_.
clang: libstdc++ LWM is 4.8.3 Document oldest libstdc++ as 4.8.3, remove a hack for a 4.6 issue. Differential Revision: https://reviews.llvm.org/D100465
2021-04-14 19:18:23 +08:00
C++2b Feature Support
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
^^^^^^^^^^^^^^^^^^^^^
[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-04 02:13:56 +08:00
CUDA/HIP Language Changes in Clang
----------------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Objective-C Language Changes in Clang
-------------------------------------
OpenCL C Language Changes in Clang
----------------------------------
...
ABI Changes in Clang
--------------------
OpenMP Support in Clang
-----------------------
[OpenMP][Docs] Remove old 14.0 release information Summary: This patch removes the OpenMP sections in the release notes. These will be filled once the release is close and implementations are finalized.
2022-04-19 20:45:51 +08:00
...
[Clang][Docs] Add documention for new OpenMP offloading driver This patch adds more documentation for the OpenMP offloading driver. This includes a new file that describes the overall pipeline becuase that was not previously explained in full elsewhere. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D118815
2022-02-03 02:06:55 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
CUDA Support in Clang
---------------------
- ...
[X86] Enable constexpr on POPCNT intrinsics (PR31446) This is a first step patch to enable constexpr support and testing to a large number of x86 intrinsics. All I've done here is provide a DEFAULT_FN_ATTRS_CONSTEXPR variant to our existing DEFAULT_FN_ATTRS tag approach that adds constexpr on c++ builds. The clang cuda headers do something similar. I've started with POPCNT mainly as its tiny and are wrappers to generic __builtin_* intrinsics which already act as constexpr. Differential Revision: https://reviews.llvm.org/D86229
2020-08-21 04:37:51 +08:00
X86 Support in Clang
--------------------
[X86] Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk This is to address feature request from https://github.com/ClangBuiltLinux/linux/issues/1665 Reviewed By: nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D130754
2022-07-29 17:47:49 +08:00
- Support ``-mindirect-branch-cs-prefix`` for call and jmp to indirect thunk.
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-24 12:45:25 +08:00
DWARF Support in Clang
----------------------
[AArch64]Enabling Cortex-A510 Support This patch enables support for Cortex-A510 CPUs. Reviewed By: MarkMurrayARM, dmgreen Differential Revision: https://reviews.llvm.org/D109825
2021-10-15 21:29:57 +08:00
Arm and AArch64 Support in Clang
--------------------------------
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 22:35:25 +08:00
Floating Point Support in Clang
-------------------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Internal API Changes
--------------------
Build System Changes
--------------------
AST Matchers
------------
clang-format
------------
[clang-extdef-mapping] Directly process .ast files When doing CTU analysis setup you pre-compile .cpp to .ast and then you run clang-extdef-mapping on the .cpp file as well. This is a pretty slow process since we have to recompile the file each time. With this patch you can now run clang-extdef-mapping directly on the .ast file. That saves a lot of time. I tried this on llvm/lib/AsmParser/Parser.cpp and running extdef-mapping on the .cpp file took 5.4s on my machine. While running it on the .ast file it took 2s. This can save a lot of time for the setup phase of CTU analysis. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D128704
2022-07-05 19:45:32 +08:00
clang-extdef-mapping
--------------------
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
libclang
--------
Static Analyzer
---------------
Reland "[analyzer] Deprecate `-analyzer-store region` flag" I'm trying to remove unused options from the `Analyses.def` file, then merge the rest of the useful options into the `AnalyzerOptions.def`. Then make sure one can set these by an `-analyzer-config XXX=YYY` style flag. Then surface the `-analyzer-config` to the `clang` frontend; After all of this, we can pursue the tablegen approach described https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488 In this patch, I'm proposing flag deprecations. We should support deprecated analyzer flags for exactly one release. In this case I'm planning to drop this flag in `clang-16`. In the clang frontend, now we won't pass this option to the cc1 frontend, rather emit a warning diagnostic reminding the users about this deprecated flag, which will be turned into error in clang-16. Unfortunately, I had to remove all the tests referring to this flag, causing a mass change. I've also added a test for checking this warning. I've seen that `scan-build` also uses this flag, but I think we should remove that part only after we turn this into a hard error. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D126215
2022-06-14 15:20:41 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
.. _release-notes-ubsan:
Undefined Behavior Sanitizer (UBSan)
------------------------------------
Core Analysis Improvements
==========================
- ...
New Issues Found
================
- ...
Python Binding Changes
----------------------
The following methods have been added:
- ...
Significant Known Problems
==========================
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-23 05:18:40 +08: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-14 05:46:33 +08: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
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-02 05:07:48 +08:00
contact us on the Discourse forums (Clang Frontend category)
<https://discourse.llvm.org/c/clang/6>`_.