When Objective-C interop is enabled, modules will continue to be referred to as “Objective-C modules”. But when interop is disabled, they will be referred to as “C modules”.
Updated the existing test for the current behavior that doesn’t expect to fail on linux and doesn’t require objc_interop, so that it checks to different diagnostics on the two systems.
Adds the runtime implementation for copy-on-write existentials. This support is
enabled if SWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS is defined. Focus is on
correctness -- not performance yet.
Don't use allocate/deallocate/projectBuffer witnesses for globals in cow
existential mode.
Use SWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS configuration to set the default for
SILOptions.
This includes an IRGen fix to use the right projection in
emitMetatypeOfOpaqueExistential if SWIFT_RUNTIME_ENABLE_COW_EXISTENTIALS is set.
Use unknownRetain instead of native retain in dynamicCastToExistential.
rdar://problem/21193574 says that this warning dates back to when closure args before default args used to be considered as trailing closures. This is not the case anymore so Jordan suggested we remove the warning.
In the general case, this is done by reverse engineering the "best"
places for requirements to go from the requirement signature.
Conformance/superclass requirements like Self: Foo and Self.T: Bar defer
to the inheritance clause if they appear there, or are attached to the
protocol where clause or T (respectively) if not. A conformance
requirement like Self.T.U: Baz will go on T (if T is declared in the
protocol being printed).
Same-type requirements always go in where clauses, and specifically a
where clause of an associated type that is mentioned in them, so
something simple like Self.T.U == Int goes on the T associated type
definition, and similarly Self.T.U == Self.V will go on V (it's kinda
nonsense, but also more directly connected to V). There's a left-bias
for cases without an "obvious" choice, meaning something more
complicated like Self.T.U == Foo<Self.V> will end up on T.
Requirements that don't fit elsewhere will go on the
protocol (e.g. Self.AssocTypeFromSuperProtocol == Int).
Previously often times when casting a value, we would just pass along the
cleanup of the uncasted value. With semantic SIL this is no longer correct since
the cleanup now needs to be on the cast result.
This caused problems for certain usages of Builtin.castToNativeObject(...) by
the stdlib. Specifically, the stdlib was using this on AnyObject values that
were not necessarily native. Since we were recreating the cleanup on the native
value, a swift native release was being used =><=.
In this commit I solve this problem by:
1. Adding an assert in Builtin.castToNativeObject(...) that ensures that any value
passed to Builtin.castToNativeObject() is known conservatively to use swift
native reference counting.
2. I changed all uses where we do not have a precondition of a native ref
counting type to use Builtin.castToUnknownObject(...).
3. I added a new Builtin called Builtin.unsafeCastToNativeObject(...) that does
not have the compile time check. I used this to rewrite callsites in the stdlib
where we know via preconditions that an AnyObject will dynamically always be
native.
rdar://29791263
A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
The new DeclBaseName type will later be able to hold either normal
identifiers (as they exist now) or special names that don't have an
identifier (like subscripts)
When a requirement source involving a ProtocolRequirement element is
built prior to the requirement signature of the protocol it
references, we can end up with a requirement source whose steps don't
reflect was is actually available via the requirement signatures. When
building a conformance access path from such requirement sources,
canonicalize on-the-fly using the requirement signatures (which have
been/can be computed by this point) to produce a correct access path.
If a generic type appears in a generic function, the old
gatherAllSubstitutions() method would map outer generic
parameters to archetypes.
However, getContextSubstitutionMap() did not map them to
anything.
I'm trying to unify these methods, so add an optional
GenericEnvironment to getContextSubstitutionMap() to support
the cases where they're needed.
Of course types in generic functions are not supported right
now, but not preserving this subtle behavioral difference
makes some crashers regress.
SourceKit always sets it positively. This may lead to more aggressive fixits however
less informative messages. We currently use the flag only for filling protocol stubs.
ASTContext::getSpecializedConformance() already copies the
substitutions, so remove some AllocateCopy() calls.
Also, add a new overload taking a SubstitutionMap instead.
This allows removing some gatherAllSubstitutions() calls,
which have an allocation inside them.
Finally, remove the now-unused ModuleDecl parameter from
ProtocolConformance::subst() and make it public.
Commands like -emit-sil and -emit-module (on its own) do not produce object files.
When -embed-bitcode is also set, the driver runs a backend job to generate a module that fails.
This commit emits a warning instead and ignores the -embed-bitcode option.
https://bugs.swift.org/browse/SR-3352
In some cases, the type checker will produce error types with the
"original type" intact for recovery purposes. Like other types, when
the original type contains a type variable, the ErrorType instance
will be allocated in the "temporary" memory arena associated with the
active constraint solver, because there's no way that particular error
will come up again once the constraint system containing that type
variable has been destroyed.
However, we weren't propagating that "contains a type variable"
information to the newly-created ErrorType, which meant that any type
/containing/ that ErrorType would be allocated in the "permanent"
arena. In practice, this would always be a DependentMemberType; not
too many types are created without looking at their base types at all.
The arena containing the ErrorType would then be deallocated, and its
memory reused later on for a /different/ type. If we ever tried to
make a DependentMemberType whose base was this new type, we'd find the
old DependentMemberType instance in our cache and return that. The
result was that we'd have a DependentMemberType whose "HasError" bit
was set even though the base type was not an error type, and which was
considered canonical whether or not the base type was. This would then
either hit an assertion later on or result in nonsensical errors like
"'C.Iterator' is not the same type as 'C.Iterator'".
Because the reused address always referred to a valid type, none of
the usual dynamic analysis tools could catch the problem. It really
comes down to using a pointer address as a key in a map---but even
without that, we were allocating types in the permanent arena that
really should be temporary, which is a waste of memory.
Likely fixes rdar://problem/30382791, a nondeterministic failure we've
been seeing for weeks on the bots and on developer machines.
