Introduce _BitInt, deprecate _ExtInt

WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitI

Introduce _BitInt, deprecate _ExtInt

WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:

* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.

I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.

show more ...

Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent."

This change leaves us unable to distinguish between different function
templ

Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent."

This change leaves us unable to distinguish between different function
templates that differ in only instantiation-dependent ways, for example

template<typename T> decltype(int(T())) f();
template<typename T> decltype(int(T(0))) f();

We'll need substantially better support for types that are
instantiation-dependent but not dependent before we can go ahead with
this change.

This reverts commit e3065ce238475ec202c707f4c58d90df171626ca.

show more ...

DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent.

Previously reverted in 34e72a146111dd986889a0f0ec8767b2ca6b2913;
re-committed with a

DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent.

Previously reverted in 34e72a146111dd986889a0f0ec8767b2ca6b2913;
re-committed with a fix to an issue that caused name mangling to assert.

show more ...

Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not"

This reverts commit 638867afd4bce4a2c56dea041299428af3727d61.

This is part of 5 commits being reverted due to https

Revert "DR2064: decltype(E) is only a dependent type if E is type-dependent, not"

This reverts commit 638867afd4bce4a2c56dea041299428af3727d61.

This is part of 5 commits being reverted due to https://crbug.com/1161059. See bug for repro.

show more ...

DR2064: decltype(E) is only a dependent type if E is type-dependent, not
if E is merely instantiation-dependent.

[clang] Fix the incorrect dependence bits for DependentExtIntType.

The error-bit was missing, and the unexpandedpack bit seemed to be
set incorrectly.

Reviewed By: sammccall, erichkeane

Differenti

[clang] Fix the incorrect dependence bits for DependentExtIntType.

The error-bit was missing, and the unexpandedpack bit seemed to be
set incorrectly.

Reviewed By: sammccall, erichkeane

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

show more ...

[AST][RecoveryExpr] Add error-bit to NestNameSpecifierDependence and TemplateNameDependence.

Summary:
We might lose the error-bit if the error-bit goes through the code path
"error type/expr" -> "er

[AST][RecoveryExpr] Add error-bit to NestNameSpecifierDependence and TemplateNameDependence.

Summary:
We might lose the error-bit if the error-bit goes through the code path
"error type/expr" -> "error template argument" -> "nested name specifier" ->
... -> "template Specialization type"

Template name also needs this, as a template can be nested into
an error specifier, e.g. templateName apply in
`TC<decltype(<recovery-expr>(Foo, int()))>::template apply`

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[AST][RecoveryExpr] Make DeduceAutoType fail if the auto is deduced from recovery exprs.

Summary:
With recovery-ast, we will get an undeduced `auto` return type for
"auto foo()->undef()" function de

[AST][RecoveryExpr] Make DeduceAutoType fail if the auto is deduced from recovery exprs.

Summary:
With recovery-ast, we will get an undeduced `auto` return type for
"auto foo()->undef()" function declaration, the function decl still keeps
valid, it is dangerous, and breaks assumptions in clang, and leads crashes.

This patch invalidates these functions, if we deduce autos from the
return rexpression, which is similar to auto VarDecl.

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[AST] Fix a crash on invalid bitwidth exprs when preserving the recoveryexprs.

Summary:
If the bitwith expr contains errors, we mark the field decl invalid.

This patch also tweaks the behavior of O

[AST] Fix a crash on invalid bitwidth exprs when preserving the recoveryexprs.

Summary:
If the bitwith expr contains errors, we mark the field decl invalid.

This patch also tweaks the behavior of ObjCInterfaceDecl to be consistent with
existing RecordDecl -- getObjCLayout method is only called with valid decls.

Reviewers: sammccall

Subscribers: cfe-commits

Tags: #clang

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

show more ...