3 Commits

Author	SHA1	Message	Date
Manav Gabhawala	7928140f79	[SE-0046] Implements consistent function parameter labels by discarding extraneous parameter names and adding _ where necessary	2016-04-06 20:21:58 -04:00
Slava Pestov	c823974f85	Fix add_conformance evolution tests to pass with optimized builds ... Even dynamically casting a generic parameter to a protocol type is only guaranteed to succeed for conformances available at build time. Since we can't express conditional availability of conformances yet, this part of the test is useless, so redo it.	2016-02-13 18:21:58 -08:00
Slava Pestov	0159627322	As promised, split up struct_add_remove_conformances library evolution test ... We now test four setups, with the four {before, after}^2 runs of each: a) Client adds conformance -vs- library adds public conformance -- fixed-layout struct b) Client adds conformance -vs- library removes internal conformance -- fixed-layout struct c) Client adds conformance -vs- library adds public conformance -- resilient struct d) Client adds conformance -vs- library removes internal conformance -- resilient struct The first two pass, but a) requires a hack to ensure we don't directly reference conformance table, otherwise the 'after_before' version doesn't link. I think the right idea here is to weakly reference conformance tables where the deployment target is lower than the availability of the conformance. The second two are XFAIL'd until protocol conformance tables can reference resilient types from other modules. This requires emitting indirect metadata symbols, since the client doesn't know if the resilient type's metadata is direct or a template, and the conformance table cannot use the metadata accessor either. These tests will also become important if we decide to revisit synthesized accessors, and make them lazy again for structs.	2016-01-20 19:08:13 -08:00