llvm-project/clang/docs/ReleaseNotes.rst

238 lines
5.7 KiB
ReStructuredText
Raw Normal View History

=======================================
Clang 9.0.0 (In-Progress) Release Notes
=======================================
.. contents::
:local:
:depth: 2
Written by the `LLVM Team <https://llvm.org/>`_
.. warning::
These are in-progress notes for the upcoming Clang 9 release.
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
frontend, part of the LLVM Compiler Infrastructure, release 9.0.0. Here we
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/>`_.
2017-08-31 02:35:44 +08: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>`_.
Note that if you are reading this file from a Subversion 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/>`_.
What's New in Clang 9.0.0?
==========================
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
------------------
- ...
Improvements to Clang's diagnostics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- ...
Non-comprehensive list of changes in this release
-------------------------------------------------
- ...
New Compiler Flags
------------------
- ...
Deprecated Compiler Flags
-------------------------
The following options are deprecated and ignored. They will be removed in
future versions of Clang.
- ...
Modified Compiler Flags
-----------------------
- `clang -dumpversion` now returns the version of Clang itself.
- ...
New Pragmas in Clang
--------------------
- ...
Attribute Changes in Clang
--------------------------
- ...
Windows Support
---------------
- ...
C Language Changes in Clang
---------------------------
- ...
...
C11 Feature Support
^^^^^^^^^^^^^^^^^^^
...
C++ Language Changes in Clang
-----------------------------
- ...
C++1z Feature Support
^^^^^^^^^^^^^^^^^^^^^
...
Objective-C Language Changes in Clang
-------------------------------------
...
OpenCL C Language Changes in Clang
----------------------------------
...
ABI Changes in Clang
--------------------
- ...
OpenMP Support in Clang
-----------------------
- Added emission of the debug information for NVPTX target devices.
CUDA Support in Clang
---------------------
- Added emission of the debug information for the device code.
Internal API Changes
--------------------
These are major API changes that have happened since the 8.0.0 release of
Clang. If upgrading an external codebase that uses Clang as a library,
this section should help get you past the largest hurdles of upgrading.
Build System Changes
--------------------
These are major changes to the build system that have happened since the 8.0.0
release of Clang. Users of the build system should adjust accordingly.
- In 8.0.0 and below, the install-clang-headers target would install clang's
resource directory headers. This installation is now performed by the
install-clang-resource-headers target. Users of the old install-clang-headers
target should switch to the new install-clang-resource-headers target. The
install-clang-headers target now installs clang's API headers (corresponding
to its libraries), which is consistent with the install-llvm-headers target.
- ...
AST Matchers
------------
- ...
clang-format
------------
- Add language support for clang-formatting C# files
- Add Microsoft coding style to encapsulate default C# formatting style
- Added new option `PPDIS_BeforeHash` (in configuration: `BeforeHash`) to
`IndentPPDirectives` which indents preprocessor directives before the hash.
libclang
--------
- When `CINDEXTEST_INCLUDE_ATTRIBUTED_TYPES` is not provided when making a
CXType, the equivalent type of the AttributedType is returned instead of the
modified type if the user does not want attribute sugar. The equivalent type
represents the minimally-desugared type which the AttributedType is
canonically equivalent to.
Static Analyzer
---------------
- The UninitializedObject checker is now considered as stable.
(moved from the 'alpha.cplusplus' to the 'optin.cplusplus' package)
...
[clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang part Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` unsigned char store = 0; bool consume(unsigned int val); void test(unsigned long val) { if (consume(val)) { // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`. // If their bit widths are different on this platform, the implicit // truncation happens. And if that `unsigned long` had a value bigger // than UINT_MAX, then you may or may not have a bug. // Similarly, integer addition happens on `int`s, so `store` will // be promoted to an `int`, the sum calculated (0+768=768), // and the result demoted to `unsigned char`, and stored to `store`. // In this case, the `store` will still be 0. Again, not always intended. store = store + 768; // before addition, 'store' was promoted to int. } // But yes, sometimes this is intentional. // You can either make the conversion explicit (void)consume((unsigned int)val); // or mask the value so no bits will be *implicitly* lost. (void)consume((~((unsigned int)0)) & val); } ``` Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, there are cases where it does **not** warn. So a Sanitizer is needed. I don't have any motivational numbers, but i know i had this kind of problem 10-20 times, and it was never easy to track down. The logic to detect whether an truncation has happened is pretty simple if you think about it - https://godbolt.org/g/NEzXbb - basically, just extend (using the new, not original!, signedness) the 'truncated' value back to it's original width, and equality-compare it with the original value. The most non-trivial thing here is the logic to detect whether this `ImplicitCastExpr` AST node is **actually** an implicit conversion, //or// part of an explicit cast. Because the explicit casts are modeled as an outer `ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children. https://godbolt.org/g/eE1GkJ Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`. So if that flag is **not** set, then it is an actual implicit conversion. As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`. There are potentially some more implicit conversions to be warned about. Namely, implicit conversions that result in sign change; implicit conversion between different floating point types, or between fp and an integer, when again, that conversion is lossy. One thing i know isn't handled is bitfields. This is a clang part. The compiler-rt part is D48959. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions) Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane Reviewed By: rsmith, vsk, erichkeane Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48958 llvm-svn: 338288
2018-07-31 02:58:30 +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
API documentation which are up-to-date with the Subversion version of
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>`_.