We need a SIL level unsafe cast that supports arbitrary usage of
UnsafePointer, generalizes Builtin.reinterpretCast, and has the same
semantics on generic vs. nongeneric code. In other words, we need to
be able to promote the cast of an address type to the cast of an
object type without changing semantics, and that cast needs to support
types that are not layout identical.
This patch introduces an unchecked_bitwise_cast instruction for that
purpose. It is different from unsafe_addr_cast, which has been our
fall-back "unknown" cast in the past. With unchecked_bitwise_cast we
cannot assume layout or RC identity. The cast implies a store and
reload of the value to obtain the low order bytes. I know that
bit_cast is just an abbreviation for bitwise_cast, but we use
"bitcast" throught to imply copying a same sized value. No one could
come up with a better name for copying an objects low bytes via:
@addr = alloca $wideTy
store @addr, $wideTy
load @addr, $narrowTy
Followup patches will optimize unchecked_bitwise_cast into more
semantically useful unchecked casts when enough type information is
present. This way, the optimizer will rarely need to be taught about
the bitwise case.
Swift SVN r29510
Mangle the generic signature and interface type of the conforming type signature. Fix the demangler to reset the generic context between mangling a witness's conformance and requirement; they have independent generic contexts, and the bookkeeping for generic signatures notes the discrepancy.
Swift SVN r28377
Single generic parameters are common, as are a lack of requirements, so tweak things so that generic parameter counts are mangled as (count - 1), with a special mangling for zero, and give a single generic parameter at depth zero the empty-string mangling. Most requirements are protocol constraints, so use a better mangling for them that doesn't require the 'P..._' wrapping of the general type mangling. On the other hand, dependent member types ought to mangle in the protocol of the associated type, which adds some length, but isn't too bad since the protocol will almost definitely have a substitution introduced by a preceding protocol constraint.
Swift SVN r28296
The following declaration kinds can be marked with this attribute:
- method
- property
- property accessor
- subscript
- constructor
Use cases include resolving circularity for bridging methods in an @objc
class, and allowing overloading methods and constructors in an @objc class
by signature by marking some of them @nonobjc.
It is an error to override an @objc method with a @nonobjc method. The
converse, where we override a @nonobjc method with a @objc method, is
explicitly supported.
It is also an error to put a @nonobjc attribute on a method which is
inferred as @objc due to being part of an @objc protocol conformance.
Fixes <rdar://problem/16763754>.
Swift SVN r28126
and r28105: "implement <rdar://problem/17013042> T! <-> T? conversions should not produce a diamond"
r28111 broke the stdlib build. I also reverted r28105, because r28111 fixes regressions introduced in r2805.
Swift SVN r28114
Two pieces to this:
- Peephole InjectOptionalExpr(BindOptionalExpr(X)) to bitcast x to the result type.
- Enhance OptionalEvaluationExpr to delete the failure block if not needed.
Swift SVN r28105
I also added a placeholder for ARC optimization docs. I wanted anyone
reading about swift ARC optimization to run across my discussion on
correctness w.r.t. COW.
Swift SVN r27890
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
Keep track of a second set of "direct method reference" curry thunks that don't end in a dynamic dispatch in order to properly implement a partial application such as 'let foo = super.foo'. Fixes rdar://problem/20598526.
Swift SVN r27538
reference to something of class type. This is required to model
RebindSelfInConstructorExpr correctly to DI, since in the class case,
self.init and super.init *take* a value out of class box so that it
can pass the +1 value without performing an extra retain. Nothing
else in the compiler uninitializes a DI-controlled memory object
like this, so nothing else needs this. DI really doesn't like something
going from initialized to uninitialized.
Yes, I feel super-gross about this and am really unhappy about it. I
may end up reverting this if I can find an alternate solution to this
problem.
Swift SVN r27525
This commit adds a flag to disable optimizations on a specific functions. The
primary motivation of this patch is to allow the optimizer developers to reduce
testcasese by disabling optimizations of parts of the code without having to
recompile the compiler or inspect SIL. The annotations "inline(never)"
and "optimize.none" can go a long way.
The second motivation for this patch is to allow our internal adopters to work
around compiler bugs.
rar://19745484
Usage:
@semantics("optimize.never")
public func miscompile() { ... }
Swift SVN r27475
Try to make it more plain that assignment method syntax is still allowed with class methods; only explicit implementation of the assignment form is not allowed.
Swift SVN r26799
