attribute syntax. There's nothing generalized about this; it's one of
several first-class attribute syntaxes we support, all of which are
more-or-less equally general.
As discussed on cfe-commits, we may want to revisit this if we start allowing
this syntax as an extension in C (or if C adopts the syntax), but hopefully
this diagnostic wording will be crystal clear to everyone in the mean time.
llvm-svn: 199443
Includes some style tweaks and removes the tautological observation that "Clang
is still under heavy development" -- it hopefully always will be.
llvm-svn: 199401
Also shuffle the Communication section so the bug tracker comes first.
(The sidebar isn't scrollable at the moment so this gives a better chance of
the bug tracker being seen. The links further down are basically invisible --
we should look into that.)
llvm-svn: 199398
not support as a possible reason for choosing GCC instead of Clang (and vice
versa). Weaken some of the claimed advantages of Clang in light of GCC
improvements.
llvm-svn: 196758
Use internal links to provide easier access to recent and ongoing work.
Also shift up the order of standards in the page title in order to avoid web
search results focusing on C++98 in the summary.
This is done to highlight the modern standards support in clang that was
previously languishing at the bottom of the page.
"C++98/03 is sooooo yesterday" - dgregor
llvm-svn: 196565
within their namespace, and such a redeclaration isn't required to be a
definition any more.
Update DR status page to say Clang 3.4 instead of SVN and add new Clang 3.5
category (but keep Clang 3.4 yellow for now).
llvm-svn: 196481
template, that member has a dependent type (even if we can see the definition
of the member of the primary template), because the array size could change in
a member specialization.
Patch by Karthik Bhat!
llvm-svn: 194740
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.
This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.
llvm-svn: 194055
tomorrow is complete.
There is a missing warning due to a serious issue with template
instantiation in Clang (and potentially in the core language).
llvm-svn: 191577
variable from being the function to being the enclosing namespace scope (in
C++) or the TU (in C). This allows us to fix a selection of related issues
where we would build incorrect redeclaration chains for such declarations, and
fail to notice type mismatches.
Such declarations are put into a new IdentifierNamespace, IDNS_LocalExtern,
which is only found when searching scopes, and not found when searching
DeclContexts. Such a declaration is only made visible in its DeclContext if
there are no non-LocalExtern declarations.
llvm-svn: 191064
This keeps the analyzer from making silly assumptions, like thinking
strlen(foo)+1 could wrap around to 0. This fixes PR16558.
Patch by Karthik Bhat!
llvm-svn: 188680
optimize, to follow the permissions granted in N3664. Under those rules, only
calls generated by new-expressions and delete-expressions are permitted to be
optimized, and direct calls to ::operator new and ::operator delete must be
treated as normal calls.
llvm-svn: 186799
A default template-argument shall not be specified in a friend template
declaration.
Interestingly, we properly handled default template arguments on friend
class members but not on just friend classes.
llvm-svn: 184882
The page is generated from a text file listing DR numbers and implementation
status, plus a copy of the cwg_index.html from the WG21 website. Recipe:
$ wget http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_index.html
$ ./make_cxx_dr_status >! cxx_dr_status.html
The intent here is to go through all the DRs, add tests for each one, then mark
them as done once such tests are committed and passing. I've not linked to this
page from anywhere, since it doesn't contain any useful information yet.
llvm-svn: 181967
- fix paper links to point to isocpp.org, where most of the papers are already up
- update "SVN" features to "Clang 3.3" to distinguish them from features which we
complete after the branch
- document use of -std=c++1y to enable c++1y support
llvm-svn: 181283
and mark "clarifying memory allocation" as done, since it turns out that our
optimizations here (such as they are) already conform to the new rules.
llvm-svn: 181110
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
- memory.MismatchedDelete, memory.MultipleDelete, and memory.DeallocateNonPtr
are complete (unix.MismatchedDeallocator and cplusplus.NewDelete)
- Per discussion on the mailing list, different.UnaryPlusWithUnsigned has
dubious value; remove it.
- Add potential checker ctordtor.PlacementSelfCopy per an internal bug report.
- core.AttributeNonNull is now core.NonNullParamChecker, though no one should
be depending on this name anyway.
llvm-svn: 179900
Also, add a few random extra open projects.
Most of C++ support is done; we don't need the status page anymore. We're
hoping that the C++-related open projects are the only major pieces of
functionality we don't model at this point.
llvm-svn: 179659
constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.
This completes our support for inheriting constructors.
llvm-svn: 179154
implement correct functionality, even if it's not optimal. On this basis, mark
"data dependency ordering" as done. Add footnotes for cases where our
implementation is known to be suboptimal.
llvm-svn: 176891
* Mark attributes as done in SVN.
* Downgrade alignment support from 'Clang 3.0' to 'SVN', now that we actually implement the rules.
* Upgrade 'Dynamic initialization with concurrency' from 'No' to 'Clang 2.9' -- all that is required here is the ABI-mandated locking for the initialization of static locals.
llvm-svn: 175882
* Mark 'sequence points' as done now we have a warning for unsequenced operations
* Mark 'memory model' as done now we correctly model bitfield operations
llvm-svn: 173771
libraries have an incorrect definition of std::common_type (inherited from a
bug in the standard -- see LWG issue 2141), whereby they produce reference
types when they should not.
If we instantiate a typedef named std::common_type<...>::type, which is defined
in a system header as decltype(... ? ... : ...), and the decltype produces a
reference type, convert it to the non-reference type. (This doesn't affect any
LWG2141-conforming implementation of common_type, such as libc++'s, because the
default implementation of common_type<...>::type isn't supposed to produce a
reference type.)
This is horrible. I'm really sorry. :( Better ideas appreciated!
llvm-svn: 166455
Richard Smith