{"push_id":757761937,"size":13,"distinct_size":13,"ref":"refs/heads/master","head":"6b8d992844994ac5e52344dd6f2eec2074790231","before":"467e441764ae6eafd9f03961ab08422d8b96c19e","commits":[{"sha":"084b3399ea562f1073f5fcb87018396a064d3537","author":{"email":"8c2972bb2b5358c2b27d18af7e160cb10cb2ee0d@live.com","name":"Hadi Brais"},"message":"Adding Table of Contents to clr-code-guide.md\n\nAdding Table of Contents to clr-code-guide.md, fixing some typos and formatting issues.","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/084b3399ea562f1073f5fcb87018396a064d3537"},{"sha":"3bfbb9bca6698c9068e42a577613343f12f24898","author":{"email":"854ca7538e83a979b0475833333b6b096e7a2117@gmail.com","name":"Andrey Akinshin"},"message":"Fix a bug with disappeared cast to byte in numeric binary expressions\n\nLowering::IndirsAreEquivalent doesn't check if the 2 indirections have the same type and because of that a RMW style instruction is generated instead of the expected\n\nmovzx    rax, byte  ptr [7FFA61024742h]\nxor      eax, 33\nmov      word  ptr [7FFA61024742h], ax\n\nThis behavior was fixed by adding an additional check to IndirsAreEquivalent (implementation of the mikedn's approach: https://github.com/dotnet/coreclr/pull/1329#discussion_r36397171).\n\nFix #1323.","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/3bfbb9bca6698c9068e42a577613343f12f24898"},{"sha":"42cf2d9a2a97a796a5a6c1080e56f15ee648234a","author":{"email":"4d7b62f37874a0e0e9bb9c3c1eb77ca6f8b899fd@microsoft.com","name":"Matt Mitchell"},"message":"Merge pull request #1329 from AndreyAkinshin/master\n\nFix a bug with disappeared cast to byte in numeric binary expressions","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/42cf2d9a2a97a796a5a6c1080e56f15ee648234a"},{"sha":"64451083d5bb7204aa6ea46f04c7d0faaf40a260","author":{"email":"07a4b8ef4776dc3c1cb2c72cd5046e2798279b6c@microsoft.com","name":"Tarek Mahmoud Sayed"},"message":"Port the DateTime parser fix from the Desktop\n\nThis change is fixing the DateTime parser in cases of date/time strings for cultures which has the date and time separators are same. This happen with Norway, Serbia and Finland cultures\n\n[tfs-changeset: 1513801]","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/64451083d5bb7204aa6ea46f04c7d0faaf40a260"},{"sha":"43a052cf5bdc001a38b991efe99613f808525ec9","author":{"email":"1268f4a162a5c7e640bb3e2686b9a6c242fd587d@microsoft.com","name":"Matt Ellis"},"message":"Build Toolbox\\BinaryRewriting as part of the PK product group\n\nWe need this so we can get a signed build of BclRewriter.exe which is only produced by the offical build out of the ProjectK branch.\n\n[tfs-changeset: 1513878]","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/43a052cf5bdc001a38b991efe99613f808525ec9"},{"sha":"3f756ddc722655ed5d76032b0a98e4dc550c2019","author":{"email":"a0c96f5c32b84a5cd299c5d50c06b1fdd36eeb8d@users.noreply.github.com","name":"Aditya Mandaleeka"},"message":"Merge pull request #1380 from dotnet-bot/from-tfs\n\nMerge changes from TFS","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/3f756ddc722655ed5d76032b0a98e4dc550c2019"},{"sha":"21712a326afeef020f3de9103132cab6929c6f31","author":{"email":"2d81c789f1a62b885ef54dbb7373bf1f07dc8d79@microsoft.com","name":"Alex Ghiondea"},"message":"We are incorrectly stripping away the Identity method from the EnumHelper type when building mscorlib.\n\n[tfs-changeset: 1513902]","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/21712a326afeef020f3de9103132cab6929c6f31"},{"sha":"02ec545c9b188bcbf21c0910ee538e572b9fcbf8","author":{"email":"202bfdaf89d4929b26015b6e3335e051707b8d9a@microsoft.com","name":"Jan Kotas"},"message":"Merge pull request #1382 from dotnet-bot/from-tfs\n\nMerge changes from TFS","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/02ec545c9b188bcbf21c0910ee538e572b9fcbf8"},{"sha":"63653cf406ead63a79ae52920e050c385a8f2e37","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Fix GC issues during exception handling on Unix\n\nThis change fixes two issues that happens in some cases when GC scans stack of\na thread that is handling exception at that moment.\n\nFirst issue was caused by the fact that the stack walker wasn't modified to\ntake into account the difference in exception handling on Unix. When an exception\nis thrown from a catch handler or finally block (a funclet )on Unix, part of the stack\nis unwound immediatelly, while on Windows, the stack is not reclaimed until\nthe exception is fully handled.\nThe problem was caused by the fact that when GC happens in the funclet before the exception\nis processed, but after a point where GC knows that the lifetime of locals in the caller frame\nis over, it doesn't update the references in the caller frame for objects that it has relocated.\nOn Windows, this is detected just from walking the stack, since the funclet frame is still there\nand the stack walker can then skip scanning the parent frame GC references.\nOn Linux, the funclet is not on stack anymore, so this case was not detected and GC attempted to\nscan the stale references and crashed.\nThe fix was to detect that a frame was a caller to a funclet from the chain of previous exception\ntrackers that is fortunately preserved and the trackers hold the necessary information.\n\nThe second issue was more subtle. During interleaved exception handling, when we unwind a native\nportion of the stack and switch back to unwinding a managed block of stack frames, we re-create\nthe exception tracker and carry over just a few members necessary to continue processing the\nsame exception. The way it was done was that we have first removed the current tracker from\nthe list of trackers of the current thread, then we have destroyed it, created a new one and\nput it back to the front of the list.\nThe issue happened when GC started walking the stack of the thread in the small time slot when\nthe current tracker was removed from the list, but the re-created tracker was not added there yet.\nThen the detection necessary for handling the previous issue didn't work and we got a crash.\nThe fix was to make the whole re-creation of the exception tracker atomic w.r.t. the GC.","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/63653cf406ead63a79ae52920e050c385a8f2e37"},{"sha":"2e37fd0a43577b45d65b582e0765c93f3b8bad51","author":{"email":"202bfdaf89d4929b26015b6e3335e051707b8d9a@microsoft.com","name":"Jan Kotas"},"message":"Merge pull request #1383 from dotnet-bot/from-tfs\n\nMerge changes from TFS","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/2e37fd0a43577b45d65b582e0765c93f3b8bad51"},{"sha":"4f0eea39b8a7d336489bcbe6dd552c7ca729f229","author":{"email":"a0c96f5c32b84a5cd299c5d50c06b1fdd36eeb8d@users.noreply.github.com","name":"Aditya Mandaleeka"},"message":"Merge pull request #1137 from hadibrais/patch-1\n\nAdd Table of Contents to clr-code-guide.md","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/4f0eea39b8a7d336489bcbe6dd552c7ca729f229"},{"sha":"87a6eb66f4b058c8a35c96edbce0e28644880b9f","author":{"email":"a0c96f5c32b84a5cd299c5d50c06b1fdd36eeb8d@users.noreply.github.com","name":"Aditya Mandaleeka"},"message":"Fix a section number in table of contents.\n\nThe \"Primitive Types\" link pointed to 2.9 rather than 2.9.1.","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/87a6eb66f4b058c8a35c96edbce0e28644880b9f"},{"sha":"6b8d992844994ac5e52344dd6f2eec2074790231","author":{"email":"c457b3e5195ce3a91c472dc392bcc90fb508bb62@microsoft.com","name":"Jan Vorlicek"},"message":"Merge pull request #1384 from janvorli/fix-gc-during-exception-handling\n\nFix GC issues during exception handling on Unix","distinct":true,"url":"https://api.github.com/repos/tarekgh/coreclr/commits/6b8d992844994ac5e52344dd6f2eec2074790231"}]}