The reason why is that we want to distinguish inbetween SILFunction's that are
marked as unspecified by SILGen and those that are parsed from textual SIL that
do not have any specified isolation. This will make it easier to write nice
FileCheck tests against SILGen output on what is the inferred isolation for
various items.
NFCI.
This just eliminates -enable-sil-ownership from all target-swift-frontend and
target-swift-emit-silgen RUN lines. Both of those now include
enable-sil-ownership in their expansion.
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.
For long names this is easier to read and in most cases the omitted information can be seen in the actual SIL code.
With the option -Xllvm -sil-full-demangle the old behavior can be restored.
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
Change all the existing addressors to the unsafe variant.
Update the addressor mangling to include the variant.
The addressor and mutable-addressor may be any of the
variants, independent of the choice for the other.
SILGen and code synthesis for the new variants is still
untested.
Swift SVN r24387
Note that the demangling for 'a' accessors changes from
'addressor' to 'mutableAddressor'. This is correct for
the existing use-case of global variables, which permit
modification through the result.
Swift SVN r22254
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
The implied semantics are:
- side-effects can occur any time before the first invocation.
- all calls to the same global_init function have the same side-effects.
- any operation that may observe the initializer's side-effects must be
preceded by a call to the initializer.
This is currently true if the function is an addressor that was lazily
generated from a global variable access. Note that the initialization
function itself does not need this attribute. It is private and only
called within the addressor.
Swift SVN r16683
