Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
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.
When the compiler fails to find an overload with suitable parameter or return types, it often attaches a note listing the available overloads so that users can find the one they meant to use. The overloads are currently ordered in a way that depends on the order they were declared, so swift-evolve would sometimes cause tests involving these diagnostics to fail.
This change emits the list in a textually-sorted order instead. The names were already being sorted as they were inserted into a std::set, so this shouldn’t significantly slow down the diagnostic.
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
Since arbitrary currying is no longer allowed `level` could
be replaced with the boolean flag which identifies if curried
`self` should be skipped or not.
When `CandidateCalleeInfo` tries to create a candidate for expression
in form of `<base>.<func>` it shouldn't assume that function type of
'<func>' would always be at curry level 1, because base could be ignored
when it is a module or 'b' refers to a static function.
Resolves: rdar://problem/45242032
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
That is, don't look through InOutType anymore, and update callers to
call getInOutObjectType() as well (or not, where it was obvious to me
that InOutType could not appear).
This surfaces more remaining uses of getInOutObjectType() directly.
Pass constraint system down into offering force unwrap fixits so that we can identify the type of the last member chosen for an optional chain. If there's a chain and the last member's return type isn't optional, then it's cleaner to offer to change that last '?' into a '!' to perform the force, rather than parenthesize the whole expression and force the result.
Unresolved types are formed in a few specific places within the type
checker's recovery path; don't let them bleed into the substitution
logic. Fixes rdar://problem/42448618.
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
* Improve label mismatch callback:
- Split "missing label" callback into 3 - missing, extraneous, incorrect (with typo(s));
- Allow label callbacks to indicate if it's a fatal error or not;
* Improve matching of the variadic parameters;
* Improve matching of the parameters with defaults;
* Try to look for an argument with matching label before fallback to
forced claming (if allowed).
Replace the last (and most obscure) use of the poor “use ‘?’ or ‘!’” diagnostic with the
new, more explanatory version that provides separate notes with Fix-Its for coalescing or
force-unwrapping the value.
Finishes rdar://problem/42081852.
When diagnosing ApplyExpr, the existing implementation
tries to resolve the function subexpression independently
in the first place, without considering the argument
information. As a result, such resolved function type
may not produce the best diagnostic message.
This patch adds condideration of the number of arguments
to decide the better function subexpression for diagnostic
purpose.
Resolves: SR-7918, SR-7786, SR-7440, SR-7295, SR-5154.
A type checker instance isn’t needed for most of the “override” checking,
so remove the TypeChecker parameters and instead get the ASTContext or
DiagnosticEngine from whatever decl or type is available. Another step
toward reducing dependency on a TypeChecker instance.
Refactor the interface to return a bit vector. Along the way, fix up
the callers and remove some dead usages of the defaults information
that were copied and pasted around Sema.
* [Diagnostics|SR-5789] Added fixits for referring to subscripts by keyword
If there is a subscript member, the error message changes to [type -bash has no member property or method named 'subscript']
The fix-it replaces parentheses with brackets, removes '.subscript'
If the apply expression is incomplete, e.g. subscript(..., the fix-it adds a bracket at the end.
* tests updated & logic for compatible arg types (except generics)
* ignore generic types & switch to returning
* avoid explicitly using sting literals
* handle implicit conversion of tuples & encapsulate it
* isolate subscript misusage
* return bool instead of void
* move function to FailureDiagnosis, diagnose independently & update error message
* Update CSDiag.cpp
When binding an optional value, or function that returns an optional
value, if that value was produced from a decl that was declared an
IUO, create a disjunction.
After solving, make use of the disjunction choices in rewriting
expressions to force optionals where needed.
This is disabled for now, as it results in a source compatibility
issue without associated changes that actually start generating
Optional<T> in place of ImplicitlyUnwrappedOptional<T>. It's
complicated, but basically having two '??' (one returning T, one
returning T?) and creating a disjunction where the first (favored)
choice is ImplicitlyUnwrappedOptional<T> and second is T results in
our selecting the wrong '??' in some cases.
Use this in places where we have a decl that is marked with the
ImplicitlyUnwrappedOptionalAttr so that we can distinguish in the
solver which decls need to be potentially unwrapped in order to type
check successfully.
