Moved UninitializedObjectChecker from the 'alpha.cplusplus' to the
'optin.cplusplus' package.
Differential Revision: https://reviews.llvm.org/D58573
llvm-svn: 358797
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
Summary:
P1353R0, adopted in San Diego, specified an implementation feature test macro for destroying delete (P0722R3).
The implementation of the feature (https://reviews.llvm.org/rL315662) is not guarded behind a flag, so the macro is not conditional on language version.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55741
llvm-svn: 350934
template specialization if there is no matching non-template function.
This exposed a couple of related bugs:
- we would sometimes substitute into a friend template instead of a
suitable non-friend declaration; this would now crash because we'd
decide the specialization of the friend is a redeclaration of itself
- ADL failed to properly handle the case where an invisible local
extern declaration redeclares an invisible friend
Both are fixed herein: in particular, we now never make invisible
friends or local extern declarations visible to name lookup unless
they are the only declaration of the entity. (We already mostly did
this for local extern declarations.)
llvm-svn: 350505
This adds anchors to all of the documented checks so that you can directly link to a check by a stable name. This is useful because the SARIF file format has a field for specifying a URI to documentation for a rule and some viewers, like CodeSonar, make use of this information. These links are then exposed through the SARIF exporter.
llvm-svn: 349812
In Python3, dict.items, dict.keys, dict.values, zip, map and filter no longer return lists, they create generator instead.
The portability patch consists in forcing an extra `list` call if the result is actually used as a list.
`map` are replaced by list comprehension and `filter` by filtered list comprehension.
Differential Revision: https://reviews.llvm.org/D55197
llvm-svn: 349501
Implement support for try-catch blocks in constexpr functions, as
proposed in http://wg21.link/P1002 and voted in San Diego for c++20.
The idea is that we can still never throw inside constexpr, so the catch
block is never entered. A try-catch block like this:
try { f(); } catch (...) { }
is then morally equivalent to just
{ f(); }
Same idea should apply for function/constructor try blocks.
rdar://problem/45530773
Differential Revision: https://reviews.llvm.org/D55097
llvm-svn: 348789
This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
As approved for the Working Paper in San Diego, support annotating
inline namespaces with 'inline'.
Change-Id: I51a654e11ffb475bf27cccb2458768151619e384
llvm-svn: 346677
This exposes a (known) CodeGen bug: it can't cope with emitting lvalue
expressions that denote non-odr-used but usable-in-constant-expression
variables. See PR39528 for a testcase.
Reverted for now until that issue can be fixed.
llvm-svn: 346065
Interestingly, this many year old (when I last looked I remember 2010ish)
checker was committed without any tests, so I thought I'd implement them, but I
was shocked to see how I barely managed to get it working. The code is severely
outdated, I'm not even sure it has ever been used, so I'd propose to move it
back into alpha, and possibly even remove it.
Differential Revision: https://reviews.llvm.org/D53856
llvm-svn: 345990
nullptr_t does not access memory.
We now reuse CK_NullToPointer to represent a conversion from a glvalue
of type nullptr_t to a prvalue of nullptr_t where necessary.
llvm-svn: 345562
Summary:
This change rejects the shadowing of a capture by a parameter in lambdas in C++17.
```
int main() {
int a;
auto f = [a](int a) { return a; };
}
```
results in:
```
main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity
auto f = [a](int a) { return a; };
^
main.cpp:3:13: note: variable a is explicitly captured here
auto f = [a](int a) { return a; };
^
```
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: lebedev.ri, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53595
llvm-svn: 345308
I added some missing doc. I have not developed any of these checkers, it might worth really inspecting whether I wrote something terribly incorrect.
Differential Revision: https://reviews.llvm.org/D52969
llvm-svn: 344878
Summary:
- Update the example VS project generation to use VS2017.
- Add docs for generating ninja build files, since they are popular.
- Remove reference to "make update" which no longer exists. Mention the
monorepo instead.
- Try to explain gnuwin32/coreutils requirements better.
- Use https:// links where possible
Reviewers: zturner, STL_MSFT
Subscribers: jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D52843
llvm-svn: 343809
Fix a one letter typo in diagnostics.html. (Wanted to try it with
arcanist).
Patch by king6cong
Differential Revision: https://reviews.llvm.org/D52511
llvm-svn: 343372
render the function deleted instead of rendering the program ill-formed.
This change also adds an enabled-by-default warning for the case where
an explicitly-defaulted special member function of a non-template class
is implicitly deleted by the type checking rules. (This fires either due
to this language change or due to pre-C++20 reasons for the member being
implicitly deleted). I've tested this on a large codebase and found only
bugs (where the program means something that's clearly different from
what the programmer intended), so this is enabled by default, but we
should revisit this if there are problems with this being enabled by
default.
llvm-svn: 343285
triggers instantiation of constexpr functions.
We mostly implemented this since Clang 6, but missed the template
instantiation case.
We do not implement the '&cast-expression' special case. It appears to
be a mistake / oversight. I've mailed CWG to see if we can remove it.
llvm-svn: 343064
This change implements C++ DR1696, which makes initialization of a
reference member of a class from a temporary object ill-formed. The
standard wording here is imprecise, but we interpret it as meaning that
any time a mem-initializer would result in lifetime extension, the
program is ill-formed.
This reinstates r337226, reverted in r337255, with a fix for the
InitializedEntity alignment problem that was breaking ARM buildbots.
llvm-svn: 337329
This change breaks on ARM because pointers to clang::InitializedEntity are only
4 byte aligned and do not have 3 bits to store values. A possible solution
would be to change the fields in clang::InitializedEntity to enforce a bigger
alignment requirement.
The error message is
llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer"
static_assert(IntBits <= PtrTraits::NumLowBitsAvailable,
include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here
Value = Info::updateInt(Info::updatePointer(0, PtrVal),
llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here
setPointerAndInt(PtrVal, IntVal);
^
llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here
return {Entity, LK_Extended};
Full log here:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394
llvm-svn: 337255
This change implements C++ DR1696, which makes initialization of a
reference member of a class from a temporary object ill-formed. The
standard wording here is imprecise, but we interpret it as meaning that
any time a mem-initializer would result in lifetime extension, the
program is ill-formed.
llvm-svn: 337226
This allows more qualification conversions, eg. conversion from
'int *(*)[]' -> 'const int *const (*)[]'
is now permitted, along with all the consequences of that: more types
are similar, more cases are permitted by const_cast, and conversely,
fewer "casting away constness" cases are permitted by reinterpret_cast.
llvm-svn: 336745
These functions are obsolete. The analyzer would advice to replace them with
memcmp(), memcpy() or memmove(), or memset().
Patch by Tom Rix!
Differential Revision: https://reviews.llvm.org/D41881
llvm-svn: 333326
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
layout" rules.
The new rules say that a standard-layout struct has its first non-static
data member and all base classes at offset 0, and consider a class to
not be standard-layout if that would result in multiple subobjects of a
single type having the same address.
We track "is C++11 standard-layout class" separately from "is
standard-layout class" so that the ABIs that need this information can
still use it.
Differential Revision: https://reviews.llvm.org/D45176
llvm-svn: 329332
Also rearrange how we list DR motions: rather than listing them as part of some
later standard, list them against the feature they are a DR against. Explicitly
add a description of how we handle DRs.
llvm-svn: 327769
More generally, this permits a template to be specialized in any scope in which
it could be defined, so this also supersedes DR44 and DR374 (the latter of
which we previously only implemented in C++11 mode onwards due to unclarity as
to whether it was a DR).
llvm-svn: 327705
Autoconf and some other systems tend to add essential compilation
options to CC (e.g. -std=gnu99). When running such an auto-generated
makefile, scan-build does not need to change CC and CXX as they are
already set to use ccc-analyzer by a configure script.
Implement a new option --keep-cc as was proposed in this discussion:
http://lists.llvm.org/pipermail/cfe-dev/2013-September/031832.html
Patch by Paul Fertser!
llvm-svn: 323665
While here, fix up the myriad other ways in which Sema's two "can this handler
catch that exception?" implementations get things wrong and unify them.
llvm-svn: 322431
This patch, by hamzasood, implements P0409R2, and allows [=, this] pre-C++2a as an extension (with appropriate warnings) for consistency.
https://reviews.llvm.org/D36572
Thanks Hamza!
llvm-svn: 311224
Kristof Umann