[clang] Remove rdar links; NFC

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

[clang] Remove rdar links; NFC

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

show more ...

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

Differential Revision: https://reviews.llvm.org/D155509

show more ...

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the eighth batch of tests being updated (there are a
significant number of other tests left to be updated).

show more ...

[analyzer] Move analyzer-eagerly-assume to AnalyzerOptions, enable by default

Differential Revision: https://reviews.llvm.org/D51251

llvm-svn: 340963

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and pe

Reland 4: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

Differential Revision: https://reviews.llvm.org/D30373

llvm-svn: 296895

show more ...

Revert "Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit ea36f1406e1f36bf456c3f3929839b024128e468.

llvm-svn: 296841

Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and pe

Reland 3: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

Differential Revision: https://reviews.llvm.org/D30373

llvm-svn: 296837

show more ...

Revert "Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit f93343c099fff646a2314cc7f4925833708298b1.

llvm-svn: 296836

Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and pe

Reland 2: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

Differential Revision: https://reviews.llvm.org/D30373

llvm-svn: 296835

show more ...

Revert "Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit 1b28d0b10e1c8feccb971abb6ef7a18bee589830.

llvm-svn: 296422

Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perf

Reland: [analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

Differential Revision: https://reviews.llvm.org/D30373

llvm-svn: 296414

show more ...

Revert "[analyzer] NFC: Update test infrastructure to support multiple constraint managers"

This reverts commit 8e7780b9e59ddaad1800baf533058d2c064d4787.

llvm-svn: 296317

[analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runt

[analyzer] NFC: Update test infrastructure to support multiple constraint managers

Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.

Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin

Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits

Differential Revision: https://reviews.llvm.org/D30373

llvm-svn: 296312

show more ...

[analyzer] Drop explicit mention of range constraint solver

Summary: The basic constraint solver was dropped in rL162384, leaving the range constraint solver as the default and only constraint solve

[analyzer] Drop explicit mention of range constraint solver

Summary: The basic constraint solver was dropped in rL162384, leaving the range constraint solver as the default and only constraint solver. Explicitly specifying it is unnecessary, and makes it difficult to test with other solver backends.

Reviewers: zaks.anna, dcoughlin

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D26694

llvm-svn: 288372

show more ...

[analyzer] Tighten up safety in the use of lazy bindings.

- When deciding if we can reuse a lazy binding, make sure to check if there
are additional bindings in the sub-region.
- When reading from

[analyzer] Tighten up safety in the use of lazy bindings.

- When deciding if we can reuse a lazy binding, make sure to check if there
are additional bindings in the sub-region.
- When reading from a lazy binding, don't accidentally strip off casts or
base object regions. This slows down lazy binding reading a bit but is
necessary for type sanity when treating one class as another.

A bit of minor refactoring allowed these two checks to be unified in a nice
early-return-using helper function.

<rdar://problem/13239840>

llvm-svn: 175703

show more ...

[analyzer] Reuse a LazyCompoundVal if its type matches the new region.

This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2

[analyzer] Reuse a LazyCompoundVal if its type matches the new region.

This allows us to keep from chaining LazyCompoundVals in cases like this:
CGRect r = CGRectMake(0, 0, 640, 480);
CGRect r2 = r;
CGRect r3 = r2;

Previously we only made this optimization if the struct did not begin with
an aggregate member, to make sure that we weren't picking up an LCV for
the first field of the struct. But since LazyCompoundVals are typed, we can
make that inference directly by comparing types.

This is a pure optimization; the test changes are to guard against possible
future regressions.

llvm-svn: 174211

show more ...

[analyzer] Fix a bug in region store that lead to undefined value false
positives.

The includeSuffix was only set on the first iteration through the
function, resulting in invalid regions being prod

[analyzer] Fix a bug in region store that lead to undefined value false
positives.

The includeSuffix was only set on the first iteration through the
function, resulting in invalid regions being produced by getLazyBinding
(ex: zoomRegion.y).

llvm-svn: 174016

show more ...

[analyzer] When invalidating symbolic offset regions, take fields into account.

Previously, RegionStore was being VERY conservative in saying that because
p[i].x and p[i].y have a concrete base regi

[analyzer] When invalidating symbolic offset regions, take fields into account.

Previously, RegionStore was being VERY conservative in saying that because
p[i].x and p[i].y have a concrete base region of 'p', they might overlap.
Now, we check the chain of fields back up to the base object and check if
they match.

This only kicks in when dealing with symbolic offset regions because
RegionStore's "base+offset" representation of concrete offset regions loses
all information about fields. In cases where all offsets are concrete
(s.x and s.y), RegionStore will already do the right thing, but mixing
concrete and symbolic offsets can cause bindings to be invalidated that
are known to not overlap (e.g. p[0].x and p[i].y).
This additional refinement is tracked by <rdar://problem/12676180>.

<rdar://problem/12530149>

llvm-svn: 167654

show more ...

Fix analyzer tests.

llvm-svn: 162588

Remove BasicConstraintManager. It hasn't been in active service for a while.

As part of this change, I discovered that a few of our tests were not testing
the RangeConstraintManager. Luckily all o

Remove BasicConstraintManager. It hasn't been in active service for a while.

As part of this change, I discovered that a few of our tests were not testing
the RangeConstraintManager. Luckily all of those passed when I moved them
over to use that constraint manager.

llvm-svn: 162384

show more ...

[analyzer] -analyzer-ipa=inlining is now the default. Remove it from tests.

The actual change here is a little more complicated than the summary above.
What we want to do is have our generic inlinin

[analyzer] -analyzer-ipa=inlining is now the default. Remove it from tests.

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

show more ...

[analyzer] Revamp RegionStore to distinguish regions with symbolic offsets.

RegionStore currently uses a (Region, Offset) pair to describe the locations
of memory bindings. However, this representat

[analyzer] Revamp RegionStore to distinguish regions with symbolic offsets.

RegionStore currently uses a (Region, Offset) pair to describe the locations
of memory bindings. However, this representation breaks down when we have
regions like 'array[index]', where 'index' is unknown. We used to store this
as (SubRegion, 0); now we mark them specially as (SubRegion, SYMBOLIC).

Furthermore, ProgramState::scanReachableSymbols depended on the existence of
a sub-region map, but RegionStore's implementation doesn't provide for such
a thing. Moving the store-traversing logic of scanReachableSymbols into the
StoreManager allows us to eliminate the notion of SubRegionMap altogether.

This fixes some particularly awkward broken test cases, now in
array-struct-region.c.

llvm-svn: 161510

show more ...

[analyzer] Fix mis-committed test. No functionality change.

llvm-svn: 159869

[analyzer] Be careful about LazyCompoundVals, which may be for the first field.

We use LazyCompoundVals to avoid copying the contents of structs and arrays
around in the store, and when we need to p

[analyzer] Be careful about LazyCompoundVals, which may be for the first field.

We use LazyCompoundVals to avoid copying the contents of structs and arrays
around in the store, and when we need to pass a struct around that already
has a LazyCompoundVal we just use the original one. However, it's possible
that the first field of a struct may have a LazyCompoundVal of its own, and
we currently can't distinguish a LazyCompoundVal for the first element of a
struct from a LazyCompoundVal for the entire struct. In this case we should
just drop the optimization and make a new LazyCompoundVal that encompasses
the old one.

PR13264 / <rdar://problem/11802440>

llvm-svn: 159866

show more ...