{"push_id":1020273441,"size":5,"distinct_size":5,"ref":"refs/heads/master","head":"bc1fc73b2a3e5e766c9ed267eb70c5122879abc4","before":"e1ad6d80ee4e5aeb77c6c39e221f9f10f41e8056","commits":[{"sha":"5271817bca4b04fa8262896b2a90272f0544283b","author":{"email":"08921094c058e0801e0223f91ca2378e2e948c35@gmail.com","name":"Dmitri Gribenko"},"message":"Move x64WindowsTarget.swift next to all other tests for platform-specific conditionals","distinct":true,"url":"https://api.github.com/repos/gottesmm/swift/commits/5271817bca4b04fa8262896b2a90272f0544283b"},{"sha":"2ee4fd6b2a73e6f5a4f22f36da58f331e745d5ea","author":{"email":"1b4bc63cf9790c932e8467eff6bcebe1944a98d7@apple.com","name":"Slava Pestov"},"message":"SILGen: Decouple \"should use materializeForSet\" from \"materializeForSet was synthesized\"\n\nWe will sometimes emit materializeForSet for resilience, even if\nit is not the preferred method for inout accesses of the property\nor subscript.\n\nTo avoid having SILGen behavior depend on whether Sema synthesized\na materializeForSet or not, add a more precise predicate. The\ngeneral idea as I understand it, is that we want to use\nmaterializeForSet if we do not have perfect information about the\nimplementation of the property or subscript, due to polymorphism\nor resilience.","distinct":true,"url":"https://api.github.com/repos/gottesmm/swift/commits/2ee4fd6b2a73e6f5a4f22f36da58f331e745d5ea"},{"sha":"a64431418b854b10faaf5fe213f526bd37e069c7","author":{"email":"1b4bc63cf9790c932e8467eff6bcebe1944a98d7@apple.com","name":"Slava Pestov"},"message":"SILGen: Emit materializeForSet in more cases\n\nRecently I changed Sema to always emit materializeForSet for properties\nof structs, to fix issues with duplicate or missing symbols when the\ntype declaration and conformance are in different translation units.\n\nThe same issue can happen with properties of final classes and enums,\nso let's simplify the logic by always emitting a materializeForSet\nwhen possible.\n\nThe new multifile demonstrate the problem.","distinct":true,"url":"https://api.github.com/repos/gottesmm/swift/commits/a64431418b854b10faaf5fe213f526bd37e069c7"},{"sha":"cfebe49e9080ed73d6942a02998fec09d0114db7","author":{"email":"1b4bc63cf9790c932e8467eff6bcebe1944a98d7@apple.com","name":"Slava Pestov"},"message":"SILGen: Allow direct calls to materializeForSet defined in a protocol extension\n\nNow that we apply the callback with the correct generic signature, the\nassert can go away. It was being triggered if the protocol extension was\ndefined in a different resilience domain; otherwise we prefer direct\naccess anyway.\n\nNote that materializeForSet now has to be able to re-abstract Self when\ninvoking the callback, since we might have to go from a thin metatype\nto a thick metatype.","distinct":true,"url":"https://api.github.com/repos/gottesmm/swift/commits/cfebe49e9080ed73d6942a02998fec09d0114db7"},{"sha":"bc1fc73b2a3e5e766c9ed267eb70c5122879abc4","author":{"email":"1b4bc63cf9790c932e8467eff6bcebe1944a98d7@apple.com","name":"Slava Pestov"},"message":"Sema: Simpler materializeForSet return type, NFC\n\nThe function pointer is a thin function and possibly polymorphic,\nso it does not really have an AST type. Instead of pretending it has\nan AST type, just return a RawPointer and remove some casts in the\nprocess.","distinct":true,"url":"https://api.github.com/repos/gottesmm/swift/commits/bc1fc73b2a3e5e766c9ed267eb70c5122879abc4"}]}