We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.
This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.
Differential Review: https://reviews.llvm.org/D158071
It was previously reverted by 8406839d1926486de900c7cabeea9f841bd3edf2.
---
This flag was introduced by
6818991d71
commit 6818991d7165f68fe196922d9e5c6648dd57cc47
Author: Ted Kremenek <kremenek@apple.com>
Date: Mon Dec 7 22:06:12 2009 +0000
Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
block literals as an entry point for analyzer checks.
The last reference was removed by this commit:
5c32dfc5fb
commit 5c32dfc5fb1cfcff8ae3671284e17daa8da3a188
Author: Anna Zaks <ganna@apple.com>
Date: Fri Dec 21 01:19:15 2012 +0000
[analyzer] Add blocks and ObjC messages to the call graph.
This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.
Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).
Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
- Should the `cc1` frontend still accept this flag - to keep
tools/users passing this flag directly to `cc1` (which is unsupported,
unadvertised) working.
- If we should remain backward compatible, how long?
- How can we get rid of deprecated and obsolete flags at some point?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126067
I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`.
Then make sure one can set these by an `-analyzer-config XXX=YYY` style
flag.
Then surface the `-analyzer-config` to the `clang` frontend;
After all of this, we can pursue the tablegen approach described
https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488
In this patch, I'm proposing flag deprecations.
We should support deprecated analyzer flags for exactly one release. In
this case I'm planning to drop this flag in `clang-16`.
In the clang frontend, now we won't pass this option to the cc1
frontend, rather emit a warning diagnostic reminding the users about
this deprecated flag, which will be turned into error in clang-16.
Unfortunately, I had to remove all the tests referring to this flag,
causing a mass change. I've also added a test for checking this warning.
I've seen that `scan-build` also uses this flag, but I think we should
remove that part only after we turn this into a hard error.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126215
This reverts commit d50d9946d1d7e5f20881f0bc71fbd025040b1c96.
Broke check-clang, see comments on https://reviews.llvm.org/D126067
Also revert dependent change "[analyzer] Deprecate the unused 'analyzer-opt-analyze-nested-blocks' cc1 flag"
This reverts commit 07b4a6d0461fe64e10d30029ed3d598e49ca3810.
Also revert "[analyzer] Fix buildbots after introducing a new frontend warning"
This reverts commit 90374df15ddc58d823ca42326a76f58e748f20eb.
(See https://reviews.llvm.org/rG90374df15ddc58d823ca42326a76f58e748f20eb)
This flag was introduced by
6818991d71
commit 6818991d7165f68fe196922d9e5c6648dd57cc47
Author: Ted Kremenek <kremenek@apple.com>
Date: Mon Dec 7 22:06:12 2009 +0000
Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
block literals as an entry point for analyzer checks.
The last reference was removed by this commit:
5c32dfc5fb
commit 5c32dfc5fb1cfcff8ae3671284e17daa8da3a188
Author: Anna Zaks <ganna@apple.com>
Date: Fri Dec 21 01:19:15 2012 +0000
[analyzer] Add blocks and ObjC messages to the call graph.
This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.
Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).
Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
- Should the `cc1` frontend still accept this flag - to keep
tools/users passing this flag directly to `cc1` (which is unsupported,
unadvertised) working.
- If we should remain backward compatible, how long?
- How can we get rid of deprecated and obsolete flags at some point?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126067
I'm trying to remove unused options from the `Analyses.def` file, then
merge the rest of the useful options into the `AnalyzerOptions.def`.
Then make sure one can set these by an `-analyzer-config XXX=YYY` style
flag.
Then surface the `-analyzer-config` to the `clang` frontend;
After all of this, we can pursue the tablegen approach described
https://discourse.llvm.org/t/rfc-tablegen-clang-static-analyzer-engine-options-for-better-documentation/61488
In this patch, I'm proposing flag deprecations.
We should support deprecated analyzer flags for exactly one release. In
this case I'm planning to drop this flag in `clang-16`.
In the clang frontend, now we won't pass this option to the cc1
frontend, rather emit a warning diagnostic reminding the users about
this deprecated flag, which will be turned into error in clang-16.
Unfortunately, I had to remove all the tests referring to this flag,
causing a mass change. I've also added a test for checking this warning.
I've seen that `scan-build` also uses this flag, but I think we should
remove that part only after we turn this into a hard error.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126215
This extends the checks for identical expressions to handle identical
statements, and compares the consequent and alternative ("then" and "else")
branches of an if-statement to see if they are identical, treating a single
statement surrounded by braces as equivalent to one without braces.
This does /not/ check subsequent branches in an if/else chain, let alone
branches that are not consecutive. This may improve in a future patch, but
it would certainly take more work.
Patch by Daniel Fahlgren!
llvm-svn: 201701
This will emit a warning if a call to clang_analyzer_warnIfReached is
executed, printing REACHABLE. This is a more explicit way to declare
expected reachability than using clang_analyzer_eval or triggering
a bug (divide-by-zero or null dereference), and unlike the former will
work the same in inlined functions and top-level functions. Like the
other debug helpers, it is part of the debug.ExprInspection checker.
Patch by Jared Grubb!
llvm-svn: 191909
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
llvm-svn: 173385
The stop-gap here is to just drop such objects when processing the InitListExpr.
We still need a better solution.
Fixes <rdar://problem/12755044>.
llvm-svn: 168757
This was also covered by <rdar://problem/12753384>. The static analyzer
evaluates a CXXConstructExpr within an initializer expression and
RegionStore doesn't know how to handle the resulting CXXTempObjectRegion
that gets created. We need a better solution than just dropping the
value, but we need to better understand how to implement the right
semantics here.
Thanks to Jordan for his help diagnosing the behavior here.
llvm-svn: 168741
The AllocaRegion did not have the superRegion (based on LocationContext)
as part of it's hash. As a consequence, the AllocaRegions from
different frames were uniqued to be the same region.
llvm-svn: 168599
The actual change here is a little more complicated than the summary above.
What we want to do is have our generic inlining tests run under whatever
mode is the default. However, there are some tests that depend on the
presence of C++ inlining, which still has some rough edges. These tests have
been explicitly marked as -analyzer-ipa=inlining in preparation for a new
mode that limits inlining to C functions and blocks. This will be the
default until the false positives for C++ have been brought down to
manageable levels.
llvm-svn: 162317
Our current handling of 'throw' is all CFG-based: it jumps to a 'catch' block
if there is one and the function exit block if not. But this doesn't really
get the right behavior when a function is inlined: execution will continue on
the caller's side, which is always the wrong thing to do.
Even within a single function, 'throw' completely skips any destructors that
are to be run. This is essentially the same problem as @finally -- a CFGBlock
that can have multiple entry points, whose exit points depend on whether it
was entered normally or exceptionally.
Representing 'throw' as a sink matches our current (non-)handling of @throw.
It's not a perfect solution, but it's better than continuing analysis in an
inconsistent or even impossible state.
<rdar://problem/12113713>
llvm-svn: 162157
There's still more work to be done here; this doesn't catch reference
parameters or return values. But it's a step in the right direction.
Part of <rdar://problem/11212286>.
llvm-svn: 161214
as aborted, but didn't treat such cases as sinks in the ExplodedGraph.
Along the way, add basic support for CXXCatchStmt, expanding the set of code we actually analyze (hopefully correctly).
Fixes: <rdar://problem/10892489>
llvm-svn: 152468
