fix the build. This isn't a proper fix (we should start putting out new attributes
on llvm::Function's, but getting the build working again seems important.
Swift SVN r6584
"SILConstant" doesn't really describe its role in SIL anymore, which is to provide a reference to a Swift declaration in a SIL instruction, such as a method or nominal type field.
Swift SVN r6559
We're redesigning enums, and the current implementation isn't really
handled in the module format (since it uses the presence or absence of
a source location to decide if a oneof element is "enum-like"). We'll
just drop this from the debug info for now.
This reverts r6462 / 9ed7fb3e70ff2cb9f08524699e89643386e8b6e0.
Swift SVN r6529
Since our modules currently have no source information, we're stuck using
the fallback filename for anything imported, including the standard library.
This makes variables.swift a little weaker, but there's not much we can do
about that. It's better than running off the end of a string, at least.
Swift SVN r6528
This unfortunately duplicates the hack of directly referencing the Clang
module loader if a cross-reference points to the current module; ideally
we'd have some kind of module chain, but I'd settle for a refactoring of
the code to share with NameBinding.
Additionally, Clang nodes are not actually validated to be from the right
module, which could be problematic for extensions or any case of actual
name collision.
Swift SVN r6519
Have WitnessBuilder awkwardly ask SIL's TypeConverter to uncurry witness types, so that polymorphic arguments get emitted in the right order consistent with lowered SILFunctions, instead of doing the uncurrying itself directly from the Swift type. This is layer-violating as hell but gets generic witness codegen working. I have a feeling SILGen will want to take over witness thunk emission at some point.
Swift SVN r6401
If a protocol requirement is satisfied by a generic method, we'll need to save the substitutions necessary to call that method from the witness thunk. This patch adds the spot in the ProtocolConformance::Mapping to save the substitutions; for now, always leave it empty and update the code for the type change.
Swift SVN r6399
When an existential's contained type is used as a generic parameter, unwrap the existential container and save its metadata and witnesses to be used as polymorphic arguments.
Our AST representation can't quite express the distinction between a type parameter being satisfied by the existential type itself from being satisfied by the existential's contained yet. I use a goofy heuristic where I assume a protocol type bound to a type variable with no requirements is satisfied by the protocol type itself; this covers all of the existing <T> (Slice<T>, T) cases that come up in the library, while enabling the <T:Foo> (T) cases. This hopefully addresses <rdar://problem/14470097> well enough to unblock library work until we get a solid AST representation of this difference.
Swift SVN r6352
As per Chris's suggestion (review of r6152), further refactored SILLocation not to derive from PointerUnion3 but to include it as a member.
In addition, added some template magic to make sure we don't have to chain dyn_casts, which I suspect will be/is happening a lot with SILLocation:
Ex:
- if (auto E = Func.dyn_cast<Expr*>()) {
- if (const FuncExpr *FE = dyn_cast<FuncExpr>(E))
- return SILLocation(FE->getBody())
+ if (const FuncExpr *FE = Func.getAs<FuncExpr>())
+ return SILLocation(FE->getBody());
Swift SVN r6283
