{"push_id":1012107426,"size":421,"distinct_size":416,"ref":"refs/heads/master","head":"5998fab672b610adc4e15c282da4d90089961d2a","before":"fc37b47f32d242e4843e87a7beea9089cebcb670","commits":[{"sha":"3240bc067e936b49a960664d17dd22b29f205822","author":{"email":"6667b8c77ec6ba15b2e807ad7a2130b19e9fa935@gmail.com","name":"Brian Gesiak"},"message":"[CMakeLists] Remove unused DARWIN_ICU_INCLUDE_PATH\n\nThis CMake variable was introduced in f6224bd3f, but its only usage was\nsubsequently removed in d9bbb6caf. Remove the obsolete variable to\navoid confusion.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/3240bc067e936b49a960664d17dd22b29f205822"},{"sha":"f049c24a02d5367560eee4c9b6e4728ca32536a6","author":{"email":"83388ff4016bc2126357f00aef690a2bae1e9376@cdbddd3f-e336-4a6e-bf7a-8cb41fa35bb4","name":"zaks"},"message":"Introduce a helper to make switching on darwin platforms less error prone\n\nIntroduce DarwinPlatformKind, which would allow us to switch on darwin\nplatforms instead of copying and pasting the brittle logic in several places.\nUse the helper method to simplify ClangImporter.","distinct":false,"url":"https://api.github.com/repos/takecian/swift/commits/f049c24a02d5367560eee4c9b6e4728ca32536a6"},{"sha":"ef925f8fb3ec7c040a42264532cf3b3d556cd032","author":{"email":"83388ff4016bc2126357f00aef690a2bae1e9376@cdbddd3f-e336-4a6e-bf7a-8cb41fa35bb4","name":"zaks"},"message":"[asan] Add basic support for Address Sanitizer function instrumentation\n\nASan allows to catch and diagnose memory corruption errors, which are possible\nwhen using unsafe pointers.\n\nThis patch introduces a new driver/frontend option -sanitize=address to enable\nASan. When option is passed in, the ASan llvm passes will be turned on and\nall functions will gain SanitizeAddress llvm attribute.","distinct":false,"url":"https://api.github.com/repos/takecian/swift/commits/ef925f8fb3ec7c040a42264532cf3b3d556cd032"},{"sha":"fa5a21fa24b26f5b8b7c55389a89aead3309f810","author":{"email":"4a57785b02e7b752fc2eb7d1c97db94302a41bf7@users.noreply.github.com","name":"practicalswift"},"message":"[CMakeLists] Remove unused SWIFT_INCLUDE_OUTPUT_INTDIR","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/fa5a21fa24b26f5b8b7c55389a89aead3309f810"},{"sha":"2b393bbcb15c268d9bb33a3bad2b6be21a87512e","author":{"email":"83388ff4016bc2126357f00aef690a2bae1e9376@cdbddd3f-e336-4a6e-bf7a-8cb41fa35bb4","name":"zaks"},"message":"[asan] XFAIL the attributes test on Linux\n\nThere is no Linux support for ASan right now.","distinct":false,"url":"https://api.github.com/repos/takecian/swift/commits/2b393bbcb15c268d9bb33a3bad2b6be21a87512e"},{"sha":"420d6deda84a0bbb7b29984417fb98bbb4324f4c","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Make the functions generating LLVM IR declarations of runtime entry points available outside of IRGen.\n\nThis functionality could be re-used by e.g. LLVMPasses, which currently create LLVM IR declarations of runtime entry points on their own.\n\nTo make the function re-usable, slightly change the API of the function:\n- use llvm::Module instead of IRGenModule.\n- use llvm::ArrayRef instead of std::initializer_list, which allows the clients of this API to dynamically form the lists of return types and arguments.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/420d6deda84a0bbb7b29984417fb98bbb4324f4c"},{"sha":"8f5e525d2dfebde3b7b5c59a6b7d3671b982c7f2","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Add function to generate an llvm wrapper for performing a runtime function call.\n\nThe generated wrapper simply invokes a corresponding entry point by means of\nan indirect call via a global the symbol, which is a function pointer referring\nto the implementation of a runtime function.\n\nUsing such wrappers allows for invocations of runtime functions from dynamic\nlibraries without the usual indirections via dynamic linker stubs.\n\nIf the calling convention and the current target require a wrapper, it will be\ngenerated. Each wrapper gets a hidden linkage and is marked as ODR, so that\na linker can merge all wrappers with the same name.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/8f5e525d2dfebde3b7b5c59a6b7d3671b982c7f2"},{"sha":"fd9a22aca19503ddabcf9d472a6ed4b17b688da0","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Prepare the configuration parameters needed for implementing a new runtime calling convention.\n\nDefine a number of macro definitions that will be used for:\n- proper auto-generation of LLVM IR level declarations of runtime function using RuntimeFunctions.def\n- generation of wrappers for runtime functions\n- setting proper calling conventions, visibility and other attributes of runtime functions inside the runtime library.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/fd9a22aca19503ddabcf9d472a6ed4b17b688da0"},{"sha":"7350fee0e33f847e57223934938ea885dfba545a","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"LLVMPasses should generate LLVM IR declarations of runtime functions in the same way as done by IRGen.\n\nMake use of the re-usable functionality provided by IRGen. This ensures that LLVM IR generated by IRGen and\nLLVMPasses for runtime functions declarations or wrappers is always in sync.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/7350fee0e33f847e57223934938ea885dfba545a"},{"sha":"adb5c7347b9d01dcc34f5211f678c669defe6f6e","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Auto-generate global symbols for those run-time functions that require it.\n\nGenerate global symbols which are function pointers to the actual implementations of runtime entry points.\nThis is done only for entry points using the new calling convention or for those entry points which explicitly require it.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/adb5c7347b9d01dcc34f5211f678c669defe6f6e"},{"sha":"68b618164250f6e2f24e7539dd0708df0da9cd1e","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Annotate runtime functions using the newly introduced annotations from runtime/Config.h.\n\nThis makes sure that runtime functions use proper calling conventions, get the required visibility, etc.\n\nWe annotate the most popular runtime functions in terms of how often they are invoked from Swift code.\n- Almost all variants of retain/release functions are annotated to use the new calling convention.\n- Some popular non-reference counting functions like swift_getGenericMetadata or swift_dynamicCast are annotated as well.\n\nThe set of runtime functions annotated to use the new calling convention should exactly match the definitions in RuntimeFunctions.def!","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/68b618164250f6e2f24e7539dd0708df0da9cd1e"},{"sha":"634579aae2289b4ccba8dab7aedab61f2ed7736a","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Move RuntimeFunctions.def into a shared location.\n\nRuntimeFunctions.def was used only by IRGen so far. But it is going to be used by the runtime library as well.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/634579aae2289b4ccba8dab7aedab61f2ed7736a"},{"sha":"850dde984d01fffdafc1d985462741b4331ce1e0","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Set the C_CC calling convention dynamically in IRGen.\n\nIt makes it look more uniform with other calling convention members of IRGen, e.g. with RuntimeCC.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/850dde984d01fffdafc1d985462741b4331ce1e0"},{"sha":"4941f513882b0852060bf547632318af86455846","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Add a new RuntimeCC1 calling convention in IRGen.\n\nThis calling convention can be now used in RuntimeFunctions.def.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/4941f513882b0852060bf547632318af86455846"},{"sha":"ec04b22145e19e771bf7f48f50899234cc09ffdc","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Properly propagate the calling convention into LLVM's call instructions.\n\nEach runtime function definition in RuntimeFunctions.def states which calling convention\nshould be used for this runtime function.  But IRGen and LLVMPasses were not always\nproperly propagating this declared calling convention all the way down to llvm's Call instructions.\nIn many cases, the standard C convention was set for the call irrespective of the actual calling\nconvention defined for a given runtime function. As a result, incorrect code was generated.\n\nThis commit tries to fix all those places, where such a mismatch was found. In many cases this is\nachieved by defining a helper function CreateCall in such a way that makes sure that the call instruction\ngets the same calling convention as the one used by its callee operand.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/ec04b22145e19e771bf7f48f50899234cc09ffdc"},{"sha":"94ab3e2a2061bc198d8cea317f64467688b5fcaa","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Define a new x-macro FUNCTION_WITH_GLOBAL_SYMBOL_AND_IMPL\n\nThis new x-macro should be used to define a runtime function that has an internal implementation\ninside the runtime library and a global symbol referring to this internal implementation.\n\nAn example of such a runtime function is \"swift_retain\", which has a global symbol \"_swift_retain\"\nreferring to its internal implementation \"_swift_retain_\".","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/94ab3e2a2061bc198d8cea317f64467688b5fcaa"},{"sha":"1d0bfcf40e0494e329269379d3eecc8564dcefc3","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Define runtime functions which should be invoked via a global function pointer.\n\nThe list of these functions is pretty much the same as the the set of functions defined in InstrumentsSupport.h\nThese are basically the functions that can be intercepted by different tools/profilers/etc.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/1d0bfcf40e0494e329269379d3eecc8564dcefc3"},{"sha":"2956e5675f70d9f3198f43e9f1d83ce2a0c3d17c","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Update x-macro metaprogramming support in IRGenModule.\n\nTeach IRGen how to handle runtime functions definitions in RuntimeFunctions.def\ndepending on their calling convention and on their need for global symbols referring\nto their internal implementations.\n\nIRGen would now generate wrappers for runtime functions invocations if at least one\nof the following conditions is met:\n- The runtime function is defined using FUNCTION_WITH_GLOBAL_SYMBOL_AND_IMPL,\n  which explicitly states that it has a global symbol referring to its implementation. In this case,\n  the generated wrapper will perform an indirect call using the specified global symbol.\n  This results in some performance improvements, because doing so removes one level of\n  indirection during a call of the runtime function.\n  The invocation sequence before looked like:\n    Swift code -> dynamic linker stub -> runtime_function -> indirect call of runtime_function's implementation through a global function pointer\n  And using a wrapper it becomes:\n    Swift code -> wrapper -> indirect call of runtime_function's implementation through a global function pointer\n\n- The runtime function is defined using the usual FUNCTION x-macro but it uses a calling convention\n   that requires that wrappers should be used instead of dynamic linker stubs to avoid the situations\n   where the dynamic linker would clobber some of the callee-saved registers when it performs a lazy\n   binding of the runtime function, which may lead to an undefined behaviour during the program execution.\n\n   In this case, the behaviour is similar to the first case, except that the name of the global symbol for\n   the  runtime function f is assumed to be _f, i.e. it has an underscore as a prefix. This symbol\n   will be auto-generated and properly initialized by an x-macro based metaprogramming machinery\n   in the runtime library.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/2956e5675f70d9f3198f43e9f1d83ce2a0c3d17c"},{"sha":"0964aecc7d7412652f4977d215fc076e3a6d8012","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Define functions using a new calling convention RuntimeCC1.\n\nWe annotate the most popular runtime functions in terms of how often they are invoked from Swift code:\n\n- Many variants of retain/release functions are annotated to use the new calling convention.\n  But those variants of retain/release functions that may result in calls of objc_retain or objc_release\n  are not migrated to the new calling convention, because it results in significant performance degradations\n  when objects of Obj-C derived classes are used.\n\n- Some popular non-reference counting functions like swift_getGenericMetadata or swift_dynamicCast are annotated as well.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/0964aecc7d7412652f4977d215fc076e3a6d8012"},{"sha":"abafdc33c10d69b6d4a5e7afc90b3ac623503c2c","author":{"email":"e18aabdf9e8eb69d578f7ff8b07a391b7e88620a@apple.com","name":"Roman Levenstein"},"message":"Fix broken tests.","distinct":true,"url":"https://api.github.com/repos/takecian/swift/commits/abafdc33c10d69b6d4a5e7afc90b3ac623503c2c"}]}