summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api/target/TestTargetAPI.py
diff options
context:
space:
mode:
authorRichard Smith <richard-llvm@metafoo.co.uk>2017-01-07 00:48:55 +0000
committerRichard Smith <richard-llvm@metafoo.co.uk>2017-01-07 00:48:55 +0000
commitd6a150829b04a63bdcc9bafe4fb7faa0e96a9df5 (patch)
tree005efe470ff275402614d3bbda5bb9036f67c11f /lldb/packages/Python/lldbsuite/test/python_api/target/TestTargetAPI.py
parent598861f661d90a87a4c6bec230b00386fa962da5 (diff)
downloadbcm5719-llvm-d6a150829b04a63bdcc9bafe4fb7faa0e96a9df5.tar.gz
bcm5719-llvm-d6a150829b04a63bdcc9bafe4fb7faa0e96a9df5.zip
PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
This implements something like the current direction of DR1581: we use a narrow syntactic check to determine the set of places where a constant expression could be evaluated, and only instantiate a constexpr function or variable if it's referenced in one of those contexts, or is odr-used. It's not yet clear whether this is the right set of syntactic locations; we currently consider all contexts within templates that would result in odr-uses after instantiation, and contexts within list-initialization (narrowing conversions take another victim...), as requiring instantiation. We could in principle restrict the former cases more (only const integral / reference variable initializers, and contexts in which a constant expression is required, perhaps). However, this is sufficient to allow us to accept libstdc++ code, which relies on GCC's behavior (which appears to be somewhat similar to this approach). llvm-svn: 291318
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/target/TestTargetAPI.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud