mode (take 2)
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
When generating constraints for an iterated sequence of type T, emit
T convertible to $T1
$T1 conforms to SequenceType
instead of
T convertible to SequenceType
This ensures that an untyped placeholder in for-each sequence position
doesn't get inferred to have type SequenceType. (The conversion is still
necessary because the sequence may have IUO type.) The new constraint
system precipitates changes in CSSimplify and CSDiag, and ends up fixing
18741539 along the way.
(NOTE: There is a small regression in diagnosis of issues like the
following:
class C {}
class D: C {}
func f(a: [C]!) { for _: D in a {} }
It complains that [C]! doesn't conform to SequenceType when it should be
complaining that C is not convertible to D.)
<rdar://problem/21167372>
(Originally Swift SVN r31481)
The properties of a context indicate those things that are considered
"contained within" the context (among other things). This helps us
avoid producing overly-generic names when we identify a redundancy in
the base name. For example, NSView contains the following:
var gestureRecognizers: [NSGestureRecognizer]
func addGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
func removeGestureRecognizer(gestureRecognizer: NSGestureRecognizer)
Normally, omit-needless-words would prune the two method names down to
"add" and "remove", respectively, because they restate type
information. However, this pruning is not ideal, because a view isn't
primarily a collection of gesture recognizers.
Use the presence of the property "gestureRecognizers" to indicate that
we should not strip "gestureRecognizer" or "gestureRecognizers" from
the base names of methods within that class (or its subclasses).
Note that there is more work to do here to properly deal with API
evolution: a newly-added property shouldn't have any effect on
existing APIs. We should use availability information here, and only
consider properties introduced no later than the entity under
consideration.
We already had isLValue(), which implied !isMaterializable().
Now, add separate flags for hasInOut() and hasDefaultArg().
The old isMaterializable() predicate is still provided,
by testing for all three flags.
The new predicates are not used for now, but will be soon
as part of reabstraction thunk changes required for resilience.
Also two fixes:
1) Before this change RecursiveTypeProperties was incorrectly
sized at 8 bits when it actually needs 9. This fixes a regression
from SVN r31130, "Introduce a new UnresolvedType to the type system".
2) DynamicSelf::get() would clear out non-materializability
but not lvalue-ness of its base type, which looks like an old
copy/paste and not intentional. Stick an assert there instead.
This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
When the first parameter of a function has Boolean type, try to create
an argument label for it. We start with the (normally non-API)
parameter name as the argument label, then try to match that against
the end of the base name of the method to eliminate redundancy. Add a
little magic, and here are some diffs:
- func openUntitledDocumentAndDisplay(_: Bool) throws -> NSDocument
+ func openUntitledDocument(display _: Bool) throws -> NSDocument
- func fontMenu(_: Bool) -> NSMenu?
- func fontPanel(_: Bool) -> NSFontPanel?
+ func fontMenu(create _: Bool) -> NSMenu?
+ func fontPanel(create _: Bool) -> NSFontPanel?
- func lockFocusFlipped(_: Bool)
+ func lockFocus(flipped _: Bool)
- func rectForSearchTextWhenCentered(_: Bool) -> NSRect
+ func rectForSearchText(whenCentered _: Bool) -> NSRect
- func dismissPreviewAnimated(_: Bool)
- func dismissMenuAnimated(_: Bool)
+ func dismissPreview(animated _: Bool)
+ func dismissMenu(animated _: Bool)
Swift SVN r32392
Extend GenericSignature to be able to answer queries about the
requirements placed on dependent types, e.g, are the class-bound, to
what protocols must they conform, etc. Implement this using a
lazily-created ArchetypeBuilder on the canonical generic signature.
NFC and as-yet-untested; this is staging for reducing our dependence
on the "all archetypes" list.
Swift SVN r32340
GenericSignature's factory method determining whether the signature
was canonical based solely on whether the types in the parameters and
requirments were canonical. While that is currently true (for legacy
reasons), it is wrong: canonicalization also needs to canonicalize
requirements, including same-type requirements, as is currently done
in the canonical signature "for mangling". Move the "this is
canonical" dependency to the point where the canonical signature is
actually computed, so we can change the definition of canonical
signatures later.
While we're here, don't eagerly compute the canonical generic
signature in GenericSignature::getASTContext().
Swift SVN r32309
When completing at the sequence position of for each statment (for i in <HRER> {}),
values of sequence type should have higher priority than the rest.
Swift SVN r32202
Allow untyped placeholder to take arbitrary type, but default to Void.
Add _undefined<T>() function, which is like fatalError() but has
arbitrary return type. In playground mode, merely warn about outstanding
placeholders instead of erroring out, and transform placeholders into
calls to _undefined(). This way, code with outstanding placeholders will
only crash when it attempts to evaluate such placeholders.
<rdar://problem/21167372> transform EditorPlaceholderExpr into fatalError()
Swift SVN r31481
We need to be able to introduce and eliminate existentials inside
reabstraction thunks, so make this logic independent of RValue
and Expr emission.
NFC for now.
Swift SVN r31375
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31105
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
(Undoing revert r30961 of r30957, which just required lockstep commit to
SourceKit -- cwillmore)
Swift SVN r30962
This reverts r30957 because it broke the following tests on Jenkins:
SourceKit :: CodeComplete/complete_open.swift
SourceKit :: CodeComplete/complete_test.swift
<rdar://problem/22120345> swift-incremental-RA #8289 failed to build
Swift SVN r30961
When a user invoke code completion after import keywords, the names of
visible top level clang modules were recommended for finishing the import decl.
Swift SVN r30957
Also, checking protocol conformances doesn't depend on any members, just the type.
We don't track dependencies on types separately from members right now, though,
so instead there's now a dummy dependency on 'deinit'.
Swift SVN r30288
The stdlib uses this condition to recognize types that represent classes without representation changing, which isn't true for metatypes. They will natively be pointers to the Swift type metadata instead of the ObjC class object, so a conversion step is necessary. This doesn't directly fix container bridging, but it prevents the runtime from trying to bridge verbatim metatypes without first changing them to ObjC representation.
Swift SVN r29998
Add getUIntDecl(), getFloatDecl() and getDoubleDecl(), change
getIntDecl() and getBoolDecl() to cache the result, and clean up
duplication. NFC
Progress on <rdar://problem/21215099>.
Swift SVN r29969
The isDependentType() query is woefully misunderstood. Some places
seem to want it to mean "a generic type parameter of dependent member
type", which corresponds to what is effectively a type parameter in
the language, while others want it to mean "contains a type parameter
anywhere in the type". Tease out these two meanings in
isTypeParameter() and hasTypeParameter(), respectively, and sort out
the callers.
Swift SVN r29945
We have no way of materializing such a value because we store the
default argument expression in the Decl and not in the Type.
Fixes <rdar://problem/20424776>.
Swift SVN r29921
While the archetype builder is constructing archetypes, it eagerly
produces the set of nested archetypes for each archetype. If the
construction of any of those nested archetypes refers to another
archetype, we would fail unceremonerously with an assertion. Fill in
the nested type names (but not their actual types) eagerly, allowing
the actual types to be determined lazily.
This is plumbing for rdar://problem/21620908, which still trips an
unrelated assertion, preventing a useful testcase at this step.
Swift SVN r29841
We diagnose usage of invalid existential types but we might still
try to compute substitutions. Just whip up an ErrorType instead.
Fixes <rdar://problem/16803384>.
Swift SVN r29567
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
This time, fix a paste-o that caused SILBlockStorageTypes to get replaced with SILBoxTypes during type substitution. Oops.
Swift SVN r29489
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
Swift SVN r29474
This prevents us from seeing a less useful error message from SILGen
further down the line.
Also fix a bug where @objc without importing Foundation was not diagnosed
after the first top-level form. Some tests were relying on this behavior,
so fix those tests, either by splitting off the objc parts of the test, or
just by passing the -disable-objc-attr-requires-foundation-module flag.
Fixes <rdar://problem/20660270>.
Swift SVN r29359
I didn't add anything to the table, just made use of what was already there.
We have plenty of additional calls to getIdentifier that could probably benefit
from this kind of easy access as well.
This commit also removes FOUNDATION_MODULE_NAME and OBJC_MODULE_NAME from
Strings.h. Neither of these is likely to change in the future, and both
already have KnownIdentifiers equivalents in use.
No intended functionality change.
Swift SVN r29292
- Remove unused names.
- Define IDENTIFIER in terms of IDENTIFIER_WITH_NAME.
- Adjust each name to always match the corresponding value in case.
- Add an IDENTIFIER_ macro for the common case of defining an underscored name.
- Avoid creating names with double underscores, which are technically reserved
by the C++ standard.
There are two special cases I left in here for the identifiers '_code' and
'_domain'. I didn't want to call these simply 'Id_code' and 'Id_domain' for
fear someone would try to use them as 'code' and 'domain', so I made them into
'Id_code_' and 'Id_domain_' for now.
No intended functionality change.
Swift SVN r29291
We only attempt to access such nested types in ill-formed code, but
this helps maintain AST invariants. Fixes rdar://problem/20593294 and
resolves 18 compiler crashers.
Swift SVN r29135
This allows @objc enum error types produced in Objective-C (e.g., via
+[NSError errorWithDomain:code:userInfo:]) to be bridged back to their
original enum types in Swift via pattern matching/catch blocks.
This finishes rdar://problem/20577517.
Swift SVN r28803
