Start using null-page values as extra inhabitants when laying out single-payload enums that contain class pointers as their payload type. Don't use inhabitants that set the lowest bit, to avoid trampling potential ObjC tagged pointer representations. This means that 'T?' for class type T now has a null pointer representation. Enums with multiple empty cases, as well as nested enums like 'T??', should now have optimal representations for class type T as well.
Note that we don't yet expose extra inhabitants for aggregates that contain heap object references, such as structs with class fields, Swift function types, or class-bounded existentials (even when the existential has no witness tables).
Swift SVN r10061
Protocols with associated types can't currently be used as existential
types. Combined with the inability to create type constraints on
generic functions nested in generic types based on the outer type and
the inability to create closures of generic type and the inability to
create protocol constraints that require generic functions and the
inability to create protocols with init() requirements... and this is
what we get.
Swift SVN r10034
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
When we need a reference to protocol or protocol composition type metadata, ask for it through the runtime, instead of referencing statically-emitted protocol metadata.
Swift SVN r9871
Same deal as for opaque existentials--pre-instantiate a static witness table for one-witness-table types (the zero-witness-tables case is nicely handled by Builtin.ObjCPointer's value witness), and generate a vwtable using dynamic witness implementations for each different-sized container on demand as necessary.
Swift SVN r9850
The assign-with-copy operation on existentials is complex enough to be emitted as a function call, which is currently generated on-demand by IRGen for every existential layout. We can instead use the implementation out of the runtime. Provide entry points for zero, one, and any number of witness tables.
Swift SVN r9815
Metadata.cpp:1280:26: warning: zero size arrays are an extension [-Wzero-length-array]
const void *_witnesses[NUM_VALUE_WITNESSES];
^~~~~~~~~~~~~~~~~~~
Metadata.cpp:1366:12: note: in instantiation of member class
'<anonymous>::OpaqueExistentialValueWitnesses<0>::Container' requested here
/*size*/ Container::size(),
^
Metadata.cpp:1448:51: note: in instantiation of static data member '<anonymous
namespace>::OpaqueExistentialValueWitnesses<0>::ValueWitnessTable' requested here
return &OpaqueExistentialValueWitnesses<0>::ValueWitnessTable;
^
1 warning generated.
As an aside, putting a template argument in ALL_CAPS is kinda wierd.
Swift SVN r9787
Instantiate static value witness implementations for the common zero- and one-witness-table cases, which correspond to the "Any" type protocol<> and to single-protocol types. For protocol compositions, instantiate a value witness table that uses the layout information from existential metadata to perform the value witness operations.
Swift SVN r9752
Set up a metadata cache for existential type metadata. Instantiate existential metadata by first sorting the protocol list, so that it is order invariant, precomputing the overall witness table count and class constraint of the composition so it can be cached in the existential metadata.
We still need to implement value witnesses for existential containers in the runtime before this is complete. We can at least test the uniquing and flags computations at this point.
Swift SVN r9727
It'd be nice to eventually report some context information, maybe derived from the location info on the originating 'cond_fail' SIL instruction, but this is a start.
Swift SVN r9589
For consistency with the vague idea that things that are only useful for
compiler developers should go in utils/, not tools/. Unless they need
build system support.
Swift SVN r9433
(This only fails under -DSWIFT_OPTIMIZED=NO; most likely due to an llvm bug.)
We've decided that it's best to specialize each arithmetic builtin that could overflow, instead of calling a separate generic "staticReport" builtin and passing it enough info to produce the message. The main advantage of this approach is that it would be possible for the compiler to customize the message and better link it to the builtin that overflows. For example, the constants that participated in the computation could be printed. In addition, less code will be generated and the compiler could, in the future, automatically emit the overflow diagnostics/trap at runtime.
This patch introduces new versions of op_with_overflow swift builtins. Which are lowered to llvm.op_with_overflow builtins in IRGen after the static diagnostics. If the last argument to the builtins evaluates to true, the overflow is unintentional. CCP uses the builtins to diagnose the overflow detectable at compile time. FixedPoint is changed to rely on these in implementation of primitive arithmetic operations.
Swift SVN r9328
wide
Currently integer literals are 64-bit. In order to allow checking for overflow
while converting an integer literal to swift.UInt/Int* types we need at least
65 bits. But floating point numbers (Float32, Float64, Float80) are
BuiltinIntegerLiteralConvertible. In order to allow spelling large floating
point constants, we allow 136-bit literals.
Rationale: 128 bits are enough to represent the absolute value of min/max IEEE
Binary32, and we need 1 bit to represent the sign. 136 is 129 rounded to the
next 8 bits.
The plan is to have builtins that do the overflow check and convert 136-bit
numbers to the required width. We need these builtins for both integers and
floating point numbers to ensure that 136-bit numbers are folded into sane
constants in SIL and don’t escape to LLVM IR.
Swift SVN r9253
- Added 2 new builtins strunc_with_overflow and utrunc_with_overflow
that perform truncation and produce a compile time error when truncation
overflows.
- Used these builtins instead of trunc to implement "_convertFromBuiltinIntegerLiteral".
- Currently, the builtins are converted to trunc in IRGen, but we should
not be IRGenning code that uses them, since all uses of
"_convertFromBuiltinIntegerLiteral" should be inlined and the arguments
constant folded.
- I had to change a test and the implementation of operator '~' in the standard library
because they assumed that '0xFF' is a valid signed Int8. It is questionable if we should
allow this and if we should treat signed and unsigned integers differently depending on
how they are spelled (decimal or hexadecimal).
* This patch will be further improved (Ex: will start finding overflows on Int64, better
deal with '-128' after the negative integer literal patch is committed.)
Swift SVN r9226
