Fix #129411

It turns out `SemaTemplate` handles this type of diagnostic already,
however when template gets encountered, it never gets parsed as a
possible statement or declaration, only as an expression.

Fixes #17959.

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

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

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

GCC from 11 onwards defaults to -std=gnu++17 for C++ source files. We want to do the same
(https://discourse.llvm.org/t/c-objc-switch-to-gnu-17-as-the-default-dialect/64360).
Split RUN lines, adjust `-verify`, or add `__cplusplus < 201703L` or `-Wno-dynamic-exception-spec`,
so that tests will pass regardless of gnu++14/gnu++17 default.

We have a desire to mark a test compatible with multiple language standards.
There are ongoing discussions how to add markers in the long term:

* https://discourse.llvm.org/t/iterating-lit-run-lines/62596
* https://discourse.llvm.org/t/lit-run-a-run-line-multiple-times-with-different-replacements/64932

As a workaround in the short term, add lit substitutions `%std_cxx98-`,
`%std_cxx11-14`, etc. They can be used for tests which work across multiple
language standards. If a range has `n` standards, run lit multiple times, with
`LIT_CLANG_STD_GROUP=0`, `LIT_CLANG_STD_GROUP=1`, etc to cover all `n` standards.

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

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

C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 without a deprecation period, so implementations continued to
support the feature. Now, as with implicit function declarations, is a
good time to reevaluate the need for this support.

This patch allows -Wimplicit-int to issue warnings in C89 mode (off by
default), defaults the warning to an error in C99 through C17, and
disables support for the feature entirely in C2x. It also removes a
warning about missing declaration specifiers that really was just an
implicit int warning in disguise and other minor related cleanups.

C++17 permits using 'typename' or 'class' for a template template
parameter, but the error message in the parser only refers to 'class'.
This patch, in C++17 or newer modes, adds "or 'template'" to the
diagnostic.

No other compiler accepts this as an extension, not even in permissive
mode. We're not doing anyone any favors by allowing this, and it's
unlikely to be at all common, even in Clang-only code, in the wild.

- add more tests (the test added in https://github.com/llvm/llvm-project/commit/2f448467e4254ddc3191136c968e6054bc009b88 is weak);
- improve the `MyTemplate<type_typo, int>();` case, with this patch, typo correction
  suggests the type decl, and no regressions found.

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