The formal type of methods should be (Type) -> (Args...) -> (),
not Type -> (Args...) -> ().
This only matters in Swift 4 mode, where it was preventing the
newly-added test case from type checking.
Fixes <rdar://problem/31725325>.
A malformed initializer or increment expression would come out of TypeChecker::typeCheckExpression() with no type, which `checkIgnoredExpr()` was not expecting.
Fixes:
* test/Parse/foreach.swift
* test/Parse/recovery.swift
* test/Parse/toplevel_library_invalid.swift
* test/IDE/complete_stmt_controlling_expr.swift
* validation-test/compiler_crashers_fixed/01736-void.swift
* validation-test/compiler_crashers_fixed/00587-swift-pattern-foreachvariable.swift
When the initialization expression on a variable declaration fails, give it an ErrorType so Swift does not redundantly diagnose its un-inferrable type.
Fixes:
* test/NameBinding/stdlib.swift
* test/decl/typealias/protocol.swift
Would also have redundantly fixed the same tests as 2e875e7e, but the targeted solution there is cleaner.
This prevents one invalid declaration from causing cascades of subsequent errors.
Fixes:
* test/NameBinding/scope_map_lookup.swift
* test/decl/var/variables.swift
It is useful to set a breakpoint on ErrorType::get(ASTContext)
to see what is going wrong immediately instead of after the
fact when an ErrorType pops up where you don't expect it.
Unfortunately associated type inference, domain shrinking and
the type cleanup RAII utility would all build ErrorTypes even
with valid code.
Refactor things a bit so that this is no longer the case; at
least now the standard library and overlays build with
'assert(false)' inserted into ErrorType::get(ASTContext).
ErrorType::get(Type) is still expected to come up in associated
type inference since it is used as a signal while sorting
through potential type witness candidates.
The fix committed in 15fb957f09 still
allows for the possibility that we can bind one type as part of
processing the Equal constraint and then later come along and attempt to
bind the LValue version of that type as part of processing another
constraint.
I don't have a test case for this as it was discovered by thought
process, not testing, and constructing a test case isn't really feasible
because it relies on a lot of specifics about the order in which things
happen to be processed the constraint solver.
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
We had an inconsistency in the handling of ConstraintKind::Equal in that
we would take
$T1 Equal $T2
where $T2 was previously bound to a type, and bind the RValue type of
$T2's type to $T1. That does not allow for us to later attempt to bind
the LValue type of that type to $T1 (as might happen in simplifying an
OptionalObject constraint).
Instead, if $T1 can be bound to an LValue and $T2 is not an LValue,
we'll defer simplifying the Equal constraint until after $T1 is bound
through some other type variable binding or constraint simplification.
Fixes rdar://problem/31724272.
Uncovered by Slava's bcbd1d2, which infers 'dynamic' in more places,
but this was always a problem when an initializer was /explicitly/
marked 'dynamic'.
rdar://problem/32026930
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
This re-applies 361ab62454, reverted in
f50b1e73dc, after a /very/ long interval
where we decided if it was worth breaking people who've added these
conformances on their own. Since the workaround isn't too difficult---
use `#if swift(>=3.2)` to guard the extension introducing the
conformance---it was deemed acceptable.
https://bugs.swift.org/browse/SR-2388
While diagnosing index expression associated with subscript call
`validateContextualType` didn't look through TupleType to identify
potential nullability of the contextual type related to generic
parameters.
Resolves: rdar://problem/31724211
This fixes a case where we would allow a function conversion
in Swift 3 mode, but not in Swift 4. We were incorrectly stripping
off ParenTypes, which was OK in Swift 3, but with the implementation
of SE-0110 this resulted in a type mismatch.
Fixes <rdar://problem/31969605>.
We were not enforcing that operators were static if
the operator was defined in a final class, or if it
was defined in a non-final class but the operator was
itself final.
Fixes <rdar://problem/31469036>.
When performing a name lookup from inside of a protocol
or extension, skip directly to the source file context
when we are done visiting the protocol or extension.
Otherwise, if we have invalid code where the protocol
or extension is nested inside another type, we might
find a member whose type contains generic parameters
of the outer type; these parameters will not resolve,
since we do not model protocols or extensions nested
inside generic contexts (yet?).
This supercedes an earlier workaround for a similar
issue; the new workaround fixes more crashes.
This is needed to avoid crasher regressions with an
upcoming patch.
Previously situations like `self.foo(...)` wouldn't be considered as viable
for diagnosing the instance method on type calls, because the base wasn't
TypeExpr, which only accounts for e.g. `X.foo`, instead of validating base
expression itself this patch checks if the _type_ of base expression is
Metatype which is less restrictive.
Resolves: SR-4692.
CSGen can see an AssignExpr where the destination has an
unresolved type, even in a case where no diagnostic has been
emitted yet.
It is then wrong to return an empty type from here, because
this stops us from attempting to solve the expression, which
results in no diagnostic being emitted in the end.
The test case I added produces a decent diagnostic now,
but the original one in the radar now just says 'ambiguous
without more context'. Still, better than crashing.
Fixes <rdar://problem/30685195>.
Any ambiguity inside of a call with a trailing closure
call was going down the code path that would tell you to
add an argument label... but the ambiguity might not be
with the call that has the trailing closure itself, and
instead something inside.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This lets us serialize that decision, which means we can conceivably
/change/ the decision in later versions of the compiler without
breaking existing code. More immediately, it's groundwork that will
eventually allow us to drop decls from the AST without affecting
vtable layout.
This isn't actually a great answer; what we really want is for SIL
vtables to be serialized consistently and treated as the point of
truth. But that would be more change than we're comfortable taking in
the Swift 4 timeframe.
First part of rdar://problem/31878396.
Some APIs that expected a String now expect a Substring and vice
versa. To ease the transition, emit fix-its on conversion errors
between these types that the migrator can pick up.
When converting from Substring -> String, suggest wrapping in
`String.init`.
When converting from String -> Substring, suggest appending the
void subscript `[]`. (This isn't implemented yet so this is
hidden behind a flag).
This can possibly be generalized later when converting between
some sequence and its subsequence, such as Array and ArraySlice,
for example.
rdar://problem/31665649
rdar://problem/31666638
- Subscripts parameter lists may not contain inout arguments, but we
were rejecting this at the call site. Teach the type checker to reject
them during type resolution instead.
- We assumed a syntactic check for inout/var parameters would suffice
given that a parameter unified to an InoutType. However, closures
passed to function parameters with inout parameters in their parameter
lists can also cause this case to appear, and we would emit a
SourceLoc-less diagnostic. Instead, do not attempt this recovery path
if the user did not actually write ‘var’ or ‘inout’ on the parameter
type.
Swift 3 allowed a class to explicitly conform to AnyObject, although
it was meaningless. Recent AnyObject-related changes started rejecting
such conformances as ill-formed; allow them with a warning + Fix-It in
Swift 3 compatibility mode.
When we have a potential assignment of associated types to type
witnesses during associated type inference, check that set of type
witnesses against the requirements in the requirement signature, so
that we can reject any solutions that fail some of the protocol's
requirements.
This is most of rdar://problem/31830524 --- but gets thwarted by the
inability of associated type inference to work across multiple
protocols.
Make this routine suppress diagnostics when there is no
source-location information (which allows it to be used as a query)
and to distinguish the "we couldn't substitute into a requirement"
failure mode from the "a requirement actually failed" failure mode.
Infer @_staticInitializeObjCMetadata in those cases where we need a
static initializer to make an NSCoding-conforming class visible to the
Objective-C runtime. This does *not* include classes with one of the
@NSKeyedArchive attributes:
* @NSKeyedArchiveLegacy implies that we'll register the class
directly, with the necessary side effect of initialize Objective-C
metadata.
* @NSKeyedArchiveSubclassesOnly promises not to archive the class
directly anyway.
Introduce the @NSKeyedArchiveSubclassesOnly attribute, which can be
placed on a class that conforms to NSCoding to suppress the
unstable-name diagnostics by promising to only archive
subclasses---not this class directly.
The diagnostic regarding NSCoding classes with unstable names can be
suppressed by adding @objc (the preferred solution for new code) or
@NSKeyedArchiveLegacy (for existing archives). Provide those as
Fix-Its, in that order.
(Thanks, Jordan!)
Currently inactive, this attribute indicates that a static initializer should be emitted to register the Objective-C metadata when the image is loaded, rather than on first use of the Objective-C metadata. Infer this attribute for NSCoding classes that won’t have static Objective-C metadata or have an @NSKeyedArchiveLegacy attributed.
