The scale test says the behavior is exponential, but it should be
linear, given that (1) we provide a contextual type outside and
(2) there is precisely 1 type which has the corresponding cases.
Misaligned indices were fixed in 5.1, but we should disable the test
when testing back deployment.
Adds a shared helper to StdlibUnittest for the run time check.
If a Mach-O image got emitted in just the wrong way, the range of `__TEXT,__swift*` sections to
read could end up starting at an unaligned address (because things like type refs have only one
byte alignment), and this would cause the reflection context to read an unaligned chunk of the
remote memory, causing alignment errors when addresses are mapped to the local copy. Keep the ranges
at least 8-byte-aligned to stave off the alignment issues we might run into with any metadata
structures, which are generally at most pointer aligned. Fixes rdar://problem/54556791
This means that we no longer have the invariant that the extendedType always
contains the generic parameters. So we need to fix the assertions/test cases
for it.
Instead of visiting all members of all types and extensions, bail out
early if the type is not a class or protocol, or the extension is not
extending a class. This means we don't visit structs, enums or
protocol extensions at all, which will avoid delayed parsing.
Also, we were evaluating isObjC() on each member, which is an expensive
operation; if the member does not have an explicit @objc we would still
have to check if it overrides an @objc method or witnesses an @objc
protocol requirement.
Since most members are not ever found by dynamic lookup, this is wasted
work. Instead, let's rely on AnyObject lookup filtering non-@objc
members at the call site, which it was already doing anyway.
It is possible that the rest of the platforms are relying in some not
clearly documented behaviour that the stdout is flushed before stderr
can be used, or something similar. Windows didn't seem to like that, and
was sometimes outputting the stderr messages interlaced with the stdout
messages (specially in the Azure testing for VS2017). The initial
solution was adding -DAG to some CHECK lines, but that doesn't cover all
the possibilities, and wasn't enabled for all the checks.
I tried to fix it in several ways, but none of them were perfect, and
many of them were deadlocking. There's a fundamental difference between
others and Windows and that is that for others stdout seems to have a
little bit of an edge in being treated first. I tried to get the Windows
code closer to that idea, but I have no luck. Some of the approaches
were using the main thread to read from the threads reading stdout and
stderr; using only the main thread and IOCP on the pipes reading from
the child process; and flushing after every output to stdout. None of
them were perfect.
The final solution is a hack, but it seems to not fail when I run the
test repeatedly in my machine, while other approaches were failing at
least once before I discarded them. The solution is including a small
sleep (1 millisecond) in the Windows code. This should yield the
execution time slice to other thread/process, which seems to do the
trick and keep the stdout before the stderr.
Hopefully this fixes the errors in Azure, and doesn't affect the rest of
the testing machines. Being a really small sleep also should not affect
the duration of the test itself.
Each candidate with incorrect labels (but everything else lined up)
gets a note on its declarationm which says what is expected and what
has been given.
For multiple solutions with fixes for the same call, replace
`ambiguous reference` diagnostic with the one that explicitly
mentions that there are no exact matches, and provide partially
matched candidates as notes.
Unresolved imports all have the "same" ModuleDecl: nullptr. But that's
not really an inconsistency, and even if there *is* a true
inconsistency among unresolved imports, it can be dealt with when the
developer fixes their search paths. (Or the imports. Whichever is
wrong.)
rdar://problem/52943397
Now that SILGen and IRGen can trigger type checking work, we have to run the
full pipeline to get a complete picture.
Thankfully everything still passes!
Since getStoredProperties() is a request that lowers lazy properties
and property wrappers to their underlying storage, and SIL can validate
stored property and enum element types, there's no longer any need for
Sema to explicitly finalize members of structs and enums. SILGen can
trigger any necessary type checkin work just by lowering a struct or
enum type.
Now the only remaining reason we need finalizeDecl() is adding implicit
methods to classes, and synthesizing accessors for storage in classes
and protocols.
