Merge branch 'swb' into users/leish/wbmerge #2351
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ChakraCore uses char16_t on xplat and wchar_t on Windows for 2 bytes wide strings. The reason we alter wchar_t to two bytes char16_t is that Unix wchar_t is 4 bytes long. This PR removes the code that alters wchar_t and replaces all the instances of wchar_t with WCHAR. Only ChakraCommonWindows.h is not updated.
…Thunks after xplat Debugger support Merge pull request chakra-core#2291 from obastemur:fix_arm_build
… + first output Merge pull request chakra-core#2292 from obastemur:chandroid_001 <img width="225" alt="andro-chakra" src="https://cloud.githubusercontent.com/assets/4390745/21525939/d62b41b4-cd20-11e6-9c97-9f295651dc37.png">
…orObjectEnumerator Merge pull request chakra-core#2198 from rajatd:iteratorEnum We need to keep property records for properties being enumerated live during enumeration. For dynamic objects, type handlers hold references to property records and for non-existent properties, we have code in ForInObjectEnumerator::MoveAndGetNext to keep the new records live. Taking care of this case for Proxies which use IteratorObjectEnumerator
…ive on IteratorObjectEnumerator Merge pull request chakra-core#2198 from rajatd:iteratorEnum We need to keep property records for properties being enumerated live during enumeration. For dynamic objects, type handlers hold references to property records and for non-existent properties, we have code in ForInObjectEnumerator::MoveAndGetNext to keep the new records live. Taking care of this case for Proxies which use IteratorObjectEnumerator
…operty keys via proxy Merge pull request chakra-core#2300 from ThomsonTan:MarshalScriptContextForEnumeratingKeysOnProxy We missed to marshal property key string when traversing (Object.keys()) an object via a proxy on it. Marshal is necessary because the object underlying the proxy could be from a difference script context.
…traversing property keys via proxy Merge pull request chakra-core#2300 from ThomsonTan:MarshalScriptContextForEnumeratingKeysOnProxy We missed to marshal property key string when traversing (Object.keys()) an object via a proxy on it. Marshal is necessary because the object underlying the proxy could be from a difference script context.
…just created from the same script context Merge pull request chakra-core#2301 from ThomsonTan:RemoveUnnecessaryMarshal Marshal symbol in JavascriptObject::CreateKeysHelper is unnecessary because it is just created from the same script context.
…l when it is just created from the same script context Merge pull request chakra-core#2301 from ThomsonTan:RemoveUnnecessaryMarshal Marshal symbol in JavascriptObject::CreateKeysHelper is unnecessary because it is just created from the same script context.
number. This ensures that we won't overflow the heap while reading the scanned data.
… to the character list when scanning a number. Merge pull request chakra-core#2263 from kfarnung:ttserialize This ensures that we won't overflow the heap while reading the scanned data.
When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object. For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object `P`. Later, newCachedType evolves when properties were added on it. Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object. In future, when we try to set same object `P` as prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacity as well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior. Fix: We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.
…ent TypedArray updates to index handling. Merge pull request chakra-core#2289 from atulkatti:TypedArray.Issue1391 Resolves chakra-core#1391: Implement TypedArray updates to index handling. 1. Also, made changes to ArrayBuffer and DataView as per the spec updates. 2. Added some more tests for DataView.
…#1391: Implement TypedArray updates to index handling. Merge pull request chakra-core#2289 from atulkatti:TypedArray.Issue1391 Resolves chakra-core#1391: Implement TypedArray updates to index handling. 1. Also, made changes to ArrayBuffer and DataView as per the spec updates. 2. Added some more tests for DataView.
Decoding a Unicode byte-sequence can cause us to read extra bytes past the end of the source buffer if the sequence is truncated by the end of buffer immediately after the starting character. The read characters are unused as the unicode sequence will include a NULL character and, thus, be considered badly-formed resulting in the decoded character becoming the unknown character (0xFFFD). Bug is in DecodeInto, where we always add 4 to the source pointer and use that as a pointer to the end of the buffer. Because we always add 4, we always assume there are 4 more characters in the buffer, even when there are less. Fix is to calculate the real end of the source buffer and pass that down to DecodeTail which will allow us to avoid reading past the end of the buffer. Fixes https://microsoft.visualstudio.com/OS/_workitems?id=8989055&_a=edit
Merge pull request chakra-core#2288 from obastemur:no_wchar_t ChakraCore uses char16_t on xplat and wchar_t on Windows for 2 bytes wide strings. The reason we alter wchar_t to two bytes char16_t is that Unix wchar_t is 4 bytes long. This PR removes the code that alters wchar_t and replaces all the instances of wchar_t with WCHAR. Only ChakraCommonWindows.h is not updated.
While mapping actuals during inlining, do not handle ArgIn_Rest when the instruction was inlined originally in the inlinee. Existing mapping code was resulting in incorrect codegen when mapping ArgIn_Rest instruction which was originally inlined into the inlinee. Because the mapping code queried formalCount of the inlinee instead of the originally inlined function of which ArgIn_Rest was part of, and created an incorrect size NewScArray.
…t while mapping formals during inlining Merge pull request chakra-core#2202 from meg-gupta:fixinline While mapping actuals during inlining, do not handle ArgIn_Rest when the instruction was inlined originally in the inlinee. Existing mapping code was resulting in incorrect codegen when mapping ArgIn_Rest instruction which was originally inlined into the inlinee. Because the mapping code queried formalCount of the inlinee instead of the originally inlined function of which ArgIn_Rest was part of, and created an incorrect size NewScArray.
Merge pull request chakra-core#2303 from kunalspathak:typesharingfix See: https://microsoft.visualstudio.com/DefaultCollection/OS/_workItems?id=10058868&triage=true&_a=edit When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object. For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object `P`. Later, newCachedType evolves when properties were added on it. Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object. In future, when we try to set same object `P` as prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacity as well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior. Fix: We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.
…ned ArgIn_Rest while mapping formals during inlining Merge pull request chakra-core#2202 from meg-gupta:fixinline While mapping actuals during inlining, do not handle ArgIn_Rest when the instruction was inlined originally in the inlinee. Existing mapping code was resulting in incorrect codegen when mapping ArgIn_Rest instruction which was originally inlined into the inlinee. Because the mapping code queried formalCount of the inlinee instead of the originally inlined function of which ArgIn_Rest was part of, and created an incorrect size NewScArray.
Merge pull request chakra-core#2303 from kunalspathak:typesharingfix See: https://microsoft.visualstudio.com/DefaultCollection/OS/_workItems?id=10058868&triage=true&_a=edit When we share type for ChangePrototype scenario, there is an instance where we could assign type with slotCapacity different than the layout of underline object. For example, initially we cache the map of oldType to newCachedType (both didn’t have properties) in prototype object `P`. Later, newCachedType evolves when properties were added on it. Also, oldType’s slotCapacity got shrunk when we update the ctor cache of an object. In future, when we try to set same object `P` as prototype to another object, we notice that currentType aka oldType’s slotcapacity was shrunk. So we try to shrink the newCachedType’s slotCapacity as well, but it doesn’t shrink to the extent oldType was shrunk. The reason being because newCachedType has successors added that were not present on oldType. Thus we end up assigning a type to an object with different slotCapacity than object’s layout. Any further operations on this object can give undefined behavior. Fix: We try to shrink slotCapacity of newCachedType and after shrinking if it still doesn’t match oldType’s slotCapacity, we create newType and set it on object. We also update the cache with this newType.
…scCount] in JavascriptObject::DefinePropertiesHelperForGenericObjects. JavascriptObject::DefinePropertiesHelperForGenericObjects can reallocate descriptors (doubling the length). The analysis needs to know that the index is still less than the actual size of the array.
Renamed proxybug.js to proxy_cctx_bugs.js
A class that extends null should have 'this' binding in its constructor same as a base class. Add new function attribute 'BaseConstructorKind' to capture 'extends null' cases during class definition evaluation. Add new opcode for branching on 'extends null' scenario for 'this' binding.
…string manipulation Merge pull request chakra-core#2329 from kfarnung:ttdstrings The string manipulation wasn't ensuring that the operation would not exceed the bounds of the buffer. Resolves chakra-core#2305
Fixes OS 9357224. Array.prototype.unshift does not take the slow path if 'this' is a cross-site object.
…ind this Merge pull request chakra-core#2327 from suwc:build/suwc/buddy A class that extends null should have 'this' binding in its constructor same way as a base class. Add new function attribute 'BaseConstructorKind' to capture 'extends null' cases during class definition evaluation. Add new opcode for branching on 'extends null' scenario for 'this' binding. Fixes chakra-core#829
…null should bind this Merge pull request chakra-core#2327 from suwc:build/suwc/buddy A class that extends null should have 'this' binding in its constructor same way as a base class. Add new function attribute 'BaseConstructorKind' to capture 'extends null' cases during class definition evaluation. Add new opcode for branching on 'extends null' scenario for 'this' binding. Fixes chakra-core#829
…hal parameters correctly Merge pull request chakra-core#2201 from tcare:unshift Fixes OS 9357224. Array.prototype.unshift prepends array values to 'this' array by calling JavascriptArray::FillFromArgs. FillFromArgs makes the assumption that values are already marshalled to the same context as 'this'. It is possible to have a situation in Array.prototype.unshift where the source array is in another context than the parameters passed in, triggering the assert. Other users of FillFromArgs (e.g. new Array()) don't seem to be able to hit this situation. Fix is to marshal values as we iterate in FillFromArgs.
…does not marshal parameters correctly Merge pull request chakra-core#2201 from tcare:unshift Fixes OS 9357224. Array.prototype.unshift prepends array values to 'this' array by calling JavascriptArray::FillFromArgs. FillFromArgs makes the assumption that values are already marshalled to the same context as 'this'. It is possible to have a situation in Array.prototype.unshift where the source array is in another context than the parameters passed in, triggering the assert. Other users of FillFromArgs (e.g. new Array()) don't seem to be able to hit this situation. Fix is to marshal values as we iterate in FillFromArgs.
…d function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.
# Conflicts: # lib/Runtime/Library/InJavascript/Intl.js.bc.32b.h # lib/Runtime/Library/InJavascript/Intl.js.bc.64b.h # lib/Runtime/Library/IteratorObjectEnumerator.cpp # lib/Runtime/Library/IteratorObjectEnumerator.h
…ral cases. Merge pull request chakra-core#2330 from pleath:9871933 We may redefer a nested function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.
…uses a FunctionInfo*, make sure that the FunctionInfo points to a full FunctionBody before attempting to box a StackScriptFunction. 2. In addition to changing the type's entry point when we redefer, make sure we change a ScriptFunctionType's entry point info's type. This is necessary in the case of a cross-site call to a redeferred function.
… rare redeferral cases. Merge pull request chakra-core#2330 from pleath:9871933 We may redefer a nested function but choose not to defer it when we recompile the enclosing function. In such a case, the existing nested FunctionProxy is a compact ParseableFunctionInfo, not the full FunctionBody the front end expects to generate. We were keeping the compact structure and discarding the AST subtree belonging to the nested function, but this seems to be producing anomalous AST's that cause problems downstream. Generate the full FunctionBody on the fly instead.
Merge pull request chakra-core#2323 from pleath:boxdeferred 1. Now that the ScopeSlots structure uses a FunctionInfo*, make sure that the FunctionInfo points to a full FunctionBody before attempting to box a StackScriptFunction. 2. In addition to changing the type's entry point when we redefer, make sure we change a ScriptFunctionType's entry point info's entry point. This is necessary in the case of a cross-site call to a redeferred function.
…l fixes Merge pull request chakra-core#2323 from pleath:boxdeferred 1. Now that the ScopeSlots structure uses a FunctionInfo*, make sure that the FunctionInfo points to a full FunctionBody before attempting to box a StackScriptFunction. 2. In addition to changing the type's entry point when we redefer, make sure we change a ScriptFunctionType's entry point info's entry point. This is necessary in the case of a cross-site call to a redeferred function.
there's functioninfo array using copy constructor to initialize
…ftware writebarrier
Contributor
Author
|
@dotnet-bot test Linux tests please |
while etw rundown, this can happen in another thread which does not have card table initialized for its stack
Contributor
Author
|
@dotnet-bot test Linux tests please |
|
Commit messages could use some cleanup... Temporary private branch name does not need to appear in history. PR title should indicate this is merging master into swb. |
jianchun
reviewed
Jan 10, 2017
| }; | ||
| FunctionInfo(JavascriptMethod entryPoint, Attributes attributes = None, LocalFunctionId functionId = Js::Constants::NoFunctionId, FunctionProxy* functionBodyImpl = nullptr); | ||
| FunctionInfo(JavascriptMethod entryPoint, _no_write_barrier_tag, Attributes attributes = None, LocalFunctionId functionId = Js::Constants::NoFunctionId, FunctionProxy* functionBodyImpl = nullptr); | ||
| FunctionInfo(FunctionInfo& that); // Todo: (leish)(swb) find a way to prevent non-static initializer calling this ctor |
There was a problem hiding this comment.
How is this constructor used? Does it help to add a dummy ", _no_write_barrier_tag" parameter so it must be called explicitly as "FORCE_NO_WRITE_BARRIER_TAG(that)"?
jianchun
approved these changes
Jan 10, 2017
jianchun
pushed a commit
that referenced
this pull request
Jan 10, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.