|
| 1 | +2018-12-10 Mark Lam <mark.lam@apple.com> |
| 2 | + |
| 3 | + Cherry-pick r239062. rdar://problem/46603464 |
| 4 | + |
| 5 | + 2018-12-10 Mark Lam <mark.lam@apple.com> |
| 6 | + |
| 7 | + PropertyAttribute needs a CustomValue bit. |
| 8 | + https://bugs.webkit.org/show_bug.cgi?id=191993 |
| 9 | + <rdar://problem/46264467> |
| 10 | + |
| 11 | + Reviewed by Saam Barati. |
| 12 | + |
| 13 | + This is because GetByIdStatus needs to distinguish CustomValue properties from |
| 14 | + other types, and its only means of doing so is via the property's attributes. |
| 15 | + Previously, there's nothing in the property's attributes that can indicate that |
| 16 | + the property is a CustomValue. |
| 17 | + |
| 18 | + We fix this by doing the following: |
| 19 | + |
| 20 | + 1. Added a PropertyAttribute::CustomValue bit. |
| 21 | + 2. Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is |
| 22 | + CustomAccessor | CustomValue. |
| 23 | + |
| 24 | + 3. Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(), |
| 25 | + we added a check in JSObject::putDirectCustomAccessor() to see if the attributes |
| 26 | + bits include PropertyAttribute::CustomAccessor. If not, then the property |
| 27 | + must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit |
| 28 | + to the attributes bits. |
| 29 | + |
| 30 | + This ensures that the property attributes is sufficient to tell us if the |
| 31 | + property contains a CustomGetterSetter. |
| 32 | + |
| 33 | + 4. Updated all checks for PropertyAttribute::CustomAccessor to check for |
| 34 | + PropertyAttribute::CustomAccessorOrValue instead if their intent is to check |
| 35 | + for the presence of a CustomGetterSetter as opposed to checking specifically |
| 36 | + for one that is used as a CustomAccessor. |
| 37 | + |
| 38 | + This includes all the Structure transition code that needs to capture the |
| 39 | + attributes change when a CustomValue has been added. |
| 40 | + |
| 41 | + 5. Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor. |
| 42 | + The fact that we're using a CustomGetterSetter as a CustomValue should remain |
| 43 | + invisible to the descriptor. This is because the descriptor should describe |
| 44 | + a CustomValue no differently from a plain value. |
| 45 | + |
| 46 | + 6. Added some asserts to ensure that property attributes are as expected, and to |
| 47 | + document some invariants. |
| 48 | + |
| 49 | + * bytecode/GetByIdStatus.cpp: |
| 50 | + (JSC::GetByIdStatus::computeFromLLInt): |
| 51 | + (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): |
| 52 | + (JSC::GetByIdStatus::computeFor): |
| 53 | + * bytecode/InByIdStatus.cpp: |
| 54 | + (JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback): |
| 55 | + * bytecode/PropertyCondition.cpp: |
| 56 | + (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const): |
| 57 | + * bytecode/PutByIdStatus.cpp: |
| 58 | + (JSC::PutByIdStatus::computeFor): |
| 59 | + * runtime/JSFunction.cpp: |
| 60 | + (JSC::getCalculatedDisplayName): |
| 61 | + * runtime/JSObject.cpp: |
| 62 | + (JSC::JSObject::putDirectCustomAccessor): |
| 63 | + (JSC::JSObject::putDirectNonIndexAccessor): |
| 64 | + (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): |
| 65 | + * runtime/JSObject.h: |
| 66 | + (JSC::JSObject::putDirectIndex): |
| 67 | + (JSC::JSObject::fillCustomGetterPropertySlot): |
| 68 | + (JSC::JSObject::putDirect): |
| 69 | + * runtime/JSObjectInlines.h: |
| 70 | + (JSC::JSObject::putDirectInternal): |
| 71 | + * runtime/PropertyDescriptor.cpp: |
| 72 | + (JSC::PropertyDescriptor::setDescriptor): |
| 73 | + (JSC::PropertyDescriptor::setCustomDescriptor): |
| 74 | + (JSC::PropertyDescriptor::setAccessorDescriptor): |
| 75 | + * runtime/PropertySlot.h: |
| 76 | + (JSC::PropertySlot::setCustomGetterSetter): |
| 77 | + |
| 78 | +2018-11-26 Alan Coon <alancoon@apple.com> |
| 79 | + |
| 80 | + Cherry-pick r238326. rdar://problem/46259215 |
| 81 | + |
| 82 | + All users of ArrayBuffer should agree on the same max size |
| 83 | + https://bugs.webkit.org/show_bug.cgi?id=191771 |
| 84 | + |
| 85 | + Reviewed by Mark Lam. |
| 86 | + |
| 87 | + JSTests: |
| 88 | + |
| 89 | + * stress/big-wasm-memory-grow-no-max.js: Added. |
| 90 | + (foo): |
| 91 | + (catch): |
| 92 | + * stress/big-wasm-memory-grow.js: Added. |
| 93 | + (foo): |
| 94 | + (catch): |
| 95 | + * stress/big-wasm-memory.js: Added. |
| 96 | + (foo): |
| 97 | + (catch): |
| 98 | + |
| 99 | + Source/JavaScriptCore: |
| 100 | + |
| 101 | + Array buffers cannot be larger than 0x7fffffff, because otherwise loading typedArray.length in the DFG/FTL would produce |
| 102 | + a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size |
| 103 | + instead. |
| 104 | + |
| 105 | + * runtime/ArrayBuffer.cpp: |
| 106 | + (JSC::ArrayBufferContents::ArrayBufferContents): |
| 107 | + (JSC::ArrayBufferContents::tryAllocate): |
| 108 | + (JSC::ArrayBufferContents::transferTo): |
| 109 | + (JSC::ArrayBufferContents::copyTo): |
| 110 | + (JSC::ArrayBufferContents::shareWith): |
| 111 | + * runtime/ArrayBuffer.h: |
| 112 | + * wasm/WasmMemory.cpp: |
| 113 | + (JSC::Wasm::Memory::tryCreate): |
| 114 | + (JSC::Wasm::Memory::grow): |
| 115 | + * wasm/WasmPageCount.h: |
| 116 | + |
| 117 | + |
| 118 | + |
| 119 | + git-svn-id: https://svn.webkit.org/repository/webkit/trunk@238326 268f45cc-cd09-0410-ab3c-d52691b4dbfc |
| 120 | + |
| 121 | + 2018-11-16 Filip Pizlo <fpizlo@apple.com> |
| 122 | + |
| 123 | + All users of ArrayBuffer should agree on the same max size |
| 124 | + https://bugs.webkit.org/show_bug.cgi?id=191771 |
| 125 | + |
| 126 | + Reviewed by Mark Lam. |
| 127 | + |
| 128 | + Array buffers cannot be larger than 0x7fffffff, because otherwise loading typedArray.length in the DFG/FTL would produce |
| 129 | + a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size |
| 130 | + instead. |
| 131 | + |
| 132 | + * runtime/ArrayBuffer.cpp: |
| 133 | + (JSC::ArrayBufferContents::ArrayBufferContents): |
| 134 | + (JSC::ArrayBufferContents::tryAllocate): |
| 135 | + (JSC::ArrayBufferContents::transferTo): |
| 136 | + (JSC::ArrayBufferContents::copyTo): |
| 137 | + (JSC::ArrayBufferContents::shareWith): |
| 138 | + * runtime/ArrayBuffer.h: |
| 139 | + * wasm/WasmMemory.cpp: |
| 140 | + (JSC::Wasm::Memory::tryCreate): |
| 141 | + (JSC::Wasm::Memory::grow): |
| 142 | + * wasm/WasmPageCount.h: |
| 143 | + |
| 144 | +2018-11-15 Mark Lam <mark.lam@apple.com> |
| 145 | + |
| 146 | + Cherry-pick r238270. rdar://problem/46085279 |
| 147 | + |
| 148 | + 2018-11-15 Mark Lam <mark.lam@apple.com> |
| 149 | + |
| 150 | + RegExpObject's collectMatches should not be using JSArray::push to fill in its match results. |
| 151 | + https://bugs.webkit.org/show_bug.cgi?id=191730 |
| 152 | + <rdar://problem/46048517> |
| 153 | + |
| 154 | + Reviewed by Saam Barati. |
| 155 | + |
| 156 | + According to the spec https://www.ecma-international.org/ecma-262/9.0/index.html#sec-regexp.prototype-@@match, |
| 157 | + the RegExp match results are filled in using the spec's CreateDataProperty() |
| 158 | + function which does not consult the prototype for setters. JSArray:push() |
| 159 | + consults the prototype for setters. We should be using putDirectIndex() instead. |
| 160 | + |
| 161 | + * runtime/RegExpObjectInlines.h: |
| 162 | + (JSC::collectMatches): |
| 163 | + |
| 164 | +2018-11-15 Mark Lam <mark.lam@apple.com> |
| 165 | + |
| 166 | + Cherry-pick r238267. rdar://problem/46032438 |
| 167 | + |
| 168 | + 2018-11-15 Mark Lam <mark.lam@apple.com> |
| 169 | + |
| 170 | + RegExp operations should not take fast patch if lastIndex is not numeric. |
| 171 | + https://bugs.webkit.org/show_bug.cgi?id=191731 |
| 172 | + <rdar://problem/46017305> |
| 173 | + |
| 174 | + Reviewed by Saam Barati. |
| 175 | + |
| 176 | + This is because if lastIndex is an object with a valueOf() method, it can execute |
| 177 | + arbitrary code which may have side effects, and side effects are not permitted by |
| 178 | + the RegExp fast paths. |
| 179 | + |
| 180 | + * builtins/RegExpPrototype.js: |
| 181 | + (globalPrivate.hasObservableSideEffectsForRegExpMatch): |
| 182 | + (overriddenName.string_appeared_here.search): |
| 183 | + (globalPrivate.hasObservableSideEffectsForRegExpSplit): |
| 184 | + (intrinsic.RegExpTestIntrinsic.test): |
| 185 | + * builtins/StringPrototype.js: |
| 186 | + (globalPrivate.hasObservableSideEffectsForStringReplace): |
| 187 | + |
1 | 188 | 2018-10-28 Babak Shafiei <bshafiei@apple.com> |
2 | 189 |
|
3 | 190 | Cherry-pick r237325. rdar://problem/45363533 |
|
0 commit comments