{"push_id":1052957534,"size":9,"distinct_size":3,"ref":"refs/heads/ProfiledCallIFlagsShouldCheckForNewCallFlag","head":"a753a827611e2830b8bd06020798ffd08a8e3298","before":"d713b9accc8bb282179dc5243815cfecd19f4065","commits":[{"sha":"f8db1987cfd70f4071da552b364a7f4e64180050","author":{"email":"4a4cdc5116fb3eae8a810d7bf105917732448500@contextis.co.uk","name":"Jan Mitchell"},"message":"Adding fixes for two NULL pointer dereferences","distinct":false,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/f8db1987cfd70f4071da552b364a7f4e64180050"},{"sha":"81a01b1fd5736d5b7b1fb01657da20022067c48d","author":{"email":"196f7372942e93c00aefc70a600eb542e0d2cd1f@microsoft.com","name":"Suwei Chen"},"message":"OS4927797: TypeofElem fastpath mishandling out-of-range scenario\n\nFastpaths for opcode 'TypeofElem' mistakenly return 'number' for certain out-of-range situations.\nFix by adding check 'undefined' for return values in the fastpaths.","distinct":false,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/81a01b1fd5736d5b7b1fb01657da20022067c48d"},{"sha":"e4a75768d658c2d4a96afe674cf286853902f250","author":{"email":"196f7372942e93c00aefc70a600eb542e0d2cd1f@microsoft.com","name":"Suwei Chen"},"message":"[MERGE #729] OS4927797: TypeofElem fastpath mishandling out-of-range scenario\n\nMerge pull request #729 from suwc:build/suwc/bugfix\nFastpaths for opcode 'TypeofElem' mistakenly return 'number' for certain out-of-range situations.\nFix by adding check 'undefined' for return values in the fastpaths.","distinct":false,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/e4a75768d658c2d4a96afe674cf286853902f250"},{"sha":"f4eb3b0c9cc3bb8726b5792be56814f8e0d7f04e","author":{"email":"f978ae746fa455d6c7b8b056655b015ed0b134a7@microsoft.com","name":"Tom Care"},"message":"Class extends clause has different source locations between defer/non-defer parse modes\n\nTracked in OS 7030846.\n\nWhen emitting a class statement with an extends clause, we made the assumption that the start and end of the bytecode for that statement happened in the same place in defer and non-defer parse modes. In fact, it is possible to have the load happen in different locations, e.g. if we cache a previous load's register location in non-defer parse mode and have to load from a local slot in defer parse mode.\n\nThe fix is to set the statement location to the InitClass bytecode.","distinct":false,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/f4eb3b0c9cc3bb8726b5792be56814f8e0d7f04e"},{"sha":"e5eca9052feccaa117b7266b39b91dd5c56da604","author":{"email":"f978ae746fa455d6c7b8b056655b015ed0b134a7@microsoft.com","name":"Tom Care"},"message":"[MERGE #738] Class extends clause has different source locations between defer/non-defer parse modes\n\nMerge pull request #738 from tcare:classExtends\nTracked in OS 7030846.\n\nWhen emitting a class statement with an extends clause, we made the assumption that the start and end of the bytecode for that statement happened in the same place in defer and non-defer parse modes. In fact, it is possible to have the load happen in different locations, e.g. if we cache a previous load's register location in non-defer parse mode and have to load from a local slot in defer parse mode.\n\nThe fix is to set the statement location to the InitClass bytecode.","distinct":false,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/e5eca9052feccaa117b7266b39b91dd5c56da604"},{"sha":"eb834d772c3deae09c697897f920ef78321280df","author":{"email":"9202620134c02c2c59880ce77ca8d0dee6f50423@Microsoft.com","name":"Michael Ferris"},"message":"[MERGE #719] Adding fixes for two NULL pointer dereferences in asm.js","distinct":false,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/eb834d772c3deae09c697897f920ef78321280df"},{"sha":"263ca6f4170fbaeeed5c46b0f454108132e45d52","author":{"email":"d14bd2a22e4c8977e74f618bf3e054ee611d1aca@microsoft.com","name":"Paul Leathers"},"message":"Fix an inconsistency between interpreter and JIT in the passing of call flags. Constructor calls with spread arguments were getting CallFlags_Value in jitted code but not interpreter, which exposed some weirdness in the Error constructor. (Suwei and/or Taylor are looking into that issue.)","distinct":true,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/263ca6f4170fbaeeed5c46b0f454108132e45d52"},{"sha":"67d393f74e0e36fe329db90869127ecd83e12401","author":{"email":"d14bd2a22e4c8977e74f618bf3e054ee611d1aca@microsoft.com","name":"Paul Leathers"},"message":"[MERGE #744] Trivial CallFlags issue in jitted code\n\nMerge pull request #744 from pleath:errorctor\nFix an inconsistency between interpreter and JIT in the passing of call flags. Constructor calls with spread arguments were getting CallFlags_Value in jitted code but not interpreter, which exposed some weirdness in the Error constructor. (Suwei and/or Taylor are looking into that issue.)","distinct":true,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/67d393f74e0e36fe329db90869127ecd83e12401"},{"sha":"a753a827611e2830b8bd06020798ffd08a8e3298","author":{"email":"68302baa08cfb0bfbf8c275998759f15f7baddce@microsoft.com","name":"Taylor Woll"},"message":"Profiler for call with flags does not check the call flags to see if the call is a new call\n\nThis only really happens when we are doing a super call in a derived class\nconstructor. That call is using ProfiledCallIFlags opcode to pass the new\nflag and new target flags in the call info. When we get to the helper,\nOP_ProfileCallCommon, we need to check the flags to see if we have the new\nflag and pass that to RecordCallSiteInfo.\n\nPreviously we ignored the flags and always passed false for\nisConstructorCall. This could lead to an assert as in the attached test\ncase.","distinct":true,"url":"https://api.github.com/repos/boingoing/ChakraCore/commits/a753a827611e2830b8bd06020798ffd08a8e3298"}]}