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.

229 lines
5.4 KiB
ReStructuredText
Raw Normal View History

[docs] Fix title overline.
2021-05-04 00:32:36 +08:00
========================================
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
Clang 14.0.0 (In-Progress) Release Notes
[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/>`_
.. warning::
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
These are in-progress notes for the upcoming Clang 14 release.
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Release notes for previous releases can be found on
`the Download Page <https://releases.llvm.org/download.html>`_.
Introduction
============
This document contains the release notes for the Clang C/C++/Objective-C
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
frontend, part of the LLVM Compiler Infrastructure, release 14.0.0. 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/>`_.
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
What's New in Clang 14.0.0?
[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
------------------
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bump the trunk major version to 12 and clear the release notes.
2020-07-15 17:40:53 +08:00
- ...
[Doc] update ReleaseNotes with new warning note.
2020-06-05 00:45:04 +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
-------------------------------------------------
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
- ...
[PGO] Fix computation of function Hash And bump its version number accordingly. This is a patched recommit of 7c298c104bfe725d4315926a656263e8a5ac3054 Previous hash implementation was incorrectly passing an uint64_t, that got converted to an uint8_t, to finalize the hash computation. This led to different functions having the same hash if they only differ by the remaining statements, which is incorrect. Added a new test case that trivially tests that a small function change is reflected in the hash value. Not that as this patch fixes the hash computation, it would invalidate all hashes computed before that patch applies, this is why we bumped the version number. Update profile data hash entries due to hash function update, except for binary version, in which case we keep the buggy behavior for backward compatibility. Differential Revision: https://reviews.llvm.org/D79961
2020-05-26 02:44:35 +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
------------------
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
- ...
Reland Produce warning for performing pointer arithmetic on a null pointer. Summary: Test and produce warning for subtracting a pointer from null or subtracting null from a pointer. This reland adds the functionality that the warning is no longer reusing an existing warning, it has different wording for C vs C++ to refect the fact that nullptr-nullptr has defined behaviour in C++, it is suppressed when the warning is triggered by a system header and adds -Wnull-pointer-subtraction to allow the warning to be controlled. -Wextra implies -Wnull-pointer-subtraction. Author: Jamie Schmeiser <schmeise@ca.ibm.com> Reviewed By: efriedma (Eli Friedman), nickdesaulniers (Nick Desaulniers) Differential Revision: https://reviews.llvm.org/D98798
2021-07-20 22:12:20 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Deprecated Compiler Flags
-------------------------
- ...
Modified Compiler Flags
-----------------------
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
- ...
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08: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 22:23:02 +08:00
Removed Compiler Flags
-------------------------
Bump the trunk major version to 14 and clear the release notes.
2021-07-28 12:51:07 +08:00
- ...
[docs] Add a release note for the removing of -Wreturn-std-move-in-c++11 `-Wreturn-std-move-in-c++11` has been removed in fbee4a0c79cc4ee87c34e51342742a5bc6fcf872. Reviewed By: aaronpuchert, amccarth Differential Revision: https://reviews.llvm.org/D97364
2021-02-24 17:01:51 +08:00
[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
--------------------------
[Attributes]: refactor to expose ParsedAttrInfo::acceptsLangOpts. NFC We will use this function to filter code completion of attributes. Differential Revision: https://reviews.llvm.org/D107836
2021-08-10 23:56:32 +08:00
- Attributes loaded as clang plugins which are sensitive to LangOpts must
now override ``acceptsLangOpts`` instead of ``diagLangOpts``.
Returning false will produce a generic "attribute ignored" diagnostic, as
with clang's built-in attributes.
If plugins want to provide richer diagnostics, they can do so when the
attribute is handled instead, e.g. in ``handleDeclAttribute``.
(This was changed in order to better support attributes in code completion).
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Windows Support
---------------
Effectively revert 33c3d8a916c / D33782 This change would treat the token `or` in system headers as an identifier, and elsewhere as an operator. As reported in llvm.org/pr42427, many users classify their third party library headers as "system" headers to suppress warnings. There's no clean way to separate Windows SDK headers from user headers. Clang is still able to parse old Windows SDK headers if C++ operator names are disabled. Traditionally this was controlled by `-fno-operator-names`, but is now also enabled with `/permissive` since D103773. This change will prevent `clang-cl` from parsing <query.h> from the Windows SDK out of the box, but there are multiple ways to work around that: - Pass `/clang:-fno-operator-names` - Pass `/permissive` - Pass `-DQUERY_H_RESTRICTION_PERMISSIVE` In all of these modes, the operator names will consistently be available or not available, instead of depending on whether the code is in a system header. I added a release note for this, since it may break straightforward users of the Windows SDK. Fixes PR42427 Differential Revision: https://reviews.llvm.org/D108720
2021-08-26 02:34:00 +08:00
- An MSVC compatibility workaround for C++ operator names was removed. As a
result, the ``<query.h>`` Windows SDK header may not compile out of the box.
Users should use a recent SDK and pass ``-DQUERY_H_RESTRICTION_PERMISSIVE``
or pass ``/permissive`` to disable C++ operator names altogether. See
`PR42427 <https://llvm.org/pr42427>` for more info.
[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
---------------------------
Make wide multi-character character literals ill-formed This implements P2362, which has not yet been approved by the C++ committee, but because wide-multi character literals are implementation defined, clang might not have to wait for WG21. This change is also being applied in C mode as the behavior is implementation-defined in C as well and there's no benefit to having different rules between the languages. The other part of P2362, making non-representable character literals ill-formed, is already implemented by clang
2021-08-20 23:10:53 +08:00
- Wide multi-characters literals such as ``L'ab'`` that would previously be interpreted as ``L'b'``
are now ill-formed in all language modes. The motivation for this change is outlined in
`P2362 <wg21.link/P2362>`_.
[Clang] add support for error+warning fn attrs Add support for the GNU C style __attribute__((error(""))) and __attribute__((warning(""))). These attributes are meant to be put on declarations of functions whom should not be called. They are frequently used to provide compile time diagnostics similar to _Static_assert, but which may rely on non-ICE conditions (ie. relying on compiler optimizations). This is also similar to diagnose_if function attribute, but can diagnose after optimizations have been run. While users may instead simply call undefined functions in such cases to get a linkage failure from the linker, these provide a much more ergonomic and actionable diagnostic to users and do so at compile time rather than at link time. Users instead may be able use inline asm .err directives. These are used throughout the Linux kernel in its implementation of BUILD_BUG and BUILD_BUG_ON macros. These macros generally cannot be converted to use _Static_assert because many of the parameters are not ICEs. The Linux kernel still needs to be modified to make use of these when building with Clang; I have a patch that does so I will send once this feature is landed. To do so, we create a new IR level Function attribute, "dontcall" (both error and warning boil down to one IR Fn Attr). Then, similar to calls to inline asm, we attach a !srcloc Metadata node to call sites of such attributed callees. The backend diagnoses these during instruction selection, while we still know that a call is a call (vs say a JMP that's a tail call) in an arch agnostic manner. The frontend then reconstructs the SourceLocation from that Metadata, and determines whether to emit an error or warning based on the callee's attribute. Link: https://bugs.llvm.org/show_bug.cgi?id=16428 Link: https://github.com/ClangBuiltLinux/linux/issues/1173 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D106030
2021-08-26 01:18:13 +08:00
- Support for ``__attribute__((error("")))`` and
``__attribute__((warning("")))`` function attributes have been added.
[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
-----------------------------
Bump the trunk major version to 12 and clear the release notes.
2020-07-15 17:40:53 +08:00
- ...
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
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
^^^^^^^^^^^^^^^^^^^^^
...
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] Bump the latest supported CUDA version to 11.4. This should reduce the amount of noise issued by clang for the recent-ish CUDA versions. Clang still does not support all the features offered by NVCC, but is expected to handle CUDA headers and produce binaries for all GPUs supported by NVCC. Differential Revision: https://reviews.llvm.org/D108248
2021-08-18 05:39:58 +08:00
CUDA Language Changes in Clang
Fixed doc build.
2021-08-24 04:45:13 +08:00
------------------------------
[CUDA] Bump the latest supported CUDA version to 11.4. This should reduce the amount of noise issued by clang for the recent-ish CUDA versions. Clang still does not support all the features offered by NVCC, but is expected to handle CUDA headers and produce binaries for all GPUs supported by NVCC. Differential Revision: https://reviews.llvm.org/D108248
2021-08-18 05:39:58 +08:00
- Clang now supports CUDA versions up to 11.4.
- Default GPU architecture has been changed from sm_20 to sm_35.
[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
-----------------------
- ...
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] AVX512FP16 instructions enabling 1/6 1. Enable FP16 type support and basic declarations used by following patches. 2. Enable new instructions VMOVW and VMOVSH. Ref.: https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D105263
2021-08-10 11:18:40 +08:00
- Support for ``AVX512-FP16`` instructions has been added.
[X86] Support Intel avxvnni This patch mainly made the following changes: 1. Support AVX-VNNI instructions; 2. Introduce ExplicitVEXPrefix flag so that vpdpbusd/vpdpbusds/vpdpbusds/vpdpbusds instructions only use vex-encoding when user explicity add {vex} prefix. Differential Revision: https://reviews.llvm.org/D89105
2020-10-30 12:58:05 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Internal API Changes
--------------------
Bump the trunk major version to 12 and clear the release notes.
2020-07-15 17:40:53 +08:00
- ...
Removed a RecursiveASTVisitor feature to visit operator kinds with different methods Summary: This feature was only used in two places, but contributed a non-trivial amount to the complexity of RecursiveASTVisitor, and was buggy (see my recent patches where I was fixing the bugs that I noticed). I don't think the convenience benefit of this feature is worth the complexity. Besides complexity, another issue with the current state of RecursiveASTVisitor is the non-uniformity in how it handles different AST nodes. All AST nodes follow a regular pattern, but operators are special -- and this special behavior not documented. Correct usage of RecursiveASTVisitor relies on shadowing member functions with specific names and signatures. Near misses don't cause any compile-time errors, incorrectly named or typed methods are just silently ignored. Therefore, predictability of RecursiveASTVisitor API is quite important. This change reduces the size of the `clang` binary by 38 KB (0.2%) in release mode, and by 7 MB (0.3%) in debug mode. The `clang-tidy` binary is reduced by 205 KB (0.3%) in release mode, and by 5 MB (0.4%) in debug mode. I don't think these code size improvements are significant enough to justify this change on its own (for me, the primary motivation is reducing code complexity), but they I think are a nice side-effect. Reviewers: rsmith, sammccall, ymandel, aaron.ballman Reviewed By: rsmith, sammccall, ymandel, aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82921
2020-07-03 23:01:01 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
Build System Changes
--------------------
Bump the trunk major version to 12 and clear the release notes.
2020-07-15 17:40:53 +08:00
- ...
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
AST Matchers
------------
Bump the trunk major version to 13 and clear the release notes.
2021-01-27 11:37:08 +08:00
- ...
Remove automatic traversal from forEach matcher Differential Revision: https://reviews.llvm.org/D91916
2020-05-23 09:12:51 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
clang-format
------------
[clang-format] Correctly attach enum braces with ShortEnums disabled Previously, with AllowShortEnumsOnASingleLine disabled, enums that would have otherwise fit on a single line would always put the opening brace on its own line. This patch ensures that these enums will only put the brace on its own line if the existing attachment rules indicate that it should. Reviewed By: HazardyKnusperkeks, curdeius Differential Revision: https://reviews.llvm.org/D99840
2021-07-28 16:17:54 +08:00
- Option ``AllowShortEnumsOnASingleLine: false`` has been improved, it now
correctly places the opening brace according to ``BraceWrapping.AfterEnum``.
[clang-format] Add basic support for formatting JSON I find as I develop I'm moving between many different languages C++,C#,JavaScript all the time. As I move between the file types I like to keep `clang-format` as my formatting tool of choice. (hence why I initially added C# support in {D58404}) I know those other languages have their own tools but I have to learn them all, and I have to work out how to configure them, and they may or may not have integration into my IDE or my source code integration. I am increasingly finding that I'm editing additional JSON files as part of my daily work and my editor and git commit hooks are just not setup to go and run [[ https://stedolan.github.io/jq/ | jq ]], So I tend to go to [[ https://jsonformatter.curiousconcept.com/ | JSON Formatter ]] and copy and paste back and forth. To get nicely formatted JSON. This is a painful process and I'd like a new one that causes me much less friction. This has come up from time to time: {D10543} https://stackoverflow.com/questions/35856565/clang-format-a-json-file https://bugs.llvm.org/show_bug.cgi?id=18699 I would like to stop having to do that and have formatting JSON as a first class clang-format support `Language` (even if it has minimal style settings at present). This revision adds support for formatting JSON using the inbuilt JSON serialization library of LLVM, With limited control at present only over the indentation level This adds an additional Language into the .clang-format file to separate the settings from your other supported languages. Reviewed By: HazardyKnusperkeks Differential Revision: https://reviews.llvm.org/D93528
2021-06-26 22:20:17 +08:00
[clang] Fix bad line ending (DOS instead of Unix) inside the release notes.
2020-02-14 05:46:33 +08:00
libclang
--------
- ...
Static Analyzer
---------------
- ...
.. _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
contact us via the `mailing
list <https://lists.llvm.org/mailman/listinfo/cfe-dev>`_.