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

[test] Make tests pass regardless of gnu++14/gnu++17 default

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-

[test] Make tests pass regardless of gnu++14/gnu++17 default

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

show more ...

Consistent spelling in diagnostics: {l,r}value instead of {l,r}-value

As Richard Smith pointed out in the review of D90123, both the C and C++
standard call it lvalue and rvalue, so let's stick to t

Consistent spelling in diagnostics: {l,r}value instead of {l,r}-value

As Richard Smith pointed out in the review of D90123, both the C and C++
standard call it lvalue and rvalue, so let's stick to the same spelling
in Clang.

show more ...

[Lit Test] Updated 34 Lit tests to be C++11 compatible.

Added expected diagnostics new to C++11.
Expanded RUN line to: default, C++98/03 and C++11.

llvm-svn: 253371

If a non-template constructor instantiated to X(X),
ignore it during overload resolution when initializing
X from a value of type cv X.

Previously, our rule here only ignored specializations
of cons

If a non-template constructor instantiated to X(X),
ignore it during overload resolution when initializing
X from a value of type cv X.

Previously, our rule here only ignored specializations
of constructor templates. That's probably because the
standard says that constructors are outright ill-formed
if their first parameter is literally X and they're
callable with one argument. However, Clang only
enforces that prohibition against non-implicit
instantiations; I'm not sure why, but it seems to be
deliberate. Given that, the most sensible thing to
do is to just ignore the "illegal" constructor
regardless of where it came from.

Also, stop ignoring such constructors silently:
print a note explaining why they're being ignored.

Fixes <rdar://19199836>.

llvm-svn: 224205

show more ...

Improve our handling of C++ [class.copy]p3, which specifies that a
constructor template will not be used to copy a class object to a
value of its own type. We were eliminating all constructor templat

Improve our handling of C++ [class.copy]p3, which specifies that a
constructor template will not be used to copy a class object to a
value of its own type. We were eliminating all constructor templates
whose specializations look like a copy constructor, which eliminated
important candidates. Fixes PR8182.

llvm-svn: 118418

show more ...

Improve our handling of user-defined conversions as part of overload
resolution. There are two sources of problems involving user-defined
conversions that this change eliminates, along with providing

Improve our handling of user-defined conversions as part of overload
resolution. There are two sources of problems involving user-defined
conversions that this change eliminates, along with providing simpler
interfaces for checking implicit conversions:

- It eliminates a case of infinite recursion found in Boost.

- It eliminates the search for the constructor needed to copy a temporary
generated by an implicit conversion from overload
resolution. Overload resolution assumes that, if it gets a value
of the parameter's class type (or a derived class thereof), there
is a way to copy if... even if there isn't. We now model this
properly.

llvm-svn: 101680

show more ...

Improve the diagnostics used to report implicitly-generated class members
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.

Adjust a lot of tests.

llv

Improve the diagnostics used to report implicitly-generated class members
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.

Adjust a lot of tests.

llvm-svn: 92832

show more ...

Switch the initialization required by return statements over to the
new InitializationSequence. This fixes some bugs (e.g., PR5808),
changed some diagnostics, and caused more churn than expected. Wha

Switch the initialization required by return statements over to the
new InitializationSequence. This fixes some bugs (e.g., PR5808),
changed some diagnostics, and caused more churn than expected. What's
new:

- InitializationSequence now has a "C conversion sequence" category
and step kind, which falls back to
- Changed the diagnostics for returns to always have the result type
of the function first and the type of the expression second.
CheckSingleAssignmentConstraints to peform checking in C.
- Improved ASTs for initialization of return values. The ASTs now
capture all of the temporaries we need to create, but
intentionally do not bind the tempoary that is actually returned,
so that it won't get destroyed twice.
- Make sure to perform an (elidable!) copy of the class object that
is returned from a class.
- Fix copy elision in CodeGen to properly see through the
subexpressions that occur with elidable copies.
- Give "new" its own entity kind; as with return values and thrown
objects, we don't bind the expression so we don't call a
destructor for it.

Note that, with this patch, I've broken returning move-only types in
C++0x. We'll fix it later, when we tackle NRVO.

llvm-svn: 91669

show more ...

Introduce a centralized routine in Sema for diagnosing failed lookups (when
used as expressions). In dependent contexts, try to recover by doing a lookup
in previously-dependent base classes. We ge

Introduce a centralized routine in Sema for diagnosing failed lookups (when
used as expressions). In dependent contexts, try to recover by doing a lookup
in previously-dependent base classes. We get better diagnostics out, but
unfortunately the recovery fails: we need to turn it into a method call
expression, not a bare call expression. Thus this is still a WIP.

llvm-svn: 91525

show more ...

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

Improve template instantiation for object constructions in several ways:

- During instantiation, drop default arguments from constructor and
call expressions; they'll be recomputed anyway, and

Improve template instantiation for object constructions in several ways:

- During instantiation, drop default arguments from constructor and
call expressions; they'll be recomputed anyway, and we don't want
to instantiate them twice.
- Rewrote the instantiation of variable initializers to cope with
non-dependent forms properly.

Together, these fix a handful of problems I introduced with the switch
to always rebuild expressions from the source code "as written."

llvm-svn: 91315

show more ...

Improve on diagnosing type mismatches because of
lack of viable convesion functions.

llvm-svn: 89216

If we attempt to add a constructor template specialization that looks
like a copy constructor to the overload set, just ignore it. This
ensures that we don't try to use such a constructor as a copy
c

If we attempt to add a constructor template specialization that looks
like a copy constructor to the overload set, just ignore it. This
ensures that we don't try to use such a constructor as a copy
constructor *without* triggering diagnostics at the point of
declaration.

Note that we *do* diagnose such copy constructors when explicitly
written by the user (e.g., as an explicit specialization).

llvm-svn: 88733

show more ...

Revert r88718, which does NOT solve the constructor-template-as-copy-constructor issue. Big thanks to John for finding this

llvm-svn: 88724

A constructor template cannot be instantiated to a copy
constructor. Make sure that such declarations can never be formed.

llvm-svn: 88718

Introduce a new class, UnqualifiedId, that provides a parsed
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
vario

Introduce a new class, UnqualifiedId, that provides a parsed
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
various forms of unqualified-id in C++.

Replace the representation of the declarator name in Declarator with
the new UnqualifiedId class, simplifying declarator-id parsing
considerably and providing more source-location information to
Sema. In the future, I hope to migrate all of the other
unqualified-id-parsing code over to this single representation, then
begin to merge actions that are currently only different because we
didn't have a unqualified notion of the name in the parser.

llvm-svn: 85851

show more ...

Commit test case from PR4655, which tests the canonical-types fix in r81913

llvm-svn: 81916

Add an assertion and a test case, in a fruitless attempt to track down an existing bug

llvm-svn: 81885

Make sure to adjust function template declarations to their templated
declarations (e.g., FunctionTemplateDecl -> CXXConstructorDecl) before
performing semantic analysis on the declarations. Fixes PR

Make sure to adjust function template declarations to their templated
declarations (e.g., FunctionTemplateDecl -> CXXConstructorDecl) before
performing semantic analysis on the declarations. Fixes PR4761.

llvm-svn: 79911

show more ...

Introduce support for constructor templates, which can now be declared
and will participate in overload resolution. Unify the instantiation
of CXXMethodDecls and CXXConstructorDecls, which had alread

Introduce support for constructor templates, which can now be declared
and will participate in overload resolution. Unify the instantiation
of CXXMethodDecls and CXXConstructorDecls, which had already gotten
out-of-sync.

llvm-svn: 79658

show more ...