`DifferentiableFunctionInst` now stores result indices.
`SILAutoDiffIndices` now stores result indices instead of a source index.
`@differentiable` SIL function types may now have multiple differentiability
result indices and `@noDerivative` resutls.
`@differentiable` AST function types do not have `@noDerivative` results (yet),
so this functionality is not exposed to users.
Resolves TF-689 and TF-1256.
Infrastructural support for TF-983: supporting differentiation of `apply`
instructions with multiple active semantic results.
When emitting the private swiftinterface, the compiler prints the
attribute explicitly even when it is deduced from the context. This can
lead to unparsable private swiftinterface files.
As a narrow fix, check if the decl type is supported before printing the
attribute.
rdar://64039069
We would previously hide the protocol, its extensions and members, but the '_'
prefix really just means the protocol itself isn't intended for clients, rather
than its members.
This also adds support for 'fully_annotated_decl' entries in doc-info for
extensions to be consistent with every other decl, and removes the
'fully_annotated_generic_signature' entry we supplied as a fallback.
Also fixes several bugs with the synthesized extensions mechanism:
- The type sustitutions applied to the extension's requirements were computed
using the extension itself as the decl context rather than the extension's
nominal. The meant the extension's requirements themselves were assumed to
hold when determining the substitutions, so equality constraints were always
met. Because of this extension members were incorrectly merged with the base
nominal or its extensions despite having additional constraints.
- Types within the requirements weren't being transformed when printed (e.g.
'Self.Element' was printed rather than 'T') both in the interface output and
in the requirements list. We were also incorrectly printing requirements
that were already satisfied once the base type was subsituted in.
- If both the protocol extension and 'enabling' extension of the base nominal
that added the protocol conformance had conditional requirements, we were
only printing the protocol extension's requirements in the synthesized
extension.
- The USR and annotated decl output embedded in the 'key.doc.full_as_xml'
string for synthesized members were printed to match their original context, rather than
the synthesized one.
Resolves rdar://problem/57121937
This part of a series of patches to bring ASTPrinter and Swift Demangler to
feature parity, which is needed by LLDB, which depends on using the strings
produced by either interchangibly.
rdar://problem/63700540
This attribute is intended to mean there's a replacement declaration that
should be used instead in Swift code. We already filter out decls with this
attribute in code completion, but were still exposing them in generated
interfaces.
Resolves rdar://problem/62464954
Now that the parser no longer constructs invalid TypeReprs for if-lets,
printing the annotation here will always reflect what the user actually
wrote.
rdar://62894516
It's treated as a keyword by syntactic highlighting, but wasn't annotated as a
keyword by code completion, cursor info, or doc info.
Resolves rdar://problem/61114942
This simplifies fixing the master-next build. Upstream LLVM already
has a copy of this function, so on master-next we only need to delete
the Swift copy, reducing the potential for merge conflicts.
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
When printing the generated interface of a module, also print the decls from
any underscored cross-import overlays it is the direct, or indirect underlying
module of. Declarations are grouped by overlay, with a descriptive `MARK:`
comment introducing each overlay, and a regular comment above each decl listing
the required bystander modules that must be imported for the decl to be
available.
In addition in each overlay:
- import declarations of any underlying modules are filtered out, since they
are either other underscored cross-import overlays, or the target module they
are being presented as being part of.
- import declarations that are also in the target module are filtered out, since
the overlay is being presented as a conditional part of the target module.
Resolves rdar://problem/59445385
When we are printing Swift interface, we have to skip the override keyword
if the overriden decl is invisible from the interface. Otherwise, an error
will occur while building the Swift module because the overriding decl
doesn't override anything.
We couldn't skip every `override` keywords because they change the
ABI if the overriden decl is also publicly visible.
For public-override-internal case, having `override` doesn't have ABI
implication. Thus we can skip them.
rdar://58562780
