The SILGen testsuite consists of valid Swift code covering most language
features. We use these tests to verify that no unknown nodes are in the
file's libSyntax tree. That way we will (hopefully) catch any future
changes or additions to the language which are not implemented in
libSyntax.
This replaces the '[volatile]' flag. Now, class_method and
super_method are only used for vtable dispatch.
The witness_method instruction is still overloaded for use
with both ObjC protocol requirements and Swift protocol
requirements; the next step is to make it only mean the
latter, also using objc_method for ObjC protocol calls.
The CHECK lines are too restrictive under different optimization.
Disable the test to unblock the buildbots. Filed rdar://problem/33495516
to pick it up again later.
Previously we ran into problems where this test used API notes for the
'gizmo' module and other tests did not, leading to potentially-invalid
information being cached in Clang's module cache. That might actually
no longer be an issue because textual API notes are now included
directly, but even so it's cleaner to just have a dedicated module for
this.
rdar://problem/28313536
Textual SIL was sometimes ambiguous when SILDeclRefs were used, because the textual representation of SILDeclRefs was the same for functions that have the same name, but different signatures.
Textual SIL was sometimes ambiguous when SILDeclRefs were used, because the textual representation of SILDeclRefs was the same for functions that have the same name, but different signatures.
This was disabled after one of the pass pipeline changes resulted in the
test failing only in certain configurations (unoptimized stdlib
build). Previously, the same test had been updated for other pipeline
changes, but the more recent pipeline changes made the previous updates
unnecessary.
This change reverts those previous updates, and adds new updates to deal
with changes that have happened since the test was
disabled (specifically signature optimization firing in some cases where it
wasn't before).
Re-apply b00dcbe with a small test update, and a small change in pass
ordering.
I measure around a 10% reduction in compile times of release no-assert
builds of the stdlib and StdlibUnitTest.
For release + debug-swift builds, I see 20% reduction in stdlib compile
time.
My latest measurements show a few regressions at -O:
Calculator
NSError
SetIsSubsetOf
Sim2DArray
There is a small (0.1%) reduction in the libswiftCore.dylib size.
Being able to remove these is a consequence of the reordering that
happened in e50daa6.
And include some supplementary mangling changes:
- Give the first generic param (depth=0, index=0) a single character mangling. Even after removing the self type from method declaration types, 'Self' still shows up very frequently in protocol requirement signatures.
- Fix the mangling of generic parameter counts to elide the count when there's only one parameter at the starting depth of the mangling.
Together these carve another 154KB out of a debug standard library. There's some awkwardness in demangled strings that I'll clean up in subsequent commits; since decl types now only mangle the number of generic params at their own depth, it's context-dependent what depths those represent, which we get wrong now. Currying markers are also wrong, but since free function currying is going away, we can mangle the partial application thunks in different ways.
Swift SVN r32896
This improves support for promoting to and generating
unchecked_ref_cast so we no longer need unchecked_ref_bit_cast, which
will just go away in the next commit.
Swift SVN r32597
And also adapt a whole set of SIL passes so that they can deal with (the not deleted) debug_value instructions.
This was required to prevent perforamnce and code size regressions.
Now the generated code is (almost) the same as before.
The effect of this change is that we keep debug_value/debug_value_addr also in optimized code (more or less).
Fixes rdar://problem/18709125.
Swift SVN r28872
Semantic analysis should be guaranteeing that all conformances that
show up in the AST are complete. Until that day, work around the crash
in rdar://problem/20700616 by not specializing.
Swift SVN r27886
"similar", avoiding false positive "not exhaustive" diagnostics on switches
like:
switch ... {
case let x?: break
case .None: break
}
Also, start using x? patterns in the stdlib more (review appreciated!), which
is what shook this issue out.
Swift SVN r26004
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
This is needed for tests which define internal functions which should not be eliminated.
So far this was not needed because of a hack which prevented whole-module-optimizations for tests.
Swift SVN r22658
Now the SILLinkage for functions and global variables is according to the swift visibility (private, internal or public).
In addition, the fact whether a function or global variable is considered as fragile, is kept in a separate flag at SIL level.
Previously the linkage was used for this (e.g. no inlining of less visible functions to more visible functions). But it had no effect,
because everything was public anyway.
For now this isFragile-flag is set for public transparent functions and for everything if a module is compiled with -sil-serialize-all,
i.e. for the stdlib.
For details see <rdar://problem/18201785> Set SILLinkage correctly and better handling of fragile functions.
The benefits of this change are:
*) Enable to eliminate unused private and internal functions
*) It should be possible now to use private in the stdlib
*) The symbol linkage is as one would expect (previously almost all symbols were public).
More details:
Specializations from fragile functions (e.g. from the stdlib) now get linkonce_odr,default
linkage instead of linkonce_odr,hidden, i.e. they have public visibility.
The reason is: if such a function is called from another fragile function (in the same module),
then it has to be visible from a third module, in case the fragile caller is inlined but not
the specialized function.
I had to update lots of test files, because many CHECK-LABEL lines include the linkage, which has changed.
The -sil-serialize-all option is now handled at SILGen and not at the Serializer.
This means that test files in sil format which are compiled with -sil-serialize-all
must have the [fragile] attribute set for all functions and globals.
The -disable-access-control option doesn't help anymore if the accessed module is not compiled
with -sil-serialize-all, because the linker will complain about unresolved symbols.
A final note: I tried to consider all the implications of this change, but it's not a low-risk change.
If you have any comments, please let me know.
Swift SVN r22215
r21096 introduces an optimization barrier for failing initializers
that allows the pattern
let x: NSFoo? = NSFoo()
be used to detect whether NSFoo() returned nil, even though the type
system says it cannot. Extend this check to Objective-C methods and
properties, where the non-optional annotation may be incorrect
<rdar://problem/17984530>.
Swift SVN r21176
