When importing C declarations, one can come across a redeclaration due
to two different clang modules textually including the same header.
Previously, to decide visibility of a declaration from a particular
module, the module in which it is redeclarated had to exactly match the
one we saw before, so a struct defined in A.B.C might cause it to be
hidden in A.X.Y, because we were already popping off submodule names on
the "left hand side", so the module comparison was A != A.X.Y. If
someone imports A.X.Y and expects that struct, they won't see it.
Now, strip off submodules of the "right hand side", correctly comparing
if the top-level modules match (A == A).
This may have the effect of allowing more declarations to be visible
than before but it prevents weird situations where struct typedefs can
be hidden in overly complicated nested header includes normally found in
OS system headers.
rdar://problem/23588593
Resilient enums are manipulated as opaque values.
Clients are still allowed to assume physical case indices and case
payload types for now -- we might add a level of indirection here,
which would require designing a new case dispatch mechanism.
Resilient enums are never constructed directly, only by calling
case constructor functions. Case constructors already get emitted,
however they're [transparent] -- this will change in a subsequent
patch.
We could save on code size by emitting an InjectEnumTag value
witness function that can construct any case given a physical case
number, rather than emitting constructors for each case, but for
now going through case constructor functions will suffice.
The C++ ABI for static locals is a bit heavy compared to dispatch_once; doing this saves more than 1KB in runtime code size. Dispatch_once/call_once is also more likely to be hot because it's also used by Swift and ObjC code.
Alas, llvm::get_execution_seed() from llvm/ADT/Hashing.h still inflicts one static local initialization on us we can't override (without forking Hashing.h, anyway).
This reverts commit 29d6170140.
I missed adding back the REQUIRES line.
Original commit message:
Make test independent of function processing order
This test verifies copy-on-write optimizations based on array semantics happen
correctly. We test that if SIL has the right form in cowarray_opts.sil these
optimizations happen. But I believe that it is important to test that SIL has
the right form when we get to the cow hoisting pass. This test verifies this.
Unfortunately, this requires a swift test case.
rdar://23681223
This test verifies copy-on-write optimizations based on array semantics happen
correctly. We test that if SIL has the right form in cowarray_opts.sil these
optimizations happen. But I believe that it is important to test that SIL has
the right form when we get to the cow hoisting pass. This test verifies this.
Unfortunately, this requires a swift test case.
rdar://23681223
The original issue has long since been fixed, but we were now producing:
error: cannot subscript a value of type 'UnsafePointer<Int8>'
which is pretty obviously wrong. The problem is that when ranking subscript
decl candidates, CSDiags was using TC.isConvertibleTo to evaluate whether the
actual base type is compatible with the base type of a subscript decl. This
was failing when the base was generic, because the logic isn't opening
archetypes. Instead of incorrectly deciding that they are incompatible, just
decide we don't know if an archetype is present. This allows us to generate
good errors in situation like this.
A crash in CSDiag that happened when we were unconditionally looking at the
getter of a subscript. This failed on UnsafeMutablePointer because it only
has addressors, not getter/setters.
When we see an unused variable in a simple-enough "if/let" (also guard and
while of course), fixit it into a comparison against nil instead of replacing
the name of the variable with "_". Also special case initialization with an
as? expression, since we can transform that into an "is" boolean test.
This reverts commit 422d46638e.
Jordan said that this change is incorrect. I am reverting the patch and plan to
investigate why we are deserializing shared_external functions with no body.
we would reject an invalid @objc enum with:
<unknown>:0: error: cannot assign value of type '(progress: Int) -> Status' to type 'Status'
because we were poking at the enum element before it was validated.
This improves the error message when attempting an array to UnsafeMutablePointer
conversion but where the element type of the array is incorrect or where the array itself
is immutable.
As a bonus fix, this dramatically improves the diagnostic when you pass "&array" to
a function that takes an UnsafePointer. We decided to not require & in this case, so
we can just provide a nice fixit to rip it off when this common error happens.
This change is related to the effort of enabling the SIL verifier by default in
debug builds.
This commit removes the code that verifies that the second argument of the cttz
and ctlz intrinsics is a constant. The SIL verifier needs to be able to verify
SIL in its early stages before optimizations clean it up. The SIL Verifier
complains that the value 'false' that we pass to ctlz is non-constant. Right now
we don't have a way to pass boolean values to the second parameter of cttz and
ctlz without creating SIL-level control flow. This control flow prevents the
verifier from detecting that the argument is a constant and
verification fails.
I tried to re-write our uses of ctlz using builtins, but the result was cryptic.
I am removing this check from the verifier mainly because it does not contribute
to the safety of our programs. LLVM already verifies that the last argument is
a constant and I believe that its okay not to verify this trait at SIL level.
These parameters were being passed down into getEligibleFunction at one
point, I think to check whether dynamic self was used, but that check
was removed recently so we no longer need to pass this around.
This test greps debug prints from the pass to verify that the optimizations
happen. One problem with this approach is that when we change the order we
process functions in the module the test breaks. Another problem is that the
test only works on specific configurations.
This commit disables the test to allow us to make progress on the bottom-up pass
manager.
rdar://23681223.