summaryrefslogtreecommitdiff
path: root/libc
diff options
context:
space:
mode:
authorMartin Braenne <mboehme@google.com>2023-05-15 09:23:44 +0000
committerMartin Braenne <mboehme@google.com>2023-05-15 11:04:51 +0000
commit1a42f795587b9d57291d009989aace6efd0a7a7f (patch)
treef817b6c8be93eaba8b91ad02a0d0391ab8f8d63d /libc
parent701f7230cdc065e180077b66ba3c839adb9092b4 (diff)
downloadllvm-1a42f795587b9d57291d009989aace6efd0a7a7f.tar.gz
[clang][dataflow] Don't analyze templated declarations.
Attempting to analyze templated code doesn't have a good cost-benefit ratio. We have so far done a best-effort attempt at this, but maintaining this support has an ongoing high maintenance cost because the AST for templates can violate a lot of the invariants that otherwise hold for the AST of concrete code. As just one example, in concrete code the operand of a UnaryOperator '*' is always a prvalue (https://godbolt.org/z/s3e5xxMd1), but in templates this isn't true (https://godbolt.org/z/6W9xxGvoM). Further rationale for not analyzing templates: * The semantics of a template itself are weakly defined; semantics can depend strongly on the concrete template arguments. Analyzing the template itself (as opposed to an instantiation) therefore has limited value. * Analyzing templates requires a lot of special-case code that isn't necessary for concrete code because dependent types are hard to deal with and the AST violates invariants that otherwise hold for concrete code (see above). * There's precedent in that neither Clang Static Analyzer nor the flow-sensitive warnings in Clang (such as uninitialized variables) support analyzing templates. Reviewed By: gribozavr2, xazax.hun Differential Revision: https://reviews.llvm.org/D150352
Diffstat (limited to 'libc')
0 files changed, 0 insertions, 0 deletions