MDModule was a bitcode-incompatible internal-only extension that has
since been replaced with a blessed IR node on trunk.
<rdar://problem/20965932> Upstream DIModule and support it in clang-700, swiftlang-700, and lldb-700
Swift SVN r29832
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
This time, fix a paste-o that caused SILBlockStorageTypes to get replaced with SILBoxTypes during type substitution. Oops.
Swift SVN r29489
Represents a heap allocation containing a value of type T, which we'll be able to use to represent the payloads of indirect enum cases, and also improve codegen of current boxes, which generates non-uniqued box metadata on every allocation, which is dumb. No codegen changes or IRGen support yet; that will come later.
Swift SVN r29474
create a replaceable forward declaration while building it.
This fixes a crash when building generic enums a tuple element recursively
referenceing the enum.
rdar://problem/21326786
Swift SVN r29416
and create a replaceable forward declaration while building it.
This fixes a crash when building generic enums with a constructor
function.
<rdar://problem/21294835>
Swift SVN r29411
With all the previous bugfixes it is no longer necessary to keep separate
copies because inlining and generic specialization is now handled
correctly so each specialized variable has its own specialized version
of the archetype.
rdar://problem/21109015
Swift SVN r29187
A dbg.declare is only meaningful if there is a single alloca for
the variable that is live throughout the function. With SIL
optimizations this is not guranteed and a variable can end up in
two allocas (for example, one function inlined twice).
Caught by an assertion in LLVM.
rdar://problem/21109015
Swift SVN r29186
emitting indirect pieces — LLVM (ToT, 700) now supports this.
Since this only happens in optimized code it is currently not feasible
to write a non-flaky testcase for this. I'll revisit this once our
SIL serialization efforts progressed further.
<rdar://problem/19427586> Support indirect pieces
Swift SVN r28051
We still don't actually handle these correctly, but at least
we have sensible information for them now.
Also, remember that we're working with canonical generic
signatures in more places.
Swift SVN r27388
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
The set of attributes that make sense at the AST level is increasingly divergent from those at the SIL level, so it doesn't really make sense for these to be the same. It'll also help prevent us from accidental unwanted propagation of attributes from the AST to SIL, which has caused bugs in the past. For staging purposes, start off with SILFunctionType's versions exactly the same as the FunctionType versions, which necessitates some ugly glue code but minimizes the potential disruption.
Swift SVN r27022
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
Upstream requires a valid type array for `MDSubroutineType`, so don't create
one unless we actually have parameters. Should fix the bot [1].
Swift SVN r26665
didn't and make the assertion about zero-sized types stricter.
<rdar://problem/19978910> Assertion failed: (Ty.getSizeInBits() && "type with size 0"), function getSizeInBits
Swift SVN r25599
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
contains an) archetype(s) mangle to the same name but differ in
their storage size.
This is causing an assertion on some of the build bots.
This works around the problem by not caching them, until I can reproduce
the problem on a smaller scale and fix the mangler.
Swift SVN r24682
