Remove the cast consumption kind from all unconditional casts. It
doesn't make sense for unconditional casts, complicates SIL ownership,
and wasn't fully supported for all variants. Copies should be
explicit.
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
There's a lot of information here for one document, so I think another layer of organization is warranted. This commit only breaks up the existing content by heading, it does not update or otherwise change any content.
This has the same semantics as open_existential_box, but returns an object value
instead of an address.
This is used in SIL opaque values mode. Attempting to reuse open_existential_box
in this mode causes SIL type inconsistencies that are too difficult to work
around. Adding this instruction allows for consistent handling of opaque values.
The original versions of several of these currently redundant instructions will
be removed once the SIL representation stabilizes.
These instructions have the same semantics as the *ExistentialAddr instructions
but operate directly on the existential value, not its address.
This is in preparation for adding ExistentialBoxValue instructions.
The previous name would cause impossible confusion with "opaque existentials"
and "opaque existential boxes".
Specifically, I tried to make it clearer that viewcfg does not rely on any type
information or declarations (i.e. it can dump raw textual CFGs). This also means
that it can be used in an editor to dump CFGs at your cursor?!
Thanks Erik for showing me this!
* IRGen: EmptyBoxType's representation cannot be nil because of a conflict with extra inhabitant assumption in indirect enums
We map nil to the .None case of Optional. Instead use a singleton object.
SR-5148
rdar://32618580
A handful of people have recently asked me if such a thing existed;
now it does. There's certainly more that can be added here, but I
wanted to dump a bunch of the information in my brain into doc form.
Previously, two constructors with the same full name and argument
types would get identical manglings even if they were declared
'private' or 'fileprivate' in different files. This would lead to
symbol collisions in whole-module builds. Add a new mangling node for
private discriminators on base-name-less decls to make this unique.
This still doesn't fix the existing issue with private members, named
or not, conflicting when they're in the /same/ file, but since Swift 4
makes those members visible to one another (SE-0169) that's only an
issue in Swift 3 mode anyway, and as such probably won't get fixed at
all.
rdar://problem/27758199
