Mangler::mangleEntity() correctly handles accessors these days, so
by calling mangleAccessorEntity() from SILGenConformance, we were just
skipping the 'Z' modifier if the accessor was static...
As a result, generating a conformance to such a protocol tried to emit
duplicate SIL functions.
Fixes <rdar://problem/21426579>.
Swift SVN r29601
The other part of rdar://problem/21444126. This is a little trickier since SIL doesn't track uses of witness tables in a principled way. Track uses in SILGen by putting a "SILGenBuilder" wrapper in front of SILBuilder, which marks conformances from apply, existential erasure, and metatype lookup instructions as used, so we can avoid emitting shared Clang importer witnesses when they aren't needed.
Swift SVN r29544
Now that we properly track inherited conformances and don't re-emit the inherited conformance in every translation unit that asks for it, this is no longer necessary or correct. The necessary conformances for a file should be emitted while visiting the types in that file, and trying to recursively emit their dependencies introduces duplicate symbols. Fixes rdar://problem/21107266.
Swift SVN r29093
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
instead of being an expression.
To the user, this has a couple of behavior changes, stemming from its non-expression-likeness.
- #available cannot be parenthesized anymore
- #available is in its own clause, not used in a 'where' clause of if/let.
Also, the implementation in the compiler is simpler and fits the model better. This
fixes:
<rdar://problem/20904820> Following a "let" condition with #available is incorrectly rejected
Swift SVN r28521
Use the Module from the associated decl instead of using getStdlibModule, which sometimes produces null for -parse-stdlib tests, and is probably wrong.
Swift SVN r28380
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
Instead of immediately creating closures for local function declarations and treating them directly as capturable values, break function captures down and transitively capture the storage necessary to invoke the captured functions. Change the way SILGen emits calls to closures and local functions so that it treats the capture list as the first curry level of an invocation, so that full applications of closure literals or nested functions don't require a partial apply at all. This allows references among local functions with captures to work within the existing confines of partial_apply, and also has the nice benefit that circular references would work without creating reference cycles (though Sema unfortunately rejects them; something we arguably ought to fix.)
This fixes rdar://problem/11266246 and improves codegen of local functions. Full applications of functions, or immediate applications of closure literals like { }(), now never need to allocate a closure.
Swift SVN r28112
emit{StrongRelease,ReleaseValue} => emit{StrongRelease,ReleaseValue}AndFold.
Then introduce a new method emit{StrongRelease,ReleaseValue} that returns a
PointerUnion containing the increment to be deleted if it exists. This obviates
the need for the callback.
Swift SVN r27804
SGF::emitLocalVariable: inline it into its only remaining client (which is
indirectly part of 'var' pattern binding emission) and simplify the code a bit.
NFC.
Swift SVN r27531
- Privatize "kind" in the base Initialization class.
- Simplify canForwardInBranch() to just isSingleBuffer().
There is only one client of it (which avoids emitting the
formation of an optional temporary) and the only cases we're
dropping is for "_" patterns and single element tuple patterns,
which are not worth optimizing for.
- Change getSubInitializationsForTuple() into a virtual method
since it has wildly different behavior based on the subclass and
requires otherwise private implementation details of those subclasses
to implement it.
- Simplify subclasses based on these changes.
Swift SVN r27463
- Use virtual dispatch to localize some predicates instead
of having special cases for LetValue inits in global places.
- Improve 'const'ness of methods.
- Introduce a common "KnownAddressInitialization" class to centralize
the notion of an initialization corresponding to a specific physical
address that is known up front. Consolidate dupes of this concept into
uses of it.
NFC.
Swift SVN r27462
don't run the cleanup for the enum if the failure path can only contain
trivial enum element matches. For example, on:
class Base {}
func test_is(a : Base?) {
let x? = a else { abort() }
}
we previously emitted:
switch_enum %0 : $Optional<Base>, case #Optional.Some!enumelt.1: bb2, default bb1 // id: %3
bb1: // Preds: bb0
release_value %0 : $Optional<Base> // id: %4
br bb3 // id: %5
which is silly because the release_value is always dynamically a no-op (the
.None element of an enum is always trivial).
Swift SVN r27460
We were previously emitting the 'else' block on a let-else after emitting the patterns bound, which
would cause cleanups for the bound patterns to be run on entry to the else. This doesn't make sense
because those have already been torn down by the failure path in the conditional pattern binding.
Fix this by emitting the 'else' code up front, before any of the patterns are bound.
Swift SVN r27451
As a result, when we're able to devirtualize calls to these functions
we'll also be able to inline all the way down to the user function.
Swift SVN r27136
kind of pattern for let/else. While I haven't done extensive testing, I believe
that let/else is wired up and working now.
Please feel free to kick the tires on let/else and file radars if you run into problems.
The only piece that I know is missing is support for is/as patterns (which will fail on
an llvm_unreachable).
Swift SVN r27135
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
register a DestroyLocalVariable cleanup: it will be a noop. Getting it out
of the apparently active set of cleanups allows us to avoid emitting empty
blocks in some cases.
Swift SVN r27049
This is necessary for correctly dealing with non-standard
ownership conventions in secondary positions, and it should
also help with non-injective type imports (like BOOL/_Bool).
But right now we aren't doing much with it.
Swift SVN r26954
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
