Commit Graph

1381 Commits

Author SHA1 Message Date
Haojian Wu b1444edbf4 [AST] Build recovery expression by default for all language.
The dependency mechanism for C has been implemented, and we have rolled out
this to all internal users, didn't see crashy issues, we consider it is stable
enough.

Differential Revision: https://reviews.llvm.org/D89046
2020-11-23 11:08:28 +01:00
Anatoliy Tomilov e7c7a19826 [Frontend] Treat .cuh files as CUDA source files
to synchronize with tools/clang-format/git-clang-format

tra: Keeping them in sync does have a minor benefit of not raising a question why the two maps are different.

Differential Revision: https://reviews.llvm.org/D91034
2020-11-12 11:42:53 -08:00
Serge Pavlov 6021cbea4d Add option 'exceptions' to pragma clang fp
Pragma 'clang fp' is extended to support a new option, 'exceptions'. It
allows to specify floating point exception behavior more flexibly.

Differential Revision: https://reviews.llvm.org/D89849
2020-10-31 17:36:12 +07:00
Melanie Blower 71bf9f07d5 [clang] add fexperimental-strict-floating-point to test cases that fail on arm and aarch not sure this will work due to commit rG13bfd89c4962 2020-10-30 07:30:06 -07:00
Melanie Blower 13bfd89c49 [clang][FPEnv] Diagnose Strict FP pragmas if target does not support StrictFP
Reviewers: sepavloff, kpn, aaron.ballman

Differential Revision: https://reviews.llvm.org/D90316
2020-10-30 06:11:25 -07:00
Tyker d3205bbca3 [Annotation] Allows annotation to carry some additional constant arguments.
This allows using annotation in a much more contexts than it currently has.
especially when annotation with template or constexpr.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D88645
2020-10-26 10:50:05 +01:00
Melanie Blower 576d436c82 Correct LIT test failure detected on buildbot after mibintc committed rG2e204e23911b: [clang] Enable support for #pragma STDC FENV_ACCESS D87528 2020-10-25 08:10:34 -07:00
Melanie Blower 2e204e2391 [clang] Enable support for #pragma STDC FENV_ACCESS
Reviewers: rjmccall, rsmith, sepavloff

Differential Revision: https://reviews.llvm.org/D87528
2020-10-25 06:46:25 -07:00
Hubert Tong 126094485a [PowerPC][AIX] Make `__vector [un]signed long` an error
The semantics associated with `__vector [un]signed long` are neither
consistently specified nor consistently implemented.

The IBM XL compilers on AIX traditionally treated these as deprecated
aliases for the corresponding `__vector int` type in both 32-bit and
64-bit modes. The newer, Clang-based, IBM XL compilers on AIX make usage
of the previously deprecated types an error. This is also consistent
with IBM XL C/C++ for Linux on Power (on little endian distributions).

In line with the above, this patch upgrades (on AIX) the deprecation of
`__vector long` to become removal.

Reviewed By: ZarkoCA

Differential Revision: https://reviews.llvm.org/D89443
2020-10-18 12:39:16 -04:00
Aaron Ballman 538762fef0 Better diagnostics for anonymous bit-fields with attributes or an initializer.
The current C++ grammar allows an anonymous bit-field with an attribute,
but this is ambiguous (the attribute in that case could appertain to the
type instead of the bit-field). The current thinking in the Core Working
Group is that it's better to disallow attributes in that position at the
grammar level so that the ambiguity resolves in favor of applying to the
type.

During discussions about the behavior of the attribute, the Core Working
Group also felt it was better to disallow anonymous bit-fields from
specifying a default member initializer.

This implements both sets of related grammar changes.
2020-09-29 16:32:20 -04:00
Aaron Ballman 15fbae8ac3 Use "default member initializer" instead of "in-class initializer" for diagnostics.
This changes some diagnostics to use terminology from the standard
rather than invented terminology, which improves consistency with other
diagnostics as well. There are no functional changes intended other
than wording and naming.
2020-09-29 15:04:23 -04:00
Richard Smith 8c98c88034 PR47176: Don't read from an inactive union member if a friend function
has default arguments and an exception specification.
2020-09-24 19:02:27 -07:00
Serge Pavlov a633da5391 [FPEnv] Partially implement #pragma STDC FENV_ROUND
This change implements pragma STDC FENV_ROUND, which is introduced by
the extension to standard (TS 18661-1). The pragma is implemented only
in frontend, it sets apprpriate state of FPOptions stored in Sema. Use
of these bits in constant evaluation adn/or code generator is not in the
scope of this change.

Parser issues warning on unsuppored pragma when it encounteres pragma
STDC FENV_ROUND, however it makes syntax checks and updates Sema state
as if the pragma were supported.

Primary purpose of the partial implementation is to facilitate
development of non-default floating poin environment. Previously a
developer cannot set non-default rounding mode in sources, this mades
preparing tests for say constant evaluation  substantially complicated.

Differential Revision: https://reviews.llvm.org/D86921
2020-09-04 16:47:10 +07:00
Richard Smith 113861b444 Fix -Wcompound-token-split to give the same warnings under -E
-frewrite-includes.

Remove the special-case (and highly implausible) diagnostic for a
compound token that crosses a file boundary, and instead model that case
the same as a compound token separated by whitespace, so that file
transitions and presumed file transitions behave the same way.
2020-08-31 20:59:20 -07:00
Richard Smith 0da84535b1 Remove -Wcompound-token-split-by-space from -Wall.
Use of a linebreak between the `(` and `{` in a GNU statement-expression
appears to be too common to include this warning in -Wall -- this occurs
in some Linux kernel headers, for example.
2020-08-31 20:59:19 -07:00
Richard Smith 0e00a95b4f Add new warning for compound punctuation tokens that are split across macro expansions or split by whitespace.
For example:

    #define FOO(x) (x)
    FOO({});

... forms a statement-expression after macro expansion. This warning
applies to '({' and '})' delimiting statement-expressions, '[[' and ']]'
delimiting attributes, and '::*' introducing a pointer-to-member.

The warning for forming these compound tokens across macro expansions
(or across files!) is enabled by default; the warning for whitespace
within the tokens is not, but is included in -Wall.

Differential Revision: https://reviews.llvm.org/D86751
2020-08-28 13:35:50 -07:00
Sam McCall c286d6fdee [Parser] Suppress -Wempty-translation-unit if this is a header file
This is motivated by tooling (clangd, libclang etc) - headers without
declarations are legitimate even if they're not valid TUs.

The other use -x c-header cases (PCH/modules) are nonstandard anyway and this
warning doesn't seem necessary there either.

Differential Revision: https://reviews.llvm.org/D85789
2020-08-13 09:43:27 +02:00
Richard Smith 1cbdf932b4 PR46231: Promote diagnostic for 'template<...>;' from ExtWarn to Error.
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.
2020-07-29 12:35:18 -07:00
Bruno Ricci 32db24a7f2
[clang] Provide a more specific diagnostic for a misplaced lambda capture-default.
Currently a capture-default which is not the first element in the lambda-capture
is diagnosed with a generic expected variable name or 'this' in lambda capture
list, which is true but not very helpful.

If we don't have already parsed a capture-default then a lone "&" or "=" is
likely to be a misplaced capture-default, so diagnose it as such.

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

Reviewed By: aaron.ballman
2020-07-18 20:35:16 +01:00
Haojian Wu 1d3d9c7b58 [clang] Include type specifiers in typo correction when checking isCXXDeclarationSpecifiers.
- add more tests (the test added in 2f448467e4 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
2020-07-13 12:05:09 +02:00
Haojian Wu 8c5133f185 [clang] Fix a null-NSS-access crash in DependentNameType.
The DependentNameType must have a non-null NSS. This property could be
violated during typo correction.

Differential Revision: https://reviews.llvm.org/D82738
2020-07-02 14:58:32 +02:00
Richard Smith 4d1b7e9820 Fix a few cases that were incorrectly parsed as unary-expressions
instead of postfix-expressions, and improve error recovery for postfix
operators after unary-expressions.

This covers nullptr, __null, and some calls to type traits with special
parsing rules. We would previously not parse a postfix-expression suffix
for these expressions, so would reject expressions such as
__is_trivial(int)["foo"].

For the case where a postfix-expression suffix is *not* permitted after
a unary-expression (for example, after a new-expression or sizeof
expression), produce a diagnostic if one appears there anyway. That's
always ill-formed, but previously produced very bad diagnostics.
2020-06-29 14:33:21 -07:00
Ahsan Saghir f4c337ab85 [PowerPC] Add support for vector bool __int128 for Power10
Summary:
This patch adds support for `vector bool __int128` type for Power10.

Reviewers: #powerpc, hfinkel, lei, stefanp, amyk

Reviewed By: #powerpc, lei, amyk

Subscribers: lei, amyk, wuzish, nemanjai, shchenz, cfe-commits

Tags: #llvm, #powerpc, #clang

Differential Revision: https://reviews.llvm.org/D81816
2020-06-23 21:25:56 -05:00
Yuanfang Chen 8c6c606cdc [Clang] Add a "#pragma unroll" test case for correct error reporting
For PR46336.
2020-06-16 13:03:32 -07:00
Haojian Wu 58ea1059df [AST][RecoveryExpr] Build recovery expressions by default for C++.
Reland https://reviews.llvm.org/D76696
All known crashes have been fixed, another attemption.

We have rolled out this to all internal users for a while, didn't see
big issues, we consider it is stable enough.

Reviewed By: sammccall

Subscribers: rsmith, hubert.reinterpretcast, ebevhan, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78350
2020-06-12 15:21:38 +02:00
Richard Smith 56a872947a Remove improper uses of DiagnosticErrorTrap and hasErrorOccurred.
DiagnosticErrorTrap is usually inappropriate because it indicates
whether an error message was rendered in a given region (and is
therefore affected by -ferror-limit and by suppression of errors if we
see an invalid declaration).

hasErrorOccurred() is usually inappropriate because it indicates
whethere an "error:" message was displayed, regardless of whether the
message was a warning promoted to an error, and therefore depends on
things like -Werror that are usually irrelevant.

Where applicable, CodeSynthesisContexts are used to attach notes to
the first diagnostic produced in a region of code, isnstead of using an
error trap and then attaching a note to whichever diagnostic happened to
be produced last (or suppressing the note if the final diagnostic is a
disabled warning!).

This is mostly NFC.
2020-06-08 14:19:57 -07:00
Zola Bridges 60ee885990 [clang][asm goto][slh] Warn if asm goto + SLH
Summary:
Asm goto is not supported by SLH. Warn if an instance of asm goto is detected
while SLH is enabled.

Test included.

Reviewed By: jyu2

Differential Revision: https://reviews.llvm.org/D79743
2020-05-20 09:46:18 -07:00
Hans Wennborg 87b235db63 Turn -Wmax-tokens off by default
On the one hand, one might interpret the use of the max-token pragmas or
-fmax-tokens flag as an opt-in to the warning. However, in Chromium
we've found it useful to only opt in selected build configurations, even
though we have the pragmas in the code. For that reason, we think it
makes sense to turn it off by default.

Differential revision: https://reviews.llvm.org/D80014
2020-05-18 13:21:46 +02:00
Melanie Blower 7f2db99350 [PATCH] #pragma float_control should be permitted in namespace scope.
Summary: Erroneous error diagnostic observed in VS2017 <numeric> header
Also correction to propagate usesFPIntrin from template func to instantiation.

Reviewers: rjmccall, erichkeane (no feedback received)

Differential Revision: https://reviews.llvm.org/D79631
2020-05-12 06:10:19 -07:00
Florian Hahn 1065869195 [Matrix] Add matrix type to Clang.
This patch adds a matrix type to Clang as described in the draft
specification in clang/docs/MatrixSupport.rst. It introduces a new option
-fenable-matrix, which can be used to enable the matrix support.

The patch adds new MatrixType and DependentSizedMatrixType types along
with the plumbing required. Loads of and stores to pointers to matrix
values are lowered to memory operations on 1-D IR arrays. After loading,
the loaded values are cast to a vector. This ensures matrix values use
the alignment of the element type, instead of LLVM's large vector
alignment.

The operators and builtins described in the draft spec will will be added in
follow-up patches.

Reviewers: martong, rsmith, Bigcheese, anemet, dexonsmith, rjmccall, aaron.ballman

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D72281
2020-05-11 18:55:45 +01:00
Richard Smith 8fc12b8698 Enforce the C++11 anonymous enum bitfields check even for
Objective-C++11 and under MS extensions.

This matches the MSVC behavior, and means that Objective-C behaves as a
set of extensions to the base language, rather than replacing the base
language rule with a different one.
2020-05-10 14:03:50 -07:00
Richard Smith 2d3f5a62de Fix typo in enum-base disambiguation. 2020-05-10 13:39:49 -07:00
Richard Smith d6425e2c14 Properly implement 'enum class' parsing.
The 'class' or 'struct' keyword is only permitted as part of either an
enum definition or a standalone opaque-enum-declaration, not as part of
an elaborated type specifier. We previously failed to diagnose this, and
generally didn't properly implement the restrictions on elaborated type
specifiers for enumeration types.

In passing, also fixed incorrect parsing for enum-bases, which we
previously parsed as a type-name, but are actually a type-specifier-seq.
This matters for cases like 'enum E : int *p;', which is valid as a
Microsoft extension.

Plus some minor parse diagnostic improvements.

Bumped the recently-added ExtWarn for 'enum E : int x;' to be
DefaultError; this is not an intentional extension, so producing an
error by default seems appropriate, but the warning flag to disable it
may still be useful for code written against old Clang. The same
treatment is given here to the diagnostic for 'enum class E x;', which
we similarly have incorrectly accepted for many years. These diagnostics
continue to be suppressed under -fms-extensions and when compiling
Objective-C code. We will need to decide separately whether Objective-C
should follow the C++ rules or the (older) MSVC rules.
2020-05-10 13:21:04 -07:00
Richard Smith c90e198107 Fix parsing of enum-base to follow C++11 rules.
Previously we implemented non-standard disambiguation rules to
distinguish an enum-base from a bit-field but otherwise treated a :
after an elaborated-enum-specifier as introducing an enum-base. That
misparses various examples (anywhere an elaborated-type-specifier can
appear followed by a colon, such as within a ternary operator or
_Generic).

We now implement the C++11 rules, with the old cases accepted as
extensions where that seemed reasonable. These amount to:
 * an enum-base must always be accompanied by an enum definition (except
   in a standalone declaration of the form 'enum E : T;')
 * in a member-declaration, 'enum E :' always introduces an enum-base,
   never a bit-field
 * in a type-specifier (or similar context), 'enum E :' is not
   permitted; the colon means whatever else it would mean in that
   context.

Fixed underlying types for enums are also permitted in Objective-C and
under MS extensions, plus as a language extension in all other modes.
The behavior in ObjC and MS extensions modes is unchanged (but the
bit-field disambiguation is a bit better); remaining language modes
follow the C++11 rules.

Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++
core issues 1514 and 1966.
2020-05-08 19:32:00 -07:00
Melanie Blower e5578013b1 When pragma FENV_ACCESS is ignored do not modify Sema.CurFPFeatures
Bug reported by @uabelho against reviews.llvm.org/D72841

Reviewers: rjmccall

Differential Revision: https://reviews.llvm.org/D79510
2020-05-06 13:18:59 -07:00
Melanie Blower c355bec749 Add support for #pragma clang fp reassociate(on|off)
Reviewers: rjmccall, erichkeane, sepavloff

Differential Revision: https://reviews.llvm.org/D78827
2020-05-06 08:05:44 -07:00
Melanie Blower f5360d4bb3 Reapply "Add support for #pragma float_control" with buildbot fixes
Add support for #pragma float_control

Reviewers: rjmccall, erichkeane, sepavloff

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

This reverts commit fce82c0ed3.
2020-05-04 05:51:25 -07:00
Melanie Blower fce82c0ed3 Revert "Reapply "Add support for #pragma float_control" with improvements to"
This reverts commit 69aacaf699.
2020-05-01 10:31:09 -07:00
Melanie Blower 69aacaf699 Reapply "Add support for #pragma float_control" with improvements to
test cases
Add support for #pragma float_control

Reviewers: rjmccall, erichkeane, sepavloff

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

This reverts commit 85dc033cac, and makes
corrections to the test cases that failed on buildbots.
2020-05-01 10:03:30 -07:00
Melanie Blower 85dc033cac Revert "Add support for #pragma float_control"
This reverts commit 4f1e9a17e9.
due to fail on buildbot, sorry for the noise
2020-05-01 06:36:58 -07:00
Melanie Blower 4f1e9a17e9 Add support for #pragma float_control
Reviewers: rjmccall, erichkeane, sepavloff

Differential Revision: https://reviews.llvm.org/D72841
2020-05-01 06:14:24 -07:00
Jian Cai fcbc613ad8 Make "#pragma clang attribute" support uninitialized attribute.
Summary:
When using -ftrivial-auto-var-init=* options to initiate automatic
variables in a file, to disable initialization on some variables,
currently we have to manually annotate the variables with uninitialized
attribute, such as

int dont_initialize_me __attribute((uninitialized));

Making pragma clang attribute to support this attribute would make
annotating variables much easier, and could be particular useful for
bisection efforts, e.g.

void use(void*);

void buggy() {
    int arr[256];
    int boom;
    float bam;
    struct { int oops; } oops;
    union { int oof; float aaaaa; } oof;

    use(&arr);
    use(&boom);
    use(&bam);
    use(&oops);
    use(&oof);
}

Reviewers: jfb, rjmccall, aaron.ballman

Reviewed By: jfb, aaron.ballman

Subscribers: aaron.ballman, george.burgess.iv, dexonsmith, MaskRay, phosek, hubert.reinterpretcast, gbiv, manojgupta, llozano, srhines, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78693
2020-04-23 14:25:13 -07:00
Erich Keane 5f0903e9be Reland Implement _ExtInt as an extended int type specifier.
I fixed the LLDB issue, so re-applying the patch.

This reverts commit a4b88c0449.
2020-04-17 10:45:48 -07:00
Sterling Augustine a4b88c0449 Revert "Implement _ExtInt as an extended int type specifier."
This reverts commit 61ba1481e2.

I'm reverting this because it breaks the lldb build with
incomplete switch coverage warnings. I would fix it forward,
but am not familiar enough with lldb to determine the correct
fix.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
2020-04-17 10:29:40 -07:00
Erich Keane 61ba1481e2 Implement _ExtInt as an extended int type specifier.
Introduction/Motivation:
LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax.
Integers of non-power-of-two aren't particularly interesting or useful
on most hardware, so much so that no language in Clang has been
motivated to expose it before.

However, in the case of FPGA hardware normal integer types where the
full bitwidth isn't used, is extremely wasteful and has severe
performance/space concerns.  Because of this, Intel has introduced this
functionality in the High Level Synthesis compiler[0]
under the name "Arbitrary Precision Integer" (ap_int for short). This
has been extremely useful and effective for our users, permitting them
to optimize their storage and operation space on an architecture where
both can be extremely expensive.

We are proposing upstreaming a more palatable version of this to the
community, in the form of this proposal and accompanying patch.  We are
proposing the syntax _ExtInt(N).  We intend to propose this to the WG14
committee[1], and the underscore-capital seems like the active direction
for a WG14 paper's acceptance.  An alternative that Richard Smith
suggested on the initial review was __int(N), however we believe that
is much less acceptable by WG14.  We considered _Int, however _Int is
used as an identifier in libstdc++ and there is no good way to fall
back to an identifier (since _Int(5) is indistinguishable from an
unnamed initializer of a template type named _Int).

[0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html)
[1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf

Differential Revision: https://reviews.llvm.org/D73967
2020-04-17 07:10:57 -07:00
Richard Smith bab6df86ae Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.
Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expression that could be a canonical template argument, it
could be a constant lvalue base object, and so on. In addition, we
represented the UUID value as a string, whose source form we did not
preserve faithfully, and that we partially parsed in multiple different
places.

With this patch, we create an MSGuidDecl object to represent the
implicit object of type 'struct _GUID' created by a UuidAttr. Each
UuidAttr holds a pointer to its 'struct _GUID' and its original
(as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves
like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue
representation of the GUID on the MSGuidDecl and use it from constant
evaluation where needed.

This allows removing a lot of the special-case logic to handle these
expressions. Unfortunately, many parts of Clang assume there are only
a couple of interesting kinds of ValueDecl, so the total amount of
special-case logic is not really reduced very much.

This fixes a few bugs and issues:
 * PR38490: we now support reading from GUID objects returned from
   __uuidof during constant evaluation.
 * Our Itanium mangling for a non-instantiation-dependent template
   argument involving __uuidof no longer depends on which CXXUuidofExpr
   template argument we happened to see first.
 * We now predeclare ::_GUID, and permit use of __uuidof without
   any header inclusion, better matching MSVC's behavior. We do not
   predefine ::__s_GUID, though; that seems like a step too far.
 * Our IR representation for GUID constants now uses the correct IR type
   wherever possible. We will still fall back to using the
      {i32, i16, i16, [8 x i8]}
   layout if a definition of struct _GUID is not available. This is not
   ideal: in principle the two layouts could have different padding.

Reviewers: rnk, jdoerfert

Subscribers: arphaman, cfe-commits, aeubanks

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78171
2020-04-15 12:20:42 -07:00
Haojian Wu 625acd8f68 [Parser] Improve diagnostic and error recovery when C++ keywords are used as identifiers.
Summary:
Previously, clang emitted a less-usefull diagnostic and didnt recover
well when the keywords is used as identifier in function paramter.

```
void foo(int case, int x); // previously we drop all parameters after
`int case`.
```

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77633
2020-04-08 15:15:33 +02:00
Richard Smith 6163aa9679 PR45239: Don't deallocate TemplateIdAnnotations if they might still be
in the token stream.

Previously we deleted all template-id annotations at the end of each
top-level declaration. That doesn't work: we can do some lookahead and
form a template-id annotation, and then roll back that lookahead, parse,
and decide that we're missing a semicolon at the end of a top-level
declaration, before we reach the annotation token. In that situation,
we'd end up parsing the annotation token after deleting its associated
data, leading to various forms of badness.

We now only delete template-id annotations if the preprocessor can
assure us that there are no annotation tokens left in the token stream
(or if we're already at EOF). This lets us delete the annotation tokens
earlier in a lot of cases; we now clean them up at the end of each
statement and class member, not just after each top-level declaration.
This also permitted some simplification of the delay-parsed templates
cleanup code.
2020-04-05 23:23:20 -07:00
Richard Smith 3308732300 Fix crash if base specifier parsing hits an invalid type annotation.
Also change type annotation representation from ParsedType to TypeResult
to make it clearer to consumers that they can represent invalid types.
2020-03-30 17:21:40 -07:00
Richard Smith 499b2a8d63 PR45294: Fix handling of assumed template names looked up in the lexical
scope.

There are a few contexts in which we assume a name is a template name;
if such a context is one where we should perform an unqualified lookup,
and lookup finds nothing, we would form a dependent template name even
if the name is not dependent. This happens in particular for the lookup
of a pseudo-destructor.

In passing, rename ActOnDependentTemplateName to just ActOnTemplateName
given that we apply it for non-dependent template names too.
2020-03-27 21:07:06 -07:00