not be a pack expansion type.
Using a pack expansion type for a pack declaration makes sense, but
general expressions should never have pack expansion types. If we have a
pack `T *...V`, then the type of `V` is the type `T *`, which contains
an unexpanded pack, and is a pointer type.
This allows us to better diagnose issues where a template is invalid due
to some non-dependent portion of a dependent type of a non-type template
parameter pack.
trivial.
We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.
Previously committed as c57f8a3a20. This
now also includes an extension of LLDB's workaround for handling special
members without the help of Sema to cover copy assignments.
trivial.
We previously took a shortcut by assuming that if a subobject had a
trivial copy assignment operator (with a few side-conditions), we would
always invoke it, and could avoid going through overload resolution.
That turns out to not be correct in the presenve of ref-qualifiers (and
also won't be the case for copy-assignments with requires-clauses
either). Use the same logic for lazy declaration of copy-assignments
that we use for all other special member functions.
implementing the resolution of CWG2352.
No functionality change, except that we now convert the referent of a
reference binding to the underlying type of the reference in more cases;
we used to happen to preserve the type sugar from the referent if the
only type change was in the cv-qualifiers.
This exposed a bug in how we generate code for trivial assignment
operators: if the type sugar (particularly the may_alias attribute)
got lost during reference binding, we'd use the "wrong" TBAA information
for the load during the assignment.
I am planning to use this feature to make update_cc_test_checks.py less fragile
by obtaining the mangled names directly from -ast-dump=json. Currently,
it uses c-index-test which ignores the -triple=, etc. arguments that are
in the RUN: line and therefore does not generate checks for some targets.
The AST dump tests were updated using the following command:
`python $LLVM_BINDIR/gen_ast_dump_json_test.py --update --source $LLVM_SRC/clang/test/AST/*-json.*`
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: rsmith, MaskRay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69564
This adds information about the offset within the source file to the given source location as well as information about the include file a location is from. These pieces of information allow for more efficient post-processing of JSON AST dumps.
llvm-svn: 374921
Rather than create JSON objects for source locations and ranges, we instead stream them out directly. This allows us to elide duplicate information (without JSON field reordering causing an issue) like file names and line numbers, similar to the text dump. This also adds token length information when dumping the source location.
llvm-svn: 364226
This also details what filters, if any, were used to generate the test output. Updates all the current JSON testing files to include the automated note.
llvm-svn: 364055
Previously, we attempted to write out template parameters and specializations to their own array, but due to the architecture of the ASTNodeTraverser, this meant that other nodes were not being written out. This now follows the same behavior as the regular AST dumper and puts all the (correct) information into the "inner" array. When we correct the AST node traverser itself, we can revisit splitting this information into separate arrays again.
llvm-svn: 363819
and returned to the context in which 'this' should be captured.
This means we now always mark 'this' referenced from the context in
which it's actually referenced, rather than potentially from some
context nested within that.
llvm-svn: 362182