<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
- Developers of system frameworks need a way for their framework to be treated as a "system framework" during development. Otherwise, they are unable to properly test how their framework behaves when installed because of the semantic changes (in warning behavior) applied to system frameworks.
llvm-svn: 154105
last N months. This required a brief soliloquy about change in
an uncertainly-versioned world.
I believe I've gotten the right target versions on all these changes.
llvm-svn: 153501
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
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
This option was added in r129614 and doesn't have any use case that I'm aware
of. It's possible that external tools are using these names - and if that's
the case we can certainly reassess the functionality, but for now it lets us
shave out a few unneeded bits from clang.
Move the "StaticDiagNameIndex" table into the only remaining consumer, diagtool.
This removes the actual diagnostic name strings from clang entirely.
Reviewed by Chris Lattner & Ted Kremenek.
llvm-svn: 150612
address safety analysis (such as e.g. AddressSanitizer or SAFECode) for a specific function.
When building with AddressSanitizer, add AddressSafety function attribute to every generated function
except for those that have __attribute__((no_address_safety_analysis)).
With this patch we will be able to
1. disable AddressSanitizer for a particular function
2. disable AddressSanitizer-hostile optimizations (such as some cases of load widening) when AddressSanitizer is on.
llvm-svn: 148842
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
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
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
stub for OpenCL work. I can't really dig enough out of the commit log
messages other than to tell that a lot of work went into this in the 2.9
-> 3.0 timeframe. I'll let the folks touching it decide if it merits
a spot in the release notes and provide the appropriate details if so.
llvm-svn: 145291
easier. Move the CUDA bits and the C1X/C++11 atomics stuff there. We
haven't exposed a __has_feature for the atomic builtins, so none of this
is available yet...
llvm-svn: 145288
The performance improvement was committed after the 3.0 branch.
Constructors/destructors are handled by the CFG, but we do not do anything
special for them in the analyzer yet.
Since we do not have an open source release qualification for the analyzer,
we are not investing into creating the proper release notes for it.
llvm-svn: 145281
worth noting in the release notes. These remain raw notes. I'll be
re-writing them into nice prose first thing tomorrow, with help from
others. A couple of notes for any reading the commits:
If you don't see something that should be mentioned, feel free to add
a note (or even a nicely written section) about it! I haven't really
done the static analyzer justice here as I don't really know what the
significant changes are other than mile-high stuff like watching it grow
C++ support and a more robust CFG. I also worry I've missed important
stuff in the Objective-C world.
If you see something that isn't worth mentioning, just delete it. I know
there are several things like this. I plan to prune the list down as
I flesh things out.
If you're name or email is on a bullet, I'll likely be sending you an
email asking for any input on that subject. For many of these I can fill
in something generic, and I'll just want you to give it a once-over.
However, if you have time, feel free to just write the blurb yourself
and drop it in, or drop it in an email to me.
Finally, *WOW* has a lot happened in Clang... I shouldn't have dreaded
(and put off) this so much, it was kind of awesome to go back and watch
the evolution. Anyways, these should be in a reasonable draft state
early tomorrow.
llvm-svn: 145247
these more detailed notes from the primary LLVM release notes for Clang.
This gives us a nice place to flesh out in plenty of detail the major
changes that have happened in Clang land since 2.9.
I've outlined a very rough structure based on the LLVM release notes
structure and what seems like useful divisions in the Clang landscape
(e.g., language-specific stuff is relevant to a narrower audience).
I'll be first converting my brain-dump-ish notes from the commit logs,
and then cleaning here. Suggestions on structure welcome. Typo
corrections, spelling fixes (oh how I'll need them), all welcome; just
commit away.
llvm-svn: 145233
- This disables the system include directories, but not the compiler builtin
directories. Useful for projects that want to use things like the intrinsic
headers, but are otherwise freestanding.
- I'm willing to reconsider the option naming, I also considered providing an
explicit -builtinc (which would match -nobuiltininc), but this is more
consistent with existing options.
llvm-svn: 141692
to operate "as if" in a certain working directory.
- For now, we just implement this by changing the actual working directory, but
eventually we would want to handle this transparently. This is useful to
avoid an extra exec() pair in some situations, and will be something we would
want to support for more flexibility in using the Clang libraries.
llvm-svn: 140409
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
This patch special cases the parser for thread safety attributes so that all
attribute arguments are put in the argument list (instead of a special
parameter) since arguments may not otherwise resolve correctly without two-token
lookahead.
This patch also adds checks to make sure that attribute arguments are
lockable objects.
llvm-svn: 137130
Introduce and document a new objc_returns_inner_pointer
attribute, and consume it by performing a retain+autorelease
on message receivers when they're not immediately loaded from
an object with precise lifetime.
llvm-svn: 135764
Patrick Beard