Callers were either just passing
choice.getKind() == OverloadChoiceKind::DeclViaDynamic
or passing false. Inline the check into the function
and assert for callers that don't expect a decl
from dynamic lookup.
We're planning to emit these attributes in module interfaces, but until
we land that patch, we want to parse these attributes and ignore them.
Part of rdar://51249311
We need this attribute to teach compiler to use a different name from the current
module name when generating runtime symbol names for a declaration. This is to serve
the workflow of refactoring a symbol from one library to another without breaking the existing
ABI.
This patch focuses on parsing and serializing the attribute, so @_originallyDefinedIn
will show up in AST, swiftinterface files and swiftmodule files.
rdar://55268186
The `hasInterfaceType()` check should only be used for cycle breaking, and in
this case was preventing us from properly establishing the capabilities of
a property wrapper.
Fixes rdar://problem/57350503 and several dupes.
Some constraint transformations require knowledge about what state
constraint system is currently in e.g. `constraint generation`,
`solving` or `diagnostics` to make a decision whether simplication
is possible. Notable example is `keypath dynamic member lookup`
which requires a presence of `applicable fn` constraint to retrieve
some contextual information.
Currently presence or absence of solver state is used to determine
whether constraint system is in `constraint generation` or `solving`
phase, but it's incorrect in case of `diagnoseFailureForExpr` which
tries to simplify leftover "active" constraints before it can attempt
type-check based diagnostics.
To make this more robust let's introduce (maybe temporarily until
type-check based diagnostics are completely obsoleted) a proper
notion of "phase" to constraint system so it is always clear what
transitions are allowed and what state constraint system is
currently in.
Resolves: rdar://problem/57201781
Constraint application was rewriting conditional casts (as?) and
forced casts (as!) into coercions (as) at the AST level when it
determined that there was a coercion. Stop doing that: it's the
optimizer's job to remove such casts.
Rather than spinning up a new constraint system when performing an "as"
coercion, perform the coercion with the known solution, because we
already did all of the work to figure out how to perform the coercion.
This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
The new file contains the implementation of typeCheckDecl() and
various utility functions that it uses. This code runs for
declarations in primary files only.
TypeCheckDecl.cpp now mostly consists of evaluate() implementations
for requests together with some utility functions.
A few of the new function prototypes I added to TypeCheckDecl.h
are indicative of some code that could be refactored further.
Any utility functions shared by both TypeCheckDecl.cpp and
TypeCheckDeclPrimary.cpp should be wrapped up in requests in
order for the results to be cached.
Instead of always attempting an optional unwrap fix if types differ
in optionality, let's make it more targeted for each applicable
locator and conversion.
In addition adjust a couple of uses of `ForceOptional` fix to avoid
recording the same fix multiple times and use appropriate `impact`
instead.
Record both sides of conversion where a form of force unwrap is
necessary to be able to produce tailored diagnostics such as for
an attempt to use optional type as a boolean.
