all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Differential Revision: https://reviews.llvm.org/D54472
llvm-svn: 351701
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.
llvm-svn: 351632
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
Summary: This is just changing naming and documentation to be general about external definitions that can be imported for cross translation unit analysis. There is at least a plan to add VarDecls: D46421
Reviewers: NoQ, xazax.hun, martong, a.sidorin, george.karpenkov, serge-sans-paille
Reviewed By: xazax.hun, martong
Subscribers: mgorny, whisperity, baloghadamsoftware, szepet, rnkovacs, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D56441
llvm-svn: 350852
Use the same logic as in TypePrinter::printTag to determine that the tag is anonymous and the separate check for namespaces.
Differential Revision: https://reviews.llvm.org/D54996
llvm-svn: 350805
The '.stringVal' field in ExprEvalResult is allocated using new[],
but was freed using a regular delete. That caused memory leaks in
the test from r350666.
llvm-svn: 350680
The original commit had a memory leak in the test has a leak as it doesn't
dispose of the evaluated cursor result.
This also contains the follow-up NFC refactoring commit r336591.
rdar://45893054
Original commit message:
[libclang] evalute compound statement cursors before trying to evaluate
the cursor like a declaration
This change fixes a bug in libclang in which it tries to evaluate a statement
cursor as a declaration cursor, because that statement still has a pointer to
the declaration parent.
rdar://38888477
Differential Revision: https://reviews.llvm.org/D49051
llvm-svn: 350666
StringIO is obsoleted in Python3, replaced by io.BytesIO or io.StringIO depending on the use.
Differential Revision: https://reviews.llvm.org/D55196
llvm-svn: 350318
This change ensures that the libclang CXCursor represents the CoroutineBody
and the Coreturn statement using the appropriate CXCursor_UnexposedStmt kind
instead of CXCursor_UnexposedExpr. The problem with CXCursor_UnexposedExpr is
that the consumer functions assumed that CoroutineBody/Coreturn statements
were valid expressions and performed an invalid downcast to Expr causing
assertion failures or other crashes.
rdar://40204290
llvm-svn: 350282
Looks like these were in place to make these types move-only. That's
generally not a feature that the type should prescribe (unless it's an
inherent limitation) - instead leaving it up to the users of a type.
llvm-svn: 349669
urllib2 as been renamed into urllib and the library layout has changed.
Workaround that in a consistent manner.
Differential Revision: https://reviews.llvm.org/D55199
llvm-svn: 349627
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
Summary:
This supposes to be a non-functional change. We have two code paths when
traversing lambda expressions:
1) traverse the function proto typeloc when parameters and return type
are explicit;
2) otherwise fallback to traverse parameter decls and return type loc
individually;
This patch unifies the code path to always traverse parameters and
return type, rather than relying on traversing the full type-loc.
Reviewers: ilya-biryukov
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D55820
llvm-svn: 349494
Using from __future__ import print_function it is possible to have a compatible behavior of `print(...)` across Python version.
Differential Revision: https://reviews.llvm.org/D55213
llvm-svn: 349454
Frontend headers have undefined reference on the symbol `clang::PCHContainerOperations::PCHContainerOperations()` through some shared_ptr usage. Any dependents will get the undefined reference which can only be resolved by explicit dependency on clangSerialization (due to -z defs).
llvm-svn: 349259
This updates the scan-build perl script to allow outputting to sarif in a more natural fashion by specifying -sarif as a command line argument, similar to how -plist is already supported.
llvm-svn: 349082
Address spaces are cast into generic before invoking the constructor.
Added support for a trailing Qualifiers object in FunctionProtoType.
Note: This recommits the previously reverted patch,
but now it is commited together with a fix for lldb.
Differential Revision: https://reviews.llvm.org/D54862
llvm-svn: 349019
This library was breaking my -DBUILD_SHARED_LIBS=1 build. rC348915 seemed to miss this case.
As this seems an "obvious" fix, I am committing without pre-commit review as
per the LLVM developer policy.
llvm-svn: 348929
Address spaces are cast into generic before invoking the constructor.
Added support for a trailing Qualifiers object in FunctionProtoType.
Differential Revision: https://reviews.llvm.org/D54862
llvm-svn: 348927
This is a more thorough fix of rC348911.
The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move PCHContainerOperations from Frontend to Serialization) is:
1. libclangSerialization.so defines PCHContainerReader dtor, ...
2. clangFrontend and clangTooling define classes inheriting from PCHContainerReader, thus their DSOs have undefined references on PCHContainerReader dtor
3. Components depending on either clangFrontend or clangTooling cannot be linked unless they have explicit dependency on clangSerialization due to the default linker option -z defs. The explicit dependency could be avoided if libclang{Frontend,Tooling}.so had these undefined references.
This patch adds the explicit dependency on clangSerialization to make them build.
llvm-svn: 348915
Workaround naming and hierarchy changes in BaseHTTPServer and SimpleHTTPServer module.
Differential Revision: https://reviews.llvm.org/D55203
llvm-svn: 348184
Python2 supports both backticks and `repr` to access the __repr__ slot. Python3 only supports `repr`.
Differential Revision: https://reviews.llvm.org/D55201
llvm-svn: 348182
Have all classes derive from object: that's implicitly the default in Python3,
it needs to be done explicilty in Python2.
Differential Revision: https://reviews.llvm.org/D55121
llvm-svn: 348127
Python2 supports the two following equivalent construct
raise ExceptionType, exception_value
and
raise ExceptionType(exception_value)
Only the later is supported by Python3.
Differential Revision: https://reviews.llvm.org/D55195
llvm-svn: 348126
Constructors have the same methods for arguments as call expressions.
Let's provide a way to get their arguments the same way.
Differential Revision: https://reviews.llvm.org/D54934
llvm-svn: 347654
This patch breaks Index/opencl-types.cl LIT test:
Script:
--
: 'RUN: at line 1'; stage1/bin/c-index-test -test-print-type llvm/tools/clang/test/Index/opencl-types.cl -cl-std=CL2.0 | stage1/bin/FileCheck llvm/tools/clang/test/Index/opencl-types.cl
--
Command Output (stderr):
--
llvm/tools/clang/test/Index/opencl-types.cl:3:26: warning: unsupported OpenCL extension 'cl_khr_fp16' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:4:26: warning: unsupported OpenCL extension 'cl_khr_fp64' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:8:9: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:11:8: error: declaring variable of type 'half' is not allowed
llvm/tools/clang/test/Index/opencl-types.cl:15:3: error: use of type 'double' requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:16:3: error: use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:26:26: warning: unsupported OpenCL extension 'cl_khr_gl_msaa_sharing' - ignoring [-Wignored-pragmas]
llvm/tools/clang/test/Index/opencl-types.cl:35:44: error: use of type '__read_only image2d_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:36:49: error: use of type '__read_only image2d_array_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:37:49: error: use of type '__read_only image2d_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm/tools/clang/test/Index/opencl-types.cl:38:54: error: use of type '__read_only image2d_array_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled
llvm-svn: 346338
Chandler Carruth