2019-07-18 19:51:05 +08:00
|
|
|
========================================
|
2020-01-15 17:02:56 +08:00
|
|
|
Clang 11.0.0 (In-Progress) Release Notes
|
2019-07-18 19:51:05 +08:00
|
|
|
========================================
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
:local:
|
|
|
|
|
:depth: 2
|
|
|
|
|
|
2018-09-10 16:51:25 +08:00
|
|
|
Written by the `LLVM Team <https://llvm.org/>`_
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
These are in-progress notes for the upcoming Clang 11 release.
|
2017-02-10 07:26:34 +08:00
|
|
|
Release notes for previous releases can be found on
|
2018-09-10 16:51:25 +08:00
|
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
This document contains the release notes for the Clang C/C++/Objective-C
|
2020-01-15 17:02:56 +08:00
|
|
|
frontend, part of the LLVM Compiler Infrastructure, release 11.0.0. Here we
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +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
|
2018-09-10 16:51:25 +08:00
|
|
|
documentation <https://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
releases may be downloaded from the `LLVM releases web
|
2018-09-10 16:51:25 +08:00
|
|
|
site <https://llvm.org/releases/>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
2017-08-31 02:35:44 +08:00
|
|
|
For more information about Clang or LLVM, including information about the
|
2018-09-10 16:51:25 +08:00
|
|
|
latest release, please see the `Clang Web Site <https://clang.llvm.org>`_ or the
|
|
|
|
|
`LLVM Web Site <https://llvm.org>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
Note that if you are reading this file from a Git checkout or the
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
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
|
2018-09-10 16:51:25 +08:00
|
|
|
see the `releases page <https://llvm.org/releases/>`_.
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
What's New in Clang 11.0.0?
|
2019-07-18 19:51:05 +08:00
|
|
|
===========================
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +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
|
|
|
|
|
------------------
|
|
|
|
|
|
2019-01-16 18:57:02 +08:00
|
|
|
- ...
|
2013-12-13 00:07:11 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
Improvements to Clang's diagnostics
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
- ...
|
[Sema] Extend -Wself-assign and -Wself-assign-field to warn on overloaded self-assignment (classes)
Summary:
This has just bit me, so i though it would be nice to avoid that next time :)
Motivational case:
https://godbolt.org/g/cq9UNk
Basically, it's likely to happen if you don't like shadowing issues,
and use `-Wshadow` and friends. And it won't be diagnosed by clang.
The reason is, these self-assign diagnostics only work for builtin assignment
operators. Which makes sense, one could have a very special operator=,
that does something unusual in case of self-assignment,
so it may make sense to not warn on that.
But while it may be intentional in some cases, it may be a bug in other cases,
so it would be really great to have some diagnostic about it...
Reviewers: aaron.ballman, rsmith, rtrieu, nikola, rjmccall, dblaikie
Reviewed By: rjmccall
Subscribers: EricWF, lebedev.ri, thakis, Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D44883
llvm-svn: 329493
2018-04-07 18:39:21 +08:00
|
|
|
|
2017-07-27 02:04:45 +08:00
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
|
-------------------------------------------------
|
|
|
|
|
|
2019-12-13 02:49:46 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
New Compiler Flags
|
|
|
|
|
------------------
|
|
|
|
|
|
2019-11-05 02:20:00 +08:00
|
|
|
|
2019-09-09 22:59:34 +08:00
|
|
|
- -fstack-clash-protection will provide a protection against the stack clash
|
|
|
|
|
attack for x86 architecture through automatic probing of each page of
|
|
|
|
|
allocated stack.
|
|
|
|
|
|
2017-07-02 05:36:21 +08:00
|
|
|
Deprecated Compiler Flags
|
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
|
|
The following options are deprecated and ignored. They will be removed in
|
|
|
|
|
future versions of Clang.
|
|
|
|
|
|
2017-07-19 22:14:07 +08:00
|
|
|
- ...
|
2017-07-02 05:36:21 +08:00
|
|
|
|
2018-03-07 19:34:02 +08:00
|
|
|
Modified Compiler Flags
|
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
|
|
|
2014-06-18 08:51:32 +08:00
|
|
|
New Pragmas in Clang
|
2018-05-16 05:45:01 +08:00
|
|
|
--------------------
|
2014-06-18 08:51:32 +08:00
|
|
|
|
2019-01-16 18:57:02 +08:00
|
|
|
- ...
|
2016-07-19 01:19:12 +08:00
|
|
|
|
|
|
|
|
Attribute Changes in Clang
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2017-07-19 22:14:07 +08:00
|
|
|
- ...
|
2014-07-22 02:08:34 +08:00
|
|
|
|
2014-08-05 08:21:23 +08:00
|
|
|
Windows Support
|
|
|
|
|
---------------
|
|
|
|
|
|
2013-12-13 17:27:34 +08:00
|
|
|
C Language Changes in Clang
|
|
|
|
|
---------------------------
|
|
|
|
|
|
2019-06-05 11:47:02 +08:00
|
|
|
- ...
|
2013-12-13 17:27:34 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
C11 Feature Support
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
C++ Language Changes in Clang
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2020-02-06 10:52:38 +08:00
|
|
|
- Clang now implements a restriction on giving non-C-compatible anonymous
|
|
|
|
|
structs a typedef name for linkage purposes, as described in C++ committee
|
|
|
|
|
paper `P1766R1 <http://wg21.link/p1766r1>`. This paper was adopted by the
|
|
|
|
|
C++ committee as a Defect Report resolution, so it is applied retroactively
|
|
|
|
|
to all C++ standard versions. This affects code such as:
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
int f() { return 0; }
|
|
|
|
|
} S;
|
|
|
|
|
|
|
|
|
|
Previous versions of Clang rejected some constructs of this form
|
|
|
|
|
(specifically, where the linkage of the type happened to be computed
|
|
|
|
|
before the parser reached the typedef name); those cases are still rejected
|
|
|
|
|
in Clang 11. In addition, cases that previous versions of Clang did not
|
|
|
|
|
reject now produce an extension warning. This warning can be disabled with
|
|
|
|
|
the warning flag ``-Wno-non-c-typedef-for-linkage``.
|
|
|
|
|
|
|
|
|
|
Affected code should be updated to provide a tag name for the anonymous
|
|
|
|
|
struct:
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
struct S {
|
|
|
|
|
int f() { return 0; }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
If the code is shared with a C compilation (for example, if the parts that
|
|
|
|
|
are not C-compatible are guarded with ``#ifdef __cplusplus``), the typedef
|
|
|
|
|
declaration should be retained, but a tag name should still be provided:
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
typedef struct S {
|
|
|
|
|
int f() { return 0; }
|
|
|
|
|
} S;
|
2016-05-06 02:40:37 +08:00
|
|
|
|
|
|
|
|
C++1z Feature Support
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
Objective-C Language Changes in Clang
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
|
2013-11-11 14:36:33 +08:00
|
|
|
OpenCL C Language Changes in Clang
|
|
|
|
|
----------------------------------
|
|
|
|
|
|
2013-11-20 18:13:37 +08:00
|
|
|
...
|
2013-11-11 14:36:33 +08:00
|
|
|
|
2018-10-27 03:26:45 +08:00
|
|
|
ABI Changes in Clang
|
|
|
|
|
--------------------
|
|
|
|
|
|
[RISCV] Match GCC `-march`/`-mabi` driver defaults
Summary:
Clang/LLVM is a cross-compiler, and so we don't have to make a choice
about `-march`/`-mabi` at build-time, but we may have to compute a
default `-march`/`-mabi` when compiling a program. Until now, each
place that has needed a default `-march` has calculated one itself.
This patch adds a single place where a default `-march` is calculated,
in order to avoid calculating different defaults in different places.
This patch adds a new function `riscv::getRISCVArch` which encapsulates
this logic based on GCC's for computing a default `-march` value
when none is provided. This patch also updates the logic in
`riscv::getRISCVABI` to match the logic in GCC's build system for
computing a default `-mabi`.
This patch also updates anywhere that `-march` is used to now use the
new function which can compute a default. In particular, we now
explicitly pass a `-march` value down to the gnu assembler.
GCC has convoluted logic in its build system to choose a default
`-march`/`-mabi` based on build options, which would be good to match.
This patch is based on the logic in GCC 9.2.0. This commit's logic is
different to GCC's only for baremetal targets, where we default
to rv32imac/ilp32 or rv64imac/lp64 depending on the target triple.
Tests have been updated to match the new logic.
Reviewers: asb, luismarques, rogfer01, kito-cheng, khchen
Reviewed By: asb, luismarques
Subscribers: sameer.abuasal, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69383
2019-11-15 23:10:02 +08:00
|
|
|
|
2016-05-31 19:17:08 +08:00
|
|
|
OpenMP Support in Clang
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
-----------------------
|
2016-05-31 19:17:08 +08:00
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2016-05-31 19:17:08 +08:00
|
|
|
|
2018-04-20 21:04:54 +08:00
|
|
|
CUDA Support in Clang
|
|
|
|
|
---------------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2018-04-20 21:04:54 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
Internal API Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
These are major API changes that have happened since the 10.0.0 release of
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
Clang. If upgrading an external codebase that uses Clang as a library,
|
|
|
|
|
this section should help get you past the largest hurdles of upgrading.
|
|
|
|
|
|
2019-08-30 17:29:34 +08:00
|
|
|
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
Build System Changes
|
|
|
|
|
--------------------
|
|
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
These are major changes to the build system that have happened since the 10.0.0
|
[build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
2019-03-05 05:19:53 +08:00
|
|
|
release of Clang. Users of the build system should adjust accordingly.
|
|
|
|
|
|
2019-08-15 00:49:52 +08:00
|
|
|
- ...
|
2015-05-14 08:22:12 +08:00
|
|
|
|
2015-09-17 21:47:22 +08:00
|
|
|
AST Matchers
|
|
|
|
|
------------
|
|
|
|
|
|
2019-03-23 06:47:34 +08:00
|
|
|
- ...
|
2017-03-14 17:43:55 +08:00
|
|
|
|
|
|
|
|
clang-format
|
|
|
|
|
------------
|
|
|
|
|
|
2019-11-19 16:34:23 +08:00
|
|
|
|
2020-01-19 23:52:26 +08:00
|
|
|
- Option ``IndentCaseBlocks`` has been added to support treating the block
|
|
|
|
|
following a switch case label as a scope block which gets indented itself.
|
|
|
|
|
It helps avoid having the closing bracket align with the switch statement's
|
|
|
|
|
closing bracket (when ``IndentCaseLabels`` is ``false``).
|
|
|
|
|
|
[clang-format] Add option for not breaking line before ObjC params
Summary:
From `clang-format` version 3.7.0 and up, , there is no way to keep following format of ObjectiveC block:
```
- (void)_aMethod
{
[self.test1 t:self w:self callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
u = c;
}]
}
```
Regardless of the change in `.clang-format` configuration file, all parameters will be lined up so that colons will be on the same column, like following:
```
- (void)_aMethod
{
[self.test1 t:self
w:self
callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
u = c;
}]
}
```
Considering with ObjectiveC, the first code style is cleaner & more readable for some people, I've added a config option: `ObjCDontBreakBeforeNestedBlockParam` (boolean) so that if it is enable, the first code style will be favored.
Reviewed By: MyDeveloperDay
Patch By: ghvg1313
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D70926
2020-02-02 01:37:25 +08:00
|
|
|
- Option ``ObjCBreakBeforeNestedBlockParam`` has been added to optionally apply
|
|
|
|
|
linebreaks for function arguments declarations before nested blocks.
|
|
|
|
|
|
2020-01-19 23:52:26 +08:00
|
|
|
.. code-block:: c++
|
[clang-format] Add option for not breaking line before ObjC params
Summary:
From `clang-format` version 3.7.0 and up, , there is no way to keep following format of ObjectiveC block:
```
- (void)_aMethod
{
[self.test1 t:self w:self callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
u = c;
}]
}
```
Regardless of the change in `.clang-format` configuration file, all parameters will be lined up so that colons will be on the same column, like following:
```
- (void)_aMethod
{
[self.test1 t:self
w:self
callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
u = c;
}]
}
```
Considering with ObjectiveC, the first code style is cleaner & more readable for some people, I've added a config option: `ObjCDontBreakBeforeNestedBlockParam` (boolean) so that if it is enable, the first code style will be favored.
Reviewed By: MyDeveloperDay
Patch By: ghvg1313
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D70926
2020-02-02 01:37:25 +08:00
|
|
|
|
2020-01-19 23:52:26 +08:00
|
|
|
switch (fool) { vs. switch (fool) {
|
|
|
|
|
case 1: case 1: {
|
|
|
|
|
{ bar();
|
|
|
|
|
bar(); } break;
|
|
|
|
|
} default: {
|
|
|
|
|
break; plop();
|
|
|
|
|
default: }
|
|
|
|
|
{ }
|
|
|
|
|
plop();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-31 17:23:02 +08:00
|
|
|
- Option ``InsertTrailingCommas`` can be set to ``TCS_Wrapped`` to insert
|
|
|
|
|
trailing commas in container literals (arrays and objects) that wrap across
|
|
|
|
|
multiple lines. It is currently only available for JavaScript and disabled by
|
|
|
|
|
default (``TCS_None``).
|
|
|
|
|
|
2013-04-24 15:33:52 +08:00
|
|
|
libclang
|
|
|
|
|
--------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2013-04-24 15:33:52 +08:00
|
|
|
|
2013-04-26 07:14:38 +08:00
|
|
|
Static Analyzer
|
2013-04-26 08:01:34 +08:00
|
|
|
---------------
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
- ...
|
2013-04-26 08:01:34 +08:00
|
|
|
|
[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:
|
|
|
|
|
|
2017-06-13 10:52:31 +08:00
|
|
|
Undefined Behavior Sanitizer (UBSan)
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour
Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4 When an expression J that has integral type is added to or subtracted
from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
elements ([dcl.array]), the expressions P + J and J + P
(where J has the value j) point to the (possibly-hypothetical) array
element i+j of x if 0≤i+j≤n and the expression P - J points to the
(possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```
Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)
To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".
Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566
Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.
`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown
Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers
Reviewed By: rsmith
Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67122
llvm-svn: 374293
2019-10-10 17:25:02 +08:00
|
|
|
|
2013-04-26 08:01:34 +08:00
|
|
|
Core Analysis Improvements
|
|
|
|
|
==========================
|
2013-04-26 07:14:38 +08:00
|
|
|
|
2013-06-04 14:17:46 +08:00
|
|
|
- ...
|
2013-04-26 08:01:34 +08:00
|
|
|
|
|
|
|
|
New Issues Found
|
|
|
|
|
================
|
|
|
|
|
|
2013-06-04 14:17:46 +08:00
|
|
|
- ...
|
2013-04-26 07:14:38 +08:00
|
|
|
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
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
|
2018-09-10 16:51:25 +08:00
|
|
|
page <https://clang.llvm.org/>`_. The web page contains versions of the
|
docs: Convert ReleaseNotes to reST.
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
2012-12-23 09:19:35 +08:00
|
|
|
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
|
2018-09-10 16:51:25 +08:00
|
|
|
list <https://lists.llvm.org/mailman/listinfo/cfe-dev>`_.
|