Now that the previous patches have shaken out implicit assumptions
about the order of generic requirements and substitutions, we can
make a more radical change, dropping redundant protocol requirements
when building the original generic signature.
This means that the canonical ordering and minimization that we
used to only perform when building the mangling signature is done
all of the time, and hence getCanonicalManglingSignature() can go
away.
Usages now either call getCanonicalSignature(), or operate on the
original signature directly.
Move the sorting algorithm from construction of the canonical mangling
signature to requirement enumeration.
This also changes how same-type constraints pick representatives, using
the more canonical total order.
The code here should not type check, because we're adding a requirement to
an outer archetype.
I'm working on some changes to ArchetypeBuilder that will make this kind
of thing easier to catch.
Add minimized test for rdar://problem/27830834.
In a build with asserts enabled assert with:
(TypeVariables[impl.getGraphIndex()] == typeVar && "Type variable mismatch")
We could support this in the future but right now it's causing problems.
There's also a potential ambiguity issue here where a protocol and class
could have the same name.
In addition to updating the importer, remove the two entries from the
CryptoTokenKit API notes that were trying to use this feature.
rdar://problem/27990168
This reverts commit dc0ae675bc. The
change here (presumably the change to Foundation) caused a regression
in several of the bridging-related benchmarks, e.g.,
ObjectiveCBridgeFromNSSetAnyObjectToString, DictionaryBridge,
ObjectiveCBridgeFromNSDictionaryAnyObjectToString.
Add test case for crash triggered in `swift::TypeBase::getCanonicalType(...)`.
Current number of unresolved compiler crashers: 55 (5156 resolved)
Assertion failure in [`include/swift/AST/Type.h (line 241)`](https://github.com/apple/swift/blob/master/include/swift/AST/Type.h#L241):
```
Assertion `isActuallyCanonicalOrNull() && "Forming a CanType out of a non-canonical type!"' failed.
When executing: swift::CanType::CanType(swift::TypeBase *)
```
Assertion context:
```
static CanType getLValueOrInOutObjectTypeImpl(CanType type);
static ClassDecl *getClassBoundImpl(CanType type);
public:
explicit CanType(TypeBase *P = 0) : Type(P) {
assert(isActuallyCanonicalOrNull() &&
"Forming a CanType out of a non-canonical type!");
}
explicit CanType(Type T) : Type(T) {
assert(isActuallyCanonicalOrNull() &&
"Forming a CanType out of a non-canonical type!");
```
Stack trace:
```
swift: /path/to/swift/include/swift/AST/Type.h:241: swift::CanType::CanType(swift::TypeBase *): Assertion `isActuallyCanonicalOrNull() && "Forming a CanType out of a non-canonical type!"' failed.
8 swift 0x00000000011536e2 swift::TypeBase::getCanonicalType() + 2370
14 swift 0x000000000109a2de swift::Stmt::walk(swift::ASTWalker&) + 78
15 swift 0x0000000000f03b35 swift::TypeChecker::computeCaptures(swift::AnyFunctionRef) + 549
19 swift 0x000000000109a2de swift::Stmt::walk(swift::ASTWalker&) + 78
20 swift 0x0000000000f03b35 swift::TypeChecker::computeCaptures(swift::AnyFunctionRef) + 549
22 swift 0x0000000000efb4a1 swift::performTypeChecking(swift::SourceFile&, swift::TopLevelContext&, swift::OptionSet<swift::TypeCheckingFlags, unsigned int>, unsigned int, unsigned int) + 1281
23 swift 0x0000000000c7b5b9 swift::CompilerInstance::performSema() + 3289
25 swift 0x00000000007db487 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2887
26 swift 0x00000000007a72b8 main + 2872
Stack dump:
0. Program arguments: /path/to/swift/bin/swift -frontend -c -primary-file validation-test/compiler_crashers/28402-swift-typebase-getcanonicaltype.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -module-name main -o /tmp/28402-swift-typebase-getcanonicaltype-e8cf35.o
<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
```
Add test case for crash triggered in `?`.
Current number of unresolved compiler crashers: 54 (5156 resolved)
Stack trace:
```
<unknown>:0: error: unable to execute command: Segmentation fault
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
```
When we are able to type check an expression this assert is fine,
although of little value. In the context of failed type checks, though,
it can be actively harmful.
The issue is that we can attempt to solve smaller parts of the
constraint system and assign contextual types (e.g. for the arguments of
a function) despite not being able to drill into members.
Some of the diagnostics we emit in these cases are not terribly useful,
and I've opened rdar://problem/27982012 with one example.
Resolves:
rdar://problem/25812474
rdar://problem/26589865
rdar://problem/27974638
Remove the functions
_(set|dictionary)Bridge(From|To)ObjectiveC(Conditional) from the
standard library. These entrypoints are no longer used by the compiler
(thanks to generalized collection up/downcasting), so stop using them
in Foundation and in tests.
Add test case for crash triggered in `swift::irgen::emitPolymorphicParameters(...)`.
Current number of unresolved compiler crashers: 52 (5156 resolved)
Assertion failure in [`lib/IRGen/GenProto.cpp (line 1810)`](https://github.com/apple/swift/blob/master/lib/IRGen/GenProto.cpp#L1810):
```
Assertion `targetDepType->isTypeParameter()' failed.
When executing: void addPotentialArchetypeAccessPath(swift::irgen::IRGenFunction &, swift::CanType, swift::CanType, GetTypeParameterInContextFn)
```
Assertion context:
```
case SILFunctionTypeRepresentation::Thick:
case SILFunctionTypeRepresentation::Thin:
case SILFunctionTypeRepresentation::Method:
return ty->isPolymorphic();
case SILFunctionTypeRepresentation::CFunctionPointer:
case SILFunctionTypeRepresentation::ObjCMethod:
// May be polymorphic at the SIL level, but no type metadata is actually
// passed.
return false;
```
Stack trace:
```
swift: /path/to/swift/lib/IRGen/GenProto.cpp:1810: void addPotentialArchetypeAccessPath(swift::irgen::IRGenFunction &, swift::CanType, swift::CanType, GetTypeParameterInContextFn): Assertion `targetDepType->isTypeParameter()' failed.
10 swift 0x000000000087bd49 swift::irgen::emitPolymorphicParameters(swift::irgen::IRGenFunction&, swift::SILFunction&, swift::irgen::Explosion&, swift::irgen::WitnessMetadata*, llvm::function_ref<llvm::Value* (unsigned int)> const&) + 1033
12 swift 0x00000000008b35d4 swift::irgen::IRGenModule::emitSILFunction(swift::SILFunction*) + 1268
13 swift 0x0000000000810c95 swift::irgen::IRGenerator::emitGlobalTopLevel() + 405
15 swift 0x00000000007ea0a4 swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, unsigned int) + 68
17 swift 0x00000000007db487 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2887
18 swift 0x00000000007a72b8 main + 2872
Stack dump:
0. Program arguments: /path/to/swift/bin/swift -frontend -c -primary-file validation-test/compiler_crashers/28399-getpointerelementtype-is-not-storagetype.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -module-name main -o /tmp/28399-getpointerelementtype-is-not-storagetype-cd8726.o
1. While emitting IR SIL function @_TTWV4main1HS_1ES_FS1_1guRd__S_1Awx1Fzwd__1BrfGVS_1Cqd___T_ for 'g' at validation-test/compiler_crashers/28399-getpointerelementtype-is-not-storagetype.swift:19:1
<unknown>:0: error: unable to execute command: Aborted
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
```
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).
https://bugs.swift.org/browse/SR-2388
Use that instead of rolling it up in _SwiftTypePreservingNSNumber so that we
get the right behavior when we go to write plists.
https://bugs.swift.org/browse/SR-2381
Add test case for crash triggered in `?`.
Current number of unresolved compiler crashers: 50 (5156 resolved)
Stack trace:
```
<unknown>:0: error: unable to execute command: Segmentation fault
<unknown>:0: error: compile command failed due to signal (use -v to see invocation)
```
The Objective-C type encoding of Boolean values in NSNumber is that of
BOOL, which is either signed char or _Bool depending on the
platform. _SwiftTypePreservingNSNumber was using _Bool, which led to
inconsistencies when bridging vs. creating an NSNumber directly. Use
BOOL consistently.
Fixes rdar://problem/27894308.
