A lot of files transitively include Expr.h, because it was
included from SILInstruction.h, SILLocation.h and SILDeclRef.h.
However in reality most of these files don't do anything
with Exprs, especially not anything in IRGen or the SILOptimizer.
Now we're down to 171 files in the frontend which depend on
Expr.h, which is still a lot but much better than before.
For example, if an internal type conforms to a public protocol, the witness table should get internal linkage.
Previously we only considered the visibility of the protocol.
Fragile witness tables still have to get public symbol linkage. This is now handled in IRGen (like we do it for functions).
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
Don't hardcode linkage of default witness thunks, addressing a FIXME.
This will allow us to emit default witness thunks for requirements of
internal protocols, too.
As there are no instructions left which produce multiple result values, this is a NFC regarding the generated SIL and generated code.
Although this commit is large, most changes are straightforward adoptions to the changes in the ValueBase and SILValue classes.
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
Getting the protocols of an arbitrary type doesn't make sense, so start phasing this out by introducing specialized entry points that do make sense:
- get the inherited protocols of a ProtocolDecl
- get the conforming protocols for an associated type or generic
type parameter
- (already present) ask for the protocols to which a nominal type conforms
Swift SVN r26411
A type in an extension doesn't inherit linkage from its parent. In particular, if an extension adds a nested type to an imported class, we don't want that nested type to have unique linkage. Fixes rdar://problem/19792174.
Swift SVN r25191
Instead, just fall through to the normal public/internal/private switch
added in the previous commit. Local declarations are always private.
Make sure we emit all local declarations by using the list in the SourceFile,
rather than walking the AST (which missed a few cases and was less efficient
anyway).
As an exception, declarations without accessibility at all still get private
linkage. These are things like local variables that don't get accessed by
symbol, even when using the debugger.
rdar://problem/19623016
Swift SVN r24839
Easy cut down on exported symbols. Unless a private type is referenced in
an inlineable function, there's no way to generate a reference to it
outside of the current file, except in the debugger. (That last bit is why
we can't use fully private linkage, which would keep the symbol out of the
symbol table completely.)
We should be doing this for "internal" declarations as well, but the
standard library /does/ have references to internal types in inlineable
functions, and also has tests that directly access these types.
Swift SVN r24838
We ignore casts when generating projection paths for alias analysis. When
comparing two paths, we say no alias when accessing different fields of
the same Decl Context.
Swift SVN r20353
Also stripCasts in findAddressProjectionPathBetweenValues.
We can now move "load of an invariant field" out of the loop even though we
have "store to a different field" in the loop.
Performance:
O3 -----
Phonebook 4367 3866 -11.4724%
Ofast ------
NBody 1623 1292 -20.3943%
EditDistance 3043 2589 -14.9195%
Swift SVN r20327
This always wrapped a single GenericTypeParamDecl *, and provided no benefit
over just using the decl directly.
No (intended) functionality change.
Swift SVN r19628
Teach IRGen to honor the linkage of SILWitnessTables, and teach SILGen to emit witness tables and protocol witness thunks for external definitions with shared linkage. Fixes <rdar://problem/16264703>.
Swift SVN r14908
We should also remove it from IRGen's Explosion API; IRGen
should always use maximal explosion, and SILGen will tell us
whether or not we need to put that in memory somewhere.
But that can be a later commit.
Swift SVN r14242
Instead for vardecls, we use the index of the field in the structdecl itself as
a stable ordering of vardecls.
I validated that the indeterminism was gone by running the failing test 1000
times in a row. Doug and I were hitting the indeterminism with well less than
100 iterations before, so I feel the number of iterations is sufficient.
Swift SVN r13859
