At some point this test case was updated such that it no longer
compiled successfully. The originally reported test case did compile
successfully, just slowly.
A bunch of .swiftinterface files fail to build into their respective .swiftmodules
if you pass -module-name <foo> for some foo that is not the correct module name.
The two tests in this change were using a shell expansion that incorrectly picked
the first path component with a period in the name as the module name; this caused
the failures.
Rather than using a shell expansion, this change uses the 2-argument form of
basename(1) (which is POSIX) that also removes a suffix from the basename.
This counts the number of leaf scopes we reach while solving the
constraint sytem, and is a much better measure of the growth of
unnecessary work than the total number of scopes opened.
There were two tests where I had a difficult time getting scale-test
to fit the curve even after adjusting some of the parameters, so I've
left those to use the old stat for now.
Have the constraint solver consider multiple designated types for an
operator. We currently consider the overloads from each in turn,
stopping as soon as we have a solution. As a result, we can still end
up with exponential type checking in some cases if an operator has
more than a single designated type. This still allows us to reduce the
base of that exponent, though, which makes it possible to increase the
number of expressions we can type check successfully in practice.
Currently (with or w/o failures) constraint system is not returned
back to its original state after solving, because constraints from
initial "active" list are not returned to the system. To fix that
let's allocate "initial" scope which captures state right before
solving begins, and add "active" list to the solver state to capture
information about "active" constraints at the time of its creation.
This is follow-up to https://github.com/apple/swift/pull/19873
Create a new RuntimeUnittest library alongside the other stdlib unit
tests so we can write C++ runtime unit tests callable from lit.
Move runtime exclusivity tests into the stdlib unittest library and
create lit tests so we can verify that the runtime crashes with an
error message.
Remove the compiler support for exclusivity warnings.
Leave runtime support for exclusivity warnings in non-release builds
only for unit testing convenience.
Remove a test case that checked the warning log output.
Modify test cases that relied on successful compilation in the
presence of exclusivity violations.
Fixes: <rdar://problem/45146046> Remaining -swift-version 3 tests for exclusivity
There is an invariant that SignatureConformances should have the same
size as the number of conformance requirements in the signature.
Previously, since unsatisfied requirements weren't reflected in it,
that caused a crash.
rdar://problem/43625800
Thanks to @slavapestov for pointing this out! The optimization to avoid
looking through the members of a protocol that can’t possibly have any
associated types was for both deserialized protocols and imported
protocols, but I only supported the former in my previous change. Check
both cases and make the reasons much more obvious.
Also, that change resolved an existing compiler crasher as well.
Rather than limiting this to protocols, allow any nominal type.
Rename -enable-operator-designated-protocols to
-enable-operator-designated-types to reflect the change.
As an optimization, we don't even look for associated types in @objc
protocols. However, this could lead to broken invariants like "every
associated type has a witness" in ill-formed @objc protocols that do
have associated types.
Implement this optimization by checking whether the protocol has a
Clang node. Fixes rdar://problem/41425828 / SR-8094.
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
For operators with default implementations in an extension, we don't
want to typecheck it both with overloads from the protocol type and
the ones from the extension.
These are cases that I know are faster when this is enabled. The test
updates all additionally disable the existing performance hacks as
well as the shrink phase of the solver.