Fix the explanation of how to run tests after migration
from autotools to cmake.
Significantly expand the "debugging" section
with more interesting stuff.
Update the table of contents accordingly.
Fix paragraphs in the overview section.
Differential Revision: https://reviews.llvm.org/D22874
llvm-svn: 277029
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
compiler-rt is optional. We often get email from users with compiler-rt
build errors who don't actually need compiler-rt. Marking it optional
should help them avoid those potential problems.
While I'm here, update a reference to the build directory and remove an
obsolete reference to llvm-gcc. Nobody today is under the impression
that Clang depends on GCC.
llvm-svn: 265963
This is the clang equivalent to llvm commit 264601. When using Visual Studio 2015, cmake now puts the native visualizers in llvm.sln, so the developer automatically sees custom visualizations.
Much thanks to ariccio who provided extensive help on this change. (manual installation still needed on VS2013).
llvm-svn: 264603
Implement lambda capture of *this by copy.
For e.g.:
struct A {
int d = 10;
auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; }
};
auto L = A{}.foo(); // A{}'s lifetime is gone.
// Below is still ok, because *this was captured by value.
assert(L(10) == 20);
assert(L(100) == 120);
If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined.
Implementation Strategy:
- amend the parser to accept *this in the lambda introducer
- add a new king of capture LCK_StarThis
- teach Sema::CheckCXXThisCapture to handle by copy captures of the
enclosing object (i.e. *this)
- when CheckCXXThisCapture does capture by copy, the corresponding
initializer expression for the closure's data member
direct-initializes it thus making a copy of '*this'.
- in codegen, when assigning to CXXThisValue, if *this was captured by
copy, make sure it points to the corresponding field member, and
not, unlike when captured by reference, what the field member points
to.
- mark feature as implemented in svn
Much gratitude to Richard Smith for his carefully illuminating reviews!
llvm-svn: 263921
exactly the same as clang's existing [[clang::fallthrough]] attribute, which
has been updated to have the same semantics. The one significant difference
is that [[fallthrough]] is ill-formed if it's not used immediately before a
switch label (even when -Wimplicit-fallthrough is disabled). To support that,
we now build a CFG of any function that uses a '[[fallthrough]];' statement
to check.
In passing, fix some bugs with our support for statement attributes -- in
particular, diagnose their use on declarations, rather than asserting.
llvm-svn: 262881
C++11 requires const objects to have a user-provided constructor, even for
classes without any fields. DR 253 relaxes this to say "If the implicit default
constructor initializes all subobjects, no initializer should be required."
clang is currently the only compiler that implements this C++11 rule, and e.g.
libstdc++ relies on something like DR 253 to compile in newer versions. This
change makes it possible to build code that says `const vector<int> v;' again
when using libstdc++5.2 and _GLIBCXX_DEBUG
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284).
Fixes PR23381.
http://reviews.llvm.org/D16552
llvm-svn: 261297
to force debug build and hopefully enable more precise warnings.
Static Analyzer is much more efficient when built in debug mode
(-UNDEBUG) so we advice users to enable it manually. This may be
inconvenient in case of large complex projects (think about Linux
distros e.g. Android or Tizen). This patch adds a flag to scan-build
which inserts -UNDEBUG automatically.
Differential Revision: http://reviews.llvm.org/D16200
llvm-svn: 261204
We will still allow it in system headers, in macros from system headers, when
combined with an 'asm' label, and under the flag -Wno-register.
llvm-svn: 254097
DR407, the C++ standard doesn't really say how this should work. Here's what we
do (which is consistent with DR407 as far as I can tell):
* When performing name lookup for an elaborated-type-specifier, a tag
declaration hides a typedef declaration that names the same type.
* When performing any other kind of lookup, a typedef declaration hides
a tag declaration that names the same type.
In any other case where lookup finds both a typedef and a tag (that is, when
they name different types), the lookup will be ambiguous. If lookup finds a
tag and a typedef that name the same type, and finds anything else, the lookup
will always be ambiguous (even if the other entity would hide the tag, it does
not also hide the typedef).
llvm-svn: 252959
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
DXR is a project developed at Mozilla that implements a code indexing
and browsing utility on top of libclang that has features such as
call graph querying.
llvm-svn: 251638
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
201501) to indicate that the feature is enabled, but the
implementation is incomplete.
The link to the Concepts TS in cxx_status is updated to refer to the
PDTS (N4377). Additional changes related to __has_feature and
__has_extension are to follow in a later change.
Relevant tests include:
test/Lexer/cxx-features.cpp
The test file is updated with testing of the C++14 + Concepts TS mode.
The expected behaviour is the same as that of the C++14 modes except
for the case of __cpp_experimental_concepts."
- Hubert Tong.
Being committed for Hubert (as per his understanding with Richard Smith) as we start work on the concepts-ts following our preliminary strategy session earlier today.
The patch is tiny and seems quite standard.
Thanks Hubert!
llvm-svn: 237982
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
Reviewers: rsmith, rjmccall
Differential Revision: http://reviews.llvm.org/D8467
llvm-svn: 232788
Still yellow because 3.6 is unreleased. While there make Urbana paper
links clickable and list binary literals as available in Clang 2.9
(they've been available basically since the dawn of Clang, but not
having a version number in the table looks weird)
llvm-svn: 228571
selects a deleted function, the outer function is still a candidate even though
the initialization sequence is "otherwise ill-formed".
llvm-svn: 227169
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
This allows 'namespace A::B { ... }' as a shorthand for 'namespace A {
namespace B { ... } }'. We already supported this correctly for error recovery;
promote that support to a full implementation.
This is not the right implementation: we do not maintain source fidelity
because we desugar the nested namespace definition in the parser. This is
tricky to avoid, since the definition genuinely does inject one named
entity per level in the namespace name.
llvm-svn: 221574
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
use __thiscall. (This doesn't actually work for MSVC; they don't allow the
__thiscall qualifier here, but it's sufficient to demonstrate that we do
implement the intent of the DR.)
llvm-svn: 217213
1. Having "get started", "get involved", and "hacking" makes it hard to find
how to send patches, so add a link from "get involved" to "hacking".
2. Remove an almost 5 year old note on the test running meachanism changing
soon.
3. Let "hacking" link to the LLVM developer policy.
llvm-svn: 210826
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
llvm-svn: 210091
Summary:
Naming the destructor using a typedef-name for the class-name is
well-formed.
This fixes PR19620.
Reviewers: rsmith, doug.gregor
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3583
llvm-svn: 209319
The list of alpha and the list of implicit checkers added. An ability to expand/collapse long texts added. Markup fixed.
http://reviews.llvm.org/D3457
llvm-svn: 209131
This minified source code and artwork is copied from a commercial product and
carries no license information:
dbtree.js (7 kb), 25.03.2014 14:51:32
Purchase and download DBTree now for only $29.75 $9.75
It was used by a small TOC which looks fine now as a plain unordered list.
llvm-svn: 207995
* It is better if we leave third parties to do "independent" benchmark.
* We compare Clang (version unspecified) with gcc 4.0 or 4.2.
* The graphs have not been updated for a while.
* Clang is well known now. I don't think we still need to explain why
Clang is great.
llvm-svn: 207358
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4. The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
(for an integer too large for any signed type) from Warning to ExtWarn -- it's
ill-formed in C++11 and C99 onwards, and UB during translation in C89 and
C++98. Add diagnostic groups for two relevant diagnostics.
llvm-svn: 203974
* Explicitly say that we conform to the two N/A bullets that required no
compiler changes.
* Remove a library feature from our features list.
llvm-svn: 203964
using-declaration, and they declare the same function (either because
the using-declaration is in the same namespace as the declaration it
imports, or because they're both extern "C"), they do not conflict.
llvm-svn: 200897
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
structure of how we're building concrete tools as well as tooling
infrastructure as part of the Clang project.
This documentation is definitely still rough. If anyone can improve it,
flesh it out, or help structure it in a more natural way, please, help!
=] This is not my forte, and patches here are more than welcome!
llvm-svn: 161855
Devin Coughlin