...since they're part of the run-time representation. Not having this
meant that someone compiling against an interface would miscompile
uses of @objc enums defined in that interface!
rdar://problem/50410541
Previously, we wouldn't escape `Type` and `Protocol` at all in the
ASTPrinter, which lead to unfortunate build failures while compiling an
interface.
Instead, make sure we escape them whenever we print a name that's a type
member. Except for methods, which are erroneously allowed to be called
`Type` and `Protocol`.
rdar://49858651
When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
To represent the abstracted interface of an opaque type, we need a generic signature that refines
the outer context generic signature with an additional generic parameter representing the underlying
type and its exposed constraints. Opaque types also need to be keyed by their originating decl, so
that we can treat values of the same opaque type as the same. When we check a FuncDecl with an
opaque type specified as its return type, create an OpaqueTypeDecl and associate it with the
originating decl. (A representation for *types* derived from the opaque decl will come next.)
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
Once the '@escaping' bit is removed from TupleTypeElt, it no longer makes
sense to print argument lists as if they were TupleTypes or ParenTypes,
since function types are '@escaping' by default inside tuples but not
in argument lists.
Instead, print ArrayRef<AnyFunctionType::Param> directly. For now this
introduces some awkward usages of AnyFunctionType::decomposeInput();
these will go away once the AST is changed to represent the argument list
as a list of expressions and not a single tuple expression.
Turns out this isn't correct, since SROA can explode these structs into
scalars in inlinable code.
Put the logic in place to effectively disable it, and document the steps
we need to take to make it work in the future.
Fixes various places where we assume that only a VarDecl can be static so they operate on any AbstractStorageDecl instead. NFC until static subscripts are added.
Otherwise we can get in trouble when a local type is named, say,
'Sequence'.
Also contains test updates and a fix for Harlan's previous commit,
which actually affects all typealiases, not just those in the Builtin
module.
(as described in the previous commit)
When printing an interface that has to be stable, we need to use the
module name that identifies where declarations should be searched for,
just like we do with serialization.
rdar://problem/49114811
These changes allow to optionally perform a very fast build that is targeted to only produce the syntax parser library.
Part of addressing rdar://48153331
The getLocStart API is deprecated and slated for removal from LLVM
very soon. Switch to use getBeginLoc instead. I did not see any uses
of the corresponding getLocEnd API.
Previously, we would print multi-line string literals with single quotes, which were not re-parseable. Instead, re-escape their contents and print them out escaped.
For lazy vars, we need to make public the top-level entry point, and the fact
that the lazy storage contributes to the layout of a type (if it’s fixed
layout, or if the type is not resilient.) We also shouldn’t ever print `lazy`
in a parseable interface.
Since we need to parse these identifiers, give them a new name,
`$__lazy_storage_$_{propname}`, which is parseable only in parseable interfaces
so it doesn’t conflict with other properties.
Instead of only printing through the pattern binding, and potentially missing stored properties with property observers, defer to the pattern binding for all stored properties, and print accessors if applicable while printing pattern bindings.
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
We want to make sure we are consistent when printing accessors.
@jrose-apple and I landed on the following table for disambiguating all
the possible combinations of accessors:
\### Computed Properties
| Semantics | Syntax |
|------------|------------------------|
| Read-only | var x: T { get } |
| Read-write | var x: T { get set } |
\### Stored Properties
| Semantics | Syntax |
|--------------------------|-------------------------------------|
| Immutable | let x: T |
| Mutable (trivial setter) | var x: T |
| Mutable (custom setter) | @_hasStorage var x: T { get set } |
| Private(set) | @_hasStorage var x: T { get } |
This first commit enables printing @_hasStorage outside of SIL mode.
