Add new builtins(by generalizing, renaming, and extending the builtins used for compile time integer literal checking). These new builtins truncate integers and check for overflow/truncation errors at runtime. Use these for FixedPoint conversion constructors.
Fix a routine in stdlib's String implementation and a test that relied on bitwise behavior of the constructors (and triggered overflows).
TODO:
- Teach CCP about these to get static checking.
- Add special builtins for same size signed <-> unsigned conversions.
Swift SVN r10432
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
