| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 170987
|
|
|
|
| |
llvm-svn: 170309
|
|
|
|
| |
llvm-svn: 170294
|
|
|
|
| |
llvm-svn: 167479
|
|
|
|
| |
llvm-svn: 162636
|
|
|
|
| |
llvm-svn: 162102
|
|
|
|
| |
llvm-svn: 160169
|
|
|
|
|
|
|
|
|
|
|
| |
Chris pointed out that while the comparison is certainly problematic
and does not have well-defined behavior, it isn't any worse than some
of the other abuses that we merely warn about and doesn't need to make
the compilation fail.
Revert the release notes change (r159766) now that this is just a new warning.
llvm-svn: 159939
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This may turn out to be a controversial change, due to string literals being
uniqued at link time, but Apple's docs only say "The compiler makes such
object constants unique on a per-module basis..."[1] without actually saying
what a "module" is. (It's not a clang module.) Furthermore, this uniqueness
guarantee often can't be guaranteed once the string has been passed through
framework code.
If this does turn out very controversial, we could downgrade this to a
DefaultError warning for strings, and leave it as a true Error for other
kinds of literals.
(<rdar://problem/11300873>)
[1]: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/CreatingStrings.html
llvm-svn: 159766
|
|
|
|
| |
llvm-svn: 159249
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the tls_model attribute. This allows the user to
choose a TLS model that is better than what LLVM would select by
default. For example, a variable might be declared as:
__thread int x __attribute__((tls_model("initial-exec")));
if it will not be used in a shared library that is dlopen'ed.
This depends on LLVM r159077.
llvm-svn: 159078
|
|
|
|
| |
llvm-svn: 158989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wsometimes-uninitialized diagnostics to make it clearer that the cause
of the issue may be a condition which must always evaluate to true or
false, rather than an uninitialized variable.
To emphasize this, add a new note with a fixit which removes the
impossible condition or replaces it with a constant.
Also, downgrade the diagnostic from -Wsometimes-uninitialized to
-Wconditional-uninitialized when it applies to a range-based for loop,
since the condition is not written explicitly in the code in that case.
llvm-svn: 157511
|
|
|
|
| |
llvm-svn: 157459
|
|
|
|
| |
llvm-svn: 157379
|
|
|
|
| |
llvm-svn: 156820
|
|
|
|
| |
llvm-svn: 156721
|
|
|
|
| |
llvm-svn: 155681
|
|
|
|
|
|
| |
Thanks to Nico Weber for the suggestion.
llvm-svn: 154648
|
|
|
|
| |
llvm-svn: 154071
|
|
|
|
| |
llvm-svn: 154012
|
|
|
|
|
|
|
|
| |
between unscoped enumerations and class template member specializations,
whose behavior is currently under discussion in CWG (and for which there
is a preference to not implement the currently-standardized wording).
llvm-svn: 153464
|
|
|
|
|
|
| |
forward-declared enums aren't /quite/ done yet.
llvm-svn: 153350
|
|
|
|
|
|
|
| |
a previous declaration if the redeclaration is invalid. That way lies madness.
Fixes a crash-on-invalid reported by Abramo.
llvm-svn: 153349
|
|
|
|
| |
llvm-svn: 152424
|
|
|
|
| |
llvm-svn: 151992
|
|
|
|
| |
llvm-svn: 151978
|
|
|
|
|
|
| |
generalized initializers is available.
llvm-svn: 151477
|
|
|
|
| |
llvm-svn: 151264
|
|
|
|
| |
llvm-svn: 151263
|
|
|
|
| |
llvm-svn: 150879
|
|
|
|
| |
llvm-svn: 150656
|
|
|
|
|
|
| |
and unions, and C++11 generalized constant expressions.
llvm-svn: 150640
|
|
|
|
| |
llvm-svn: 148219
|
|
|
|
| |
llvm-svn: 145360
|
|
|
|
| |
llvm-svn: 145359
|
|
|
|
|
|
| |
formatting here a bit... mostly to my preferred bikeshed-blue.
llvm-svn: 145337
|
|
|
|
|
|
|
|
|
|
|
| |
the release notes despite their awesomeness. If we had a thorough
discussion of the performance of Clang in 2.9 vs. 3.0, the first would
be more relevant, but we don't. The serialization stuff hopefully isn't
terribly visible to end users.
Objections to these omissions are of course welcome. =]
llvm-svn: 145336
|
|
|
|
|
|
|
| |
extensions and one infrastructure feature addition that has a direct
impact on other projects which use Clang.
llvm-svn: 145335
|
|
|
|
| |
llvm-svn: 145334
|
|
|
|
|
|
| |
from the Objective-C experts, but the basic stuff is there now.
llvm-svn: 145333
|
|
|
|
| |
llvm-svn: 145325
|
|
|
|
|
|
| |
I think that's enough for my release notes.
llvm-svn: 145320
|
|
|
|
| |
llvm-svn: 145317
|
|
|
|
| |
llvm-svn: 145315
|
|
|
|
| |
llvm-svn: 145311
|
|
|
|
|
|
|
|
| |
accurate than my original notes were based on IRC conversations. Windows
folks, please edit as needed to make this closer to the truth if I've
still got it wrong.
llvm-svn: 145309
|
|
|
|
| |
llvm-svn: 145308
|
|
|
|
|
|
|
| |
add a bit to that section about the many bug-finding warnings that Clang
has grown since 2.9 as this is one of the more visible new additions.
llvm-svn: 145307
|