[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 ...

[Clang] Diagnose jumps into statement expressions

Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.

Fixes #63682

Reviewed By: a

[Clang] Diagnose jumps into statement expressions

Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.

Fixes #63682

Reviewed By: aaron.ballman, #clang-language-wg

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

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 ...

Revert "[Clang] Diagnose jumps into statement expressions"

This reverts commit b0cc947b5d0a74f4ffe63c53b32978b21498e72e.

Breaks in presence of asm goto
https://reviews.llvm.org/D154696#4493805

[Clang] Diagnose jumps into statement expressions

Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.

Fixes #63682

Reviewed By: a

[Clang] Diagnose jumps into statement expressions

Such jumps are not allowed by GCC and allowing them
can lead to situations where we jumps into unevaluated
statements.

Fixes #63682

Reviewed By: aaron.ballman, #clang-language-wg

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

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 fourth batch of tests being updated (there are a significant
number of other tests left to be updated).

show more ...

Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

This reapplies r334224 and adds explicit triples to some tests to fix
them on Windows (where otherwise they would have run with the default
wi

Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

This reapplies r334224 and adds explicit triples to some tests to fix
them on Windows (where otherwise they would have run with the default
windows-msvc triple, which I'm changing the behavior for).

Original commit message:
The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@finally` body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).

Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.

Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH `__finally`
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what `__finally` uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those. In theory `__finally`
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.

The one case supported by `@finally` but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
`@finally`, e.g. having a return statement inside a `@finally`. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.

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

llvm-svn: 334251

show more ...

Reword switch/goto diagnostics "protected scope" diagnostics. Making up a term
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in

Reword switch/goto diagnostics "protected scope" diagnostics. Making up a term
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in the diagnostic: we cannot jump from
here to there. The notes explain nicely why not.

llvm-svn: 217293

show more ...

Added a new attribute, objc_root_class, which informs the compiler when a root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang uni

Added a new attribute, objc_root_class, which informs the compiler when a root class is intentionally declared.
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>

llvm-svn: 154187

show more ...

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unex

Modify how the -verify flag works. Currently, the verification string and
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:

// expect-error{{candidate function has different number of parameters}}

will match the following error messages from Clang:

candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters

It will also match these other error messages:

candidate function
function has different number of parameters
number of parameters

This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:

87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)

llvm-svn: 146619

show more ...

Make clang -cc1 disable Objective-C exceptions by default, and add a -fobjc-exceptions flag to turn them on.

Update all tests accordingly.

llvm-svn: 126177

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead o

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).

llvm-svn: 91446

show more ...

Change tests to use clang -cc1...

llvm-svn: 91297

add support for goto checking and @synchronized blocks,
rdar://6810106

llvm-svn: 69667

test that vlas are checked in an objc method context.

llvm-svn: 69508

the scope checker does work with objc methods, add testcase.

llvm-svn: 69487

I didn't understand how @catches were chained. Now that I get it, fix
the scope checker to not think @catches are nested in each other, eliminating
some bogus notes.

llvm-svn: 69486

reject invalid jumps among pieces of @try blocks. This seems to work
reasonably well except for the problem that @catches are nested within
each other in the AST, giving the ugly diagnostics in L8.

reject invalid jumps among pieces of @try blocks. This seems to work
reasonably well except for the problem that @catches are nested within
each other in the AST, giving the ugly diagnostics in L8.

llvm-svn: 69477

show more ...

improve wording of scope violation error messages.

llvm-svn: 69456

rename test

llvm-svn: 69455