2016-07-19 02:05:19 +08:00
|
|
|
=======================================
|
2018-01-03 23:49:39 +08:00
|
|
|
Clang 7.0.0 (In-Progress) Release Notes
|
2016-07-19 02:05:19 +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
|
|
|
|
|
|
|
|
|
|
Written by the `LLVM Team <http://llvm.org/>`_
|
|
|
|
|
|
|
|
|
|
.. warning::
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
These are in-progress notes for the upcoming Clang 7 release.
|
2017-02-10 07:26:34 +08:00
|
|
|
Release notes for previous releases can be found on
|
|
|
|
|
`the Download Page <http://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
|
2018-01-03 23:49:39 +08:00
|
|
|
frontend, part of the LLVM Compiler Infrastructure, release 7.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
|
|
|
|
|
documentation <http://llvm.org/docs/ReleaseNotes.html>`_. All LLVM
|
|
|
|
|
releases may be downloaded from the `LLVM releases web
|
|
|
|
|
site <http://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 <http://clang.llvm.org>`_ or the
|
|
|
|
|
`LLVM Web Site <http://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
|
|
|
|
|
|
|
|
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 <http://llvm.org/releases/>`_.
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
What's New in Clang 7.0.0?
|
2016-07-19 02:05:19 +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
|
|
|
|
|
------------------
|
|
|
|
|
|
[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
|
|
|
- A new Implicit Conversion Sanitizer (``-fsanitize=implicit-conversion``) group
|
|
|
|
|
was added. Please refer to the :ref:`release-notes-ubsan` section of the
|
|
|
|
|
release notes for the details.
|
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
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
|
2018-03-17 02:01:07 +08:00
|
|
|
- ``-Wc++98-compat-extra-semi`` is a new flag, which was previously inseparable
|
|
|
|
|
from ``-Wc++98-compat-pedantic``. The latter still controls the new flag.
|
|
|
|
|
|
|
|
|
|
- ``-Wextra-semi`` now also controls ``-Wc++98-compat-extra-semi``.
|
|
|
|
|
Please do note that if you pass ``-Wno-c++98-compat-pedantic``, it implies
|
|
|
|
|
``-Wno-c++98-compat-extra-semi``, so if you want that diagnostic, you need
|
|
|
|
|
to explicitly re-enable it (e.g. by appending ``-Wextra-semi``).
|
[Sema] -Wzero-as-null-pointer-constant: don't warn for system macros other than NULL.
Summary:
The warning was initially introduced in D32914 by @thakis,
and the concerns were raised there, and later in rL302247
and PR33771.
I do believe that it makes sense to relax the diagnostic
e.g. in this case, when the expression originates from the
system header, which can not be modified. This prevents
adoption for the diagnostic for codebases which use pthreads
(`PTHREAD_MUTEX_INITIALIZER`), gtest, etc.
As @malcolm.parsons suggests, it *may* make sense to also
not warn for the template types, but it is not obvious to
me how to do that in here.
Though, it still makes sense to complain about `NULL` macro.
While there, add more tests.
Reviewers: dblaikie, thakis, rsmith, rjmccall, aaron.ballman
Reviewed By: thakis
Subscribers: Rakete1111, hans, cfe-commits, thakis, malcolm.parsons
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38954
llvm-svn: 316662
2017-10-26 21:18:14 +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
|
|
|
- ``-Wself-assign`` and ``-Wself-assign-field`` were extended to diagnose
|
|
|
|
|
self-assignment operations using overloaded operators (i.e. classes).
|
|
|
|
|
If you are doing such an assignment intentionally, e.g. in a unit test for
|
[Sema] Add -Wno-self-assign-overloaded
Summary:
It seems there isn't much enthusiasm for `-wtest` D45685.
This is more conservative version, which i had in the very first
revision of D44883, but that 'erroneously' got removed because of the review.
**Based on some [irc] discussions, it must really be documented that
we want all the new diagnostics to have their own flags, to ease
rollouts, transitions, etc.**
Please do note that i'm only adding `-Wno-self-assign-overloaded`,
but not `-Wno-self-assign-field-overloaded`, because i'm honestly
not aware of any false-positives from the `-field` variant,
but i can just as easily add it if wanted.
https://reviews.llvm.org/D44883#1068561
Reviewers: dblaikie, aaron.ballman, thakis, rjmccall, rsmith
Reviewed By: dblaikie
Subscribers: Quuxplusone, chandlerc, cfe-commits
Differential Revision: https://reviews.llvm.org/D45766
llvm-svn: 330651
2018-04-24 05:35:21 +08:00
|
|
|
a data structure, the first warning can be disabled by passing
|
|
|
|
|
``-Wno-self-assign-overloaded``, also the warning can be suppressed by adding
|
|
|
|
|
``*&`` to the right-hand side or casting it to the appropriate reference type.
|
[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
|
|
|
|
|
-------------------------------------------------
|
|
|
|
|
|
2018-04-04 02:28:13 +08:00
|
|
|
- Clang binary and libraries have been renamed from 7.0 to 7.
|
|
|
|
|
For example, the ``clang`` binary will be called ``clang-7``
|
|
|
|
|
instead of ``clang-7.0``.
|
Rename clang link from clang-X.Y to clang-X
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
So, instead, I propose the following:
Instead of having clang-7.0 in bin/, we will have clang-7
Since also matches was gcc is doing.
Reviewers: tstellar, dlj, dim, hans
Reviewed By: dim, hans
Subscribers: dim, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41808
llvm-svn: 328769
2018-03-29 18:05:46 +08:00
|
|
|
|
2018-04-06 02:55:37 +08:00
|
|
|
- Clang implements a collection of recent fixes to the C++ standard's definition
|
|
|
|
|
of "standard-layout". In particular, a class is only considered to be
|
|
|
|
|
standard-layout if all base classes and the first data member (or bit-field)
|
|
|
|
|
can be laid out at offset zero.
|
|
|
|
|
|
2018-04-29 12:55:46 +08:00
|
|
|
- Clang's handling of the GCC ``packed`` class attribute in C++ has been fixed
|
|
|
|
|
to apply only to non-static data members and not to base classes. This fixes
|
|
|
|
|
an ABI difference between Clang and GCC, but creates an ABI difference between
|
|
|
|
|
Clang 7 and earlier versions. The old behavior can be restored by setting
|
|
|
|
|
``-fclang-abi-compat`` to ``6`` or earlier.
|
|
|
|
|
|
2018-05-07 14:43:30 +08:00
|
|
|
- Clang implements the proposed resolution of LWG issue 2358, along with the
|
|
|
|
|
`corresponding change to the Itanium C++ ABI
|
|
|
|
|
<https://github.com/itanium-cxx-abi/cxx-abi/pull/51>`_, which make classes
|
|
|
|
|
containing only unnamed non-zero-length bit-fields be considered non-empty.
|
|
|
|
|
This is an ABI break compared to prior Clang releases, but makes Clang
|
|
|
|
|
generate code that is ABI-compatible with other compilers. The old
|
|
|
|
|
behavior can be restored by setting ``-fclang-abi-compat`` to ``6`` or
|
|
|
|
|
lower.
|
|
|
|
|
|
2018-05-16 18:23:25 +08:00
|
|
|
- An existing tool named ``diagtool`` has been added to the release. As the
|
|
|
|
|
name suggests, it helps with dealing with diagnostics in ``clang``, such as
|
|
|
|
|
finding out the warning hierarchy, and which of them are enabled by default
|
|
|
|
|
or for a particular compiler invocation.
|
|
|
|
|
|
2018-07-18 08:27:07 +08:00
|
|
|
- By default, Clang emits an address-significance table into
|
|
|
|
|
every ELF object file when using the integrated assembler.
|
|
|
|
|
Address-significance tables allow linkers to implement `safe ICF
|
|
|
|
|
<https://research.google.com/pubs/archive/36912.pdf>`_ without the false
|
|
|
|
|
positives that can result from other implementation techniques such as
|
|
|
|
|
relocation scanning. The ``-faddrsig`` and ``-fno-addrsig`` flags can be
|
|
|
|
|
used to control whether to emit the address-significance table.
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
2017-12-15 03:22:02 +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
|
|
|
|
|
------------------
|
|
|
|
|
|
2018-06-28 20:05:40 +08:00
|
|
|
- ``-fstrict-float-cast-overflow`` and ``-fno-strict-float-cast-overflow``.
|
2018-05-16 05:45:01 +08:00
|
|
|
|
|
|
|
|
When a floating-point value is not representable in a destination integer
|
|
|
|
|
type, the code has undefined behavior according to the language standard. By
|
|
|
|
|
default, Clang will not guarantee any particular result in that case. With the
|
|
|
|
|
'no-strict' option, Clang attempts to match the overflowing behavior of the
|
|
|
|
|
target's native float-to-int conversion instructions.
|
2018-04-28 00:21:22 +08:00
|
|
|
|
2018-06-28 20:05:40 +08:00
|
|
|
- ``-fforce-emit-vtables`` and ``-fno-force-emit-vtables``.
|
2018-06-13 21:55:42 +08:00
|
|
|
|
|
|
|
|
In order to improve devirtualization, forces emitting of vtables even in
|
|
|
|
|
modules where it isn't necessary. It causes more inline virtual functions
|
|
|
|
|
to be emitted.
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
2017-10-22 00:45:08 +08:00
|
|
|
|
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
|
|
|
|
|
-----------------------
|
|
|
|
|
|
2018-04-04 17:38:22 +08:00
|
|
|
- Before Clang 7, we prepended the `#` character to the `--autocomplete`
|
2018-03-08 09:37:39 +08:00
|
|
|
argument to enable cc1 flags. For example, when the `-cc1` or `-Xclang` flag
|
|
|
|
|
is in the :program:`clang` invocation, the shell executed
|
2018-04-04 17:38:22 +08:00
|
|
|
`clang --autocomplete=#-<flag to be completed>`. Clang 7 now requires the
|
2018-03-08 09:37:39 +08:00
|
|
|
whole invocation including all flags to be passed to the `--autocomplete` like
|
|
|
|
|
this: `clang --autocomplete=-cc1,-xc++,-fsyn`.
|
2018-03-07 19:34:02 +08:00
|
|
|
|
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
|
|
|
|
2014-08-23 05:59:11 +08:00
|
|
|
Clang now supports the ...
|
2016-07-19 01:19:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Attribute Changes in Clang
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2018-01-09 07:36:29 +08:00
|
|
|
- Clang now supports function multiversioning with attribute 'target' on ELF
|
|
|
|
|
based x86/x86-64 environments by using indirect functions. This implementation
|
|
|
|
|
has a few minor limitations over the GCC implementation for the sake of AST
|
|
|
|
|
sanity, however it is otherwise compatible with existing code using this
|
|
|
|
|
feature for GCC. Consult the documentation for the target attribute for more
|
|
|
|
|
information.
|
2018-03-08 09:37:39 +08:00
|
|
|
|
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
|
|
|
|
|
---------------
|
|
|
|
|
|
2018-07-18 19:55:03 +08:00
|
|
|
- clang-cl's support for precompiled headers has been much improved:
|
|
|
|
|
|
|
|
|
|
- When using a pch file, clang-cl now no longer redundantly emits inline
|
|
|
|
|
methods that are already stored in the obj that was built together with
|
|
|
|
|
the pch file (matching cl.exe). This speeds up builds using pch files
|
|
|
|
|
by around 30%.
|
|
|
|
|
|
2018-07-21 05:06:41 +08:00
|
|
|
- The /Ycfoo.h and /Yufoo.h flags can now be used without /FIfoo.h when
|
2018-07-18 19:55:03 +08:00
|
|
|
foo.h is instead included by an explicit `#include` directive. This means
|
|
|
|
|
Visual Studio's default stdafx.h setup now uses precompiled headers with
|
|
|
|
|
clang-cl.
|
|
|
|
|
|
|
|
|
|
- ...
|
2014-08-05 08:21:23 +08:00
|
|
|
|
|
|
|
|
|
2013-12-13 17:27:34 +08:00
|
|
|
C Language Changes in Clang
|
|
|
|
|
---------------------------
|
|
|
|
|
|
2016-07-19 02:05:19 +08:00
|
|
|
- ...
|
2016-06-22 00:09:30 +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
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
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
|
|
|
|
2016-05-31 19:17:08 +08:00
|
|
|
OpenMP Support in Clang
|
|
|
|
|
----------------------------------
|
|
|
|
|
|
2018-07-27 01:53:45 +08:00
|
|
|
- Clang gained basic support for OpenMP 4.5 offloading for NVPTX target.
|
|
|
|
|
To compile your program for NVPTX target use the following options:
|
|
|
|
|
`-fopenmp -fopenmp-targets=nvptx64-nvidia-cuda` for 64 bit platforms or
|
|
|
|
|
`-fopenmp -fopenmp-targets=nvptx-nvidia-cuda` for 32 bit platform.
|
|
|
|
|
|
|
|
|
|
- Passing options to the OpenMP device offloading toolchain can be done using
|
|
|
|
|
the `-Xopenmp-target=<triple> -opt=val` flag. In this way the `-opt=val`
|
|
|
|
|
option will be forwarded to the respective OpenMP device offloading toolchain
|
|
|
|
|
described by the triple. For example passing the compute capability to
|
|
|
|
|
the OpenMP NVPTX offloading toolchain can be done as follows:
|
2018-07-27 02:40:41 +08:00
|
|
|
`-Xopenmp-target=nvptx64-nvidia-cuda -march=sm_60`. For the case when only one
|
2018-07-27 01:53:45 +08:00
|
|
|
target offload toolchain is specified under the `-fopenmp-targets=<triples>`
|
|
|
|
|
option, then the triple can be skipped: `-Xopenmp-target -march=sm_60`.
|
|
|
|
|
|
|
|
|
|
- Other bugfixes.
|
2016-05-31 19:17:08 +08:00
|
|
|
|
2018-04-20 21:04:54 +08:00
|
|
|
CUDA Support in Clang
|
|
|
|
|
---------------------
|
|
|
|
|
|
|
|
|
|
- Clang will now try to locate the CUDA installation next to :program:`ptxas`
|
|
|
|
|
in the `PATH` environment variable. This behavior can be turned off by passing
|
|
|
|
|
the new flag `--cuda-path-ignore-env`.
|
|
|
|
|
|
|
|
|
|
- Clang now supports generating object files with relocatable device code. This
|
|
|
|
|
feature needs to be enabled with `-fcuda-rdc` and my result in performance
|
|
|
|
|
penalties compared to whole program compilation. Please note that NVIDIA's
|
|
|
|
|
:program:`nvcc` must be used for linking.
|
|
|
|
|
|
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
|
|
|
|
|
--------------------
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
These are major API changes that have happened since the 6.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.
|
|
|
|
|
|
2016-07-28 07:01:55 +08:00
|
|
|
- ...
|
2015-05-14 08:22:12 +08:00
|
|
|
|
2015-09-17 21:47:22 +08:00
|
|
|
AST Matchers
|
|
|
|
|
------------
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
2017-03-14 17:43:55 +08:00
|
|
|
|
|
|
|
|
clang-format
|
|
|
|
|
------------
|
|
|
|
|
|
2018-05-08 17:25:12 +08:00
|
|
|
- Clang-format will now support detecting and formatting code snippets in raw
|
|
|
|
|
string literals. This is configured through the `RawStringFormats` style
|
|
|
|
|
option.
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
2017-12-05 17:23:47 +08:00
|
|
|
|
2013-04-24 15:33:52 +08:00
|
|
|
libclang
|
|
|
|
|
--------
|
|
|
|
|
|
2013-06-04 14:17:46 +08:00
|
|
|
...
|
2013-04-24 15:33:52 +08:00
|
|
|
|
2016-08-07 04:23:54 +08:00
|
|
|
|
2013-04-26 07:14:38 +08:00
|
|
|
Static Analyzer
|
2013-04-26 08:01:34 +08:00
|
|
|
---------------
|
|
|
|
|
|
2018-01-03 23:49:39 +08:00
|
|
|
- ...
|
2017-11-30 17:18:35 +08:00
|
|
|
|
2013-11-20 18:13:37 +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)
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
[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
|
|
|
* A new Implicit Conversion Sanitizer (``-fsanitize=implicit-conversion``) group
|
|
|
|
|
was added.
|
|
|
|
|
|
|
|
|
|
Currently, only one type of issues is caught - implicit integer truncation
|
|
|
|
|
(``-fsanitize=implicit-integer-truncation``), also known as integer demotion.
|
|
|
|
|
While there is a ``-Wconversion`` diagnostic group that catches this kind of
|
|
|
|
|
issues, it is both noisy, and does not catch **all** the cases.
|
|
|
|
|
|
|
|
|
|
.. code-block:: c++
|
|
|
|
|
|
|
|
|
|
unsigned char store = 0;
|
|
|
|
|
|
|
|
|
|
bool consume(unsigned int val);
|
|
|
|
|
|
|
|
|
|
void test(unsigned long val) {
|
|
|
|
|
if (consume(val)) // the value may have been silently truncated.
|
|
|
|
|
store = store + 768; // before addition, 'store' was promoted to int.
|
|
|
|
|
(void)consume((unsigned int)val); // OK, the truncation is explicit.
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Just like other ``-fsanitize=integer`` checks, these issues are **not**
|
|
|
|
|
undefined behaviour. But they are not *always* intentional, and are somewhat
|
|
|
|
|
hard to track down. This group is **not** enabled by ``-fsanitize=undefined``,
|
|
|
|
|
but the ``-fsanitize=implicit-integer-truncation`` check
|
|
|
|
|
is enabled by ``-fsanitize=integer``.
|
2017-06-13 10:52:31 +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
|
|
|
|
|
page <http://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
|
2015-08-05 11:55:23 +08:00
|
|
|
list <http://lists.llvm.org/mailman/listinfo/cfe-dev>`_.
|