The "typechecked function body" request was defined to type-check a
function body that is known to be present, and not skipped, and would
assert these conditions, requiring its users to check whether a body
was expected. Often, this means that callers would use `getBody()`
instead, which retrieves the underlying value in whatever form it
happens to be, and assume it has been mutated appropriately.
Make the "typechecked function body" request, triggered by
`getTypecheckedBody()`, more resilient and central. A `NULL` result is
now acceptable, signifying that there is no body. Clients will need to
tolerate NULL results.
* When there is no body but should be one, produce an appropriate
error.
* When there shouldn't be a body but is, produce an appropriate error
* Handle skipping of function bodies here, rather than elsewhere.
Over time, we should move clients off of `getBody` and `hasBody`
entirely, and toward `getTypecheckedBody` or some yet-to-be-introduced
forms like `getBodyAsWritten` for the pre-typechecked body.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
Matching logic in the ASTPrinter. Otherwise we attempt to mangle types with archetypes in them, which cannot be done, and causes the compiler to crash.
Resolves rdar://113039215
names. It can often be more complex than the code can currently handle (e.g.
properties whose types include archetypes), and we
do not have a good motivating use-case to extract them.
Resolves rdar://113039215
To reduce duplication of logic with other parts of the compiler, instead of destructuring the constraint type, write the requirements in the opaque type declaration's generic signature.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
This change adds to the extracted type metadata the following fields:
- Conformances: this is a list of all protocols that the given nominal type conforms to
- associated type aliases: this is a list of all associated types across all conformances that the given nominal type substitutes with concrete types. For a given associated type, we gather:
- Associated type name
- Substituted type's fully-qualified name
- Substituted type's mangled name
- If the substituted type is opaque:
- List of conformance requirements of this opaque type
- List of same-type requirements of this opaque type
The intended design is to extract actual types of type values appearing in conformance properties, whereas the original extraction code-path queried and recorded the type values' types - their metatypes.
Resolves rdar://108609420
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
