- 12 Oct, 2017 37 commits
-
-
Ali Ijaz Sheikh authored
This reverts commit e770879e. Reason for revert: broke on this build: https://build.chromium.org/p/client.v8/builders/V8%20Mac%20-%20debug/builds/16703 Original change's description: > [heap] Add missing steps for Add/Remove observers > > Change-Id: I9935ff4debc623af674e606c006085258b685ced > Reviewed-on: https://chromium-review.googlesource.com/715118 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> > Cr-Commit-Position: refs/heads/master@{#48513} TBR=ulan@chromium.org,mlippautz@chromium.org,ofrobots@google.com Change-Id: Idc53870cbcb692e79764dfe0984ff765ed2458f3 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/717318Reviewed-by:
Ali Ijaz Sheikh <ofrobots@google.com> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> Cr-Commit-Position: refs/heads/master@{#48515}
-
Jakob Kummerow authored
We can bump it up later if there is need. Taking digit size into account for the max length in digits makes the max length in bits consistent across architectures. Bug: v8:6791 Change-Id: Id5205d2d308bbe6a38f8ff1ee19c082bedbeb74a Reviewed-on: https://chromium-review.googlesource.com/717176 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48514}
-
Ali Ijaz Sheikh authored
Change-Id: I9935ff4debc623af674e606c006085258b685ced Reviewed-on: https://chromium-review.googlesource.com/715118Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com> Cr-Commit-Position: refs/heads/master@{#48513}
-
Jakob Kummerow authored
In preparation for adding more separate test files. Bug: v8:6791 Change-Id: I92e2a3ab6fd35e2f902179a005ed9640851ca1b6 Reviewed-on: https://chromium-review.googlesource.com/716927Reviewed-by:
-
Marja Hölttä authored
Parser creates a FunctionState for default ctors, which affects the next_function_is_likely_called logic. PreParser needs to match that logic, so that Parser and PreParser agree about which functions are skippable. BUG=v8:5515, chromium:773576 Change-Id: I96cb6f5aa68e74389a863355f70a34693a2d1329 Reviewed-on: https://chromium-review.googlesource.com/712579 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Andrii Shyshkalov authored
Rietveld CQ has already been disabled and is no longer supoorted. TBR=sergiyb@chromium.org No-Try: True Bug: chromium:770592 Change-Id: If4411aaf15402b3c6d44fd0a8126d1db2150cb46 Reviewed-on: https://chromium-review.googlesource.com/716838Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Commit-Queue: Andrii Shyshkalov <tandrii@chromium.org> Cr-Commit-Position: refs/heads/master@{#48510}
-
Clemens Hammacher authored
The current Control::unreachable flag served two things at the same time: It tracked whether the label of that block is reachable (anyone jumps / falls through to there), and it tracked whether that block was ended by an unconditional branch or something similar. It turns out that these two things cannot be tracked with a single boolean per control struct. This CL introduces a Merge::reached flag, which tracks whether a merge point was reached so far. Also, the boolean flag to track unreachability of instructions within a block is extended to track implicitly unreachable instructions. According to the spec, a new block inside of unreachable code must be validated as reachable code again, and also code after a block which never returns has to be validated. It's not needed to generate code for such instructions, however. This new state will be particularly needed for the baseline compiler. A follow-up CL will avoid calling interface methods for unreachable code. R=titzer@chromium.org Bug: v8:6600 Change-Id: I54c97a19121eace65e25c448639330d06f61b1c8 Reviewed-on: https://chromium-review.googlesource.com/715637 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Rossberg <rossberg@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48509}
-
Jakob Kummerow authored
Bug: v8:6791 Change-Id: Ib807ac94dca646cddfe2eb5fafe18999cf0764a2 Reviewed-on: https://chromium-review.googlesource.com/714450Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48508}
-
Jakob Kummerow authored
Contrary to other Absolute-bitwise operations, it is not symmetric. Bug: v8:6791 Change-Id: Id0d57e3cf61177af0b77a3d9d4a4e17e5737ae11 Reviewed-on: https://chromium-review.googlesource.com/714301Reviewed-by:
-
Leszek Swirski authored
CheckIf is lowered to DeoptimizeIfNot, but there is no deoptimization reason given in the deopt if that check fails (the reason is hardcoded to "no reason"). These deopts are annoying to track down. This patch makes CheckIf an operator with a DeoptimizeReason parameter, which is passed through to the DeoptimizeIfNot when lowered. A couple of checks are converted to give good deoptimize reasons (some new reasons are introduced), and the others are defaulted to kNoReason until someone else finds a use for them. Change-Id: I7e910cc9579ccf978dfe9d270ba7b98c8f6c2492 Reviewed-on: https://chromium-review.googlesource.com/716479Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#48506}
-
Daniel Ehrenberg authored
The use of object literals comes with Object.prototype as the prototype. Some of these were required by the specification, but a change to the specification is proposed in https://github.com/tc39/ecma402/pull/170 to eliminate this. Some of them are unobservable, since Object.prototype is always shadowed, and defineProperty is used rather than ordinary set. However, just to be cautious, all object literals in intl.js except the ones that need it (namely the result of resolvedOptions()) are changed to a null prototype Tests are in the test262 PR https://github.com/tc39/test262/pull/1220 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I1f684615e60b523441baf31350d752585d8f96d1 Reviewed-on: https://chromium-review.googlesource.com/657839Reviewed-by:
-
Michael Lippautz authored
The Scavenger currently requires taking the lock for OLD->NEW processing and can also take another lock for sweeping a different page. Since order of pages during scavenge and sweep is unstable this may result in lock order inversion reports on TSAN when long-running programms are only executed on a single thread. The report is a false positve, hence flag it as suppression until we redesign this particular piece. No-try: true Bug: v8:6923 Change-Id: I82355be1c8d83ea61cc21152aeb10b58b1dc4b86 Reviewed-on: https://chromium-review.googlesource.com/716261Reviewed-by:
-
Igor Sheludko authored
Bug: chromium:768875 Change-Id: Ib5b324e90bea846e6cca419f81bf46bd293e83b4 Reviewed-on: https://chromium-review.googlesource.com/715802Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#48503}
-
Michael Starzinger authored
This makes all inline allocation constructions go through the existing {AllocationBuilder} helper class. It hence ensures there is a single place for all sanity checking and and makes use-sites easier to read. R=jarin@chromium.org Change-Id: Ib5daf48acd93c631fccdfa095eda1afda7048115 Reviewed-on: https://chromium-review.googlesource.com/709056 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48502}
-
Michael Lippautz authored
Bug: Change-Id: I0eb97474acaed7180bf90a47a9761df466d7e0a2 Reviewed-on: https://chromium-review.googlesource.com/716037Reviewed-by:
-
Michael Achenbach authored
NOTRY=true TBR=ulan@chromium.org Change-Id: I497f5d0359d32e48cb1c54c958bc9897c168f025 Reviewed-on: https://chromium-review.googlesource.com/715900 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48500}
-
Michael Hablich authored
TBR=machenbach@chromium.org NOTRY=true Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I819f879e68743248a2d96b2aad20136a7841a69e Reviewed-on: https://chromium-review.googlesource.com/715763 Commit-Queue: Michael Hablich <hablich@chromium.org> Reviewed-by:
Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#48499}
-
Clemens Hammacher authored
A minor refactoring of the decoder interface, which makes implementing the baseline compiler easier. R=titzer@chromium.org Bug: v8:6600 Change-Id: Ia5ae66e0e036329767b6e4f1cfcd3ed6a5e4cb74 Reviewed-on: https://chromium-review.googlesource.com/715636 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: I6ebd14d39666e8ebe8af42f6dfe579e3fd375754 Reviewed-on: https://chromium-review.googlesource.com/711843 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48497}
-
Michael Starzinger authored
This switches all deoptimization events to go through use one single continuation builtin (i.e. {Builtins::kNotifyDeoptimized}) instead of handling builtin continuation specially. Fewer moving pieces. R=jarin@chromium.org Change-Id: Ic8a2316fa2f5c8717b4d50d1a619b87a38011564 Reviewed-on: https://chromium-review.googlesource.com/712156 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: -
Maya Lekova authored
Bug: v8:6557 Change-Id: I01f065b74e3c568e577a3ee2caca68f24293c1cb Reviewed-on: https://chromium-review.googlesource.com/686763Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#48495}
-
Clemens Hammacher authored
The degenerate br_table case should be handled specially only in the graph building consumer. There it is necessary for avoiding the construction of a degenerate Switch node, which would cause a DCHECK error in instruction selection. For other backends, like the baseline compiler, we should handle it as a br_table, because the signature is different to a br. Drive-by: Fix redundant validation. R=titzer@chromium.org Bug: v8:6600 Change-Id: Ia430b6d251eb1323848977388ed95a112f8c76f7 Reviewed-on: https://chromium-review.googlesource.com/715616Reviewed-by:
-
Michael Starzinger authored
This propagates the existing type of a {JSAdd} node back to the newly created {Allocate} node. There are cases where said type is {None}. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-772720 BUG=chromium:772720 Change-Id: Iab18d2108a789b51db4e405f7f335c5c0ca6f686 Reviewed-on: https://chromium-review.googlesource.com/708796Reviewed-by: -
Igor Sheludko authored
Bug: chromium:764219 Change-Id: I99d1192c5c0f2b8bf47e0f193a0c4d9c00477466 Reviewed-on: https://chromium-review.googlesource.com/712454 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Pierre Langlois authored
When an immediate does not fit an add instruction we use a temporary register to hold the value, using movw/movt to encode it. However, in order to remove a use of r9 in TurboFan's code generator, we need to cope with no scratch registers being available. That is to say that the destination and source registers are the same, and `ip` is not available to use. In this case, we can split an add instruction into a sequence of additions: ``` UseScratchRegisterScope temps(...); Register my_scratch = temps.Acquire(); __ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd // add r0, r0, #0xab00 ``` As a drive-by fix, make the disassembler test fail if we expected a different number of instructions generated. Bug: v8:6553 Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf Reviewed-on: https://chromium-review.googlesource.com/685014Reviewed-by:Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#48491}
-
Clemens Hammacher authored
The VALIDATE macro should only be used for tests that do not have any side effect, because the side effect will only be executed if validation is active or in debug builds (because the condition is DCHECKed there). The TypeCheckBreak method has side effects since a while, since it inserts unreachable values on the stack. This did not lead to failures so far, since we only have validating users of the WasmFullDecoder. This will change once we have general lazy compilation of wasm modules, e.g. for tier-up. R=titzer@chromium.org Change-Id: I7b34dfd9297122616fa9ebdf899d9f44ca60273b Reviewed-on: https://chromium-review.googlesource.com/715416 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
R=titzer@chromium.org Change-Id: I26261e16a9db2b4b9622b1d4a3eab959fa24b7e3 Reviewed-on: https://chromium-review.googlesource.com/713496Reviewed-by:
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: Id050eb583af2977e27a91f6ff9ab82c72df0ca2e Reviewed-on: https://chromium-review.googlesource.com/711849Reviewed-by:
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: Id499a47cbb545c7ba4bffd1c1935846be6025b5e Reviewed-on: https://chromium-review.googlesource.com/712255 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Georg Neis authored
Also add tests for Object::SameValue. R=jkummerow@chromium.org Bug: v8:6791 Change-Id: I0611044dcfee4c6ba836629cf82d1589135e4ab0 Reviewed-on: https://chromium-review.googlesource.com/712034Reviewed-by:
-
Georg Neis authored
R=jkummerow@chromium.org Bug: v8:6791 Change-Id: I7e99a8aa2aa65e78a8d4288f496d496600063bfe Reviewed-on: https://chromium-review.googlesource.com/712534 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
Bug: Change-Id: I9e4b2e1157f36dacb24f7a0d0c43d31c84de8488 Reviewed-on: https://chromium-review.googlesource.com/712397Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#48484}
-
Jungshik Shin authored
- remove unused Runtime_GetLanguageTagVariants - add test for another related bug (chromium:770452) as well as for chromium:770450 . Bug: chromium:770450, chromium:770452 Test: intl/general/invalid-locale.js Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4496a4a5421000faa0e37aed85fea21ceb487998 Reviewed-on: https://chromium-review.googlesource.com/710816Reviewed-by:
-
Benedikt Meurer authored
This reverts commit 4cf47645. Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch. Original change's description: > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes the issues > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > One problem was that mutating an effect node into Unreachable confused > the LoadElimination sidetables, so I just always create a new node now. > > The other problem was that UpdateBlockControl() was executed after > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > So now I make sure that UpdateEffectPhi() is always executed last. > > This is a reland of 6ddb5e7d > Original change's description: > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > graph end. This fixes issues with later phases running DeadCodeElimination and > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > This is a reland of 3c4bc27f > > Original change's description: > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > This is a reland of e1cdda25 > > > Original change's description: > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > of a node with type {None} as dead. > > > > > > > > Bug: chromium:741225 > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > Bug: chromium:741225 > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > Bug: chromium:741225 > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48366} > > Bug: chromium:741225 > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > Reviewed-on: https://chromium-review.googlesource.com/709214 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48469} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/715096Reviewed-by:
-
v8-autoroll authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/adaf9e5..ddb142b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a48a6af..072921b Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/08cb956..21d33b1 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/b3169f9..0c09c7a Rolling v8/tools/luci-go: https://chromium.googlesource.com/chromium/src/tools/luci-go/+log/9f54aa9..45a8a51 TBR=machenbach@chromium.org,hablich@chromium.org Change-Id: I7796e40539570a9eca5dbca27d4cb69dbe62e5b3 Reviewed-on: https://chromium-review.googlesource.com/714698Reviewed-by:
v8 autoroll <v8-autoroll@chromium.org> Commit-Queue: v8 autoroll <v8-autoroll@chromium.org> Cr-Commit-Position: refs/heads/master@{#48481}
-
Jaroslav Sevcik authored
In the current implementation of hash code for objects (identity hash), we do not bother to shift the hash when we retrieve it from the hash-length bitfield in a property array. (Even worse, we store shifted value even if we do not have property array or inside dictionaries.) That means that the hash-code for objects is always divisible by 1024. Since our hash table uses a simple masking with (2^logsize - 1) to obtain the bucket, we get terrible hash collisions - essentially, our hash table degenerates to a linked list for fewer than 1024 elements. This CL always shifts the hash code so that the value in the lowest 21 bits is uniformly distributed. This results in big improvements on medium to large hash tables. A program storing 1M elements into a WeakMap gets roughly 17x faster. A program retrieving 1M elements from a Map improves even more dramatically (>100x). const a = []; for (let i = 0; i < 1e6; i++) a[i] = {}; const m = new Map(); console.time("Map.set"); for (let i = 0; i < 1e6; i++) { m.set(a[i], i); } console.timeEnd("Map.set"); console.time("Map.get"); let s = 0; for (let i = 0; i < 1e6; i++) { s += m.get(a[i]); } console.timeEnd("Map.get"); const w = new WeakMap(); console.time("WeakMap.set"); for (let i = 0; i < 1e6; i++) { w.set(a[i], i); } console.timeEnd("WeakMap.set"); Before the fix: Map.set: 157.575000 Map.get: 28333.182000 WeakMap.set: 6923.826000 After the fix: Map.set: 178.382000 Map.get: 185.930000 WeakMap.set: 409.529000 Note that Map does not suffer from the hash collision on insertion because it uses chaining (insertion into linked list is fast regardless of size!), and we cleverly avoid lookup in the hash table on update if the key does not have identity hash yet. This is in contrast to the WeakMap, which uses open-addressing, and deals with collisions on insertion. Bug: v8:6916 Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4 Reviewed-on: https://chromium-review.googlesource.com/713616Reviewed-by: -
Jakob Kummerow authored
and add the implementations for BitwiseNot, Increment, Decrement. This CL teaches the respective bytecode handlers about BigInts, and collects kBigInt type feedback for them (which TF discards for now, substituting "any"). Bug: v8:6791 Change-Id: I4e802b301b9702d8270bda400edd7e885e6b11b9 Reviewed-on: https://chromium-review.googlesource.com/706101 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
- 11 Oct, 2017 3 commits
-
-
Jungshik Shin authored
This reverts commit d9a25842. Reason for revert: I'm reverting this CL for a few reasons. #2 is the most significant and I should have thought of that before making a switch. Sorry for that. 1) perf-regression: http://crbug.com/769706 2) http://crbug.com/612010 : ICU timezone update is not propagated to zygote process so that new tabs will hold on to an old timezone even after a timezone change on Linux and Chrome OS. 3) http://crbug.com/754053 : OS timezone detection issues on macOS 10.13, Ubutu 16, RHEL 7, SuSe Linux 12 or newer. ; it's being fixed. So, it actually ok. 4) http://crbug.com/771868 : timezone wrong in gmail: If it's due to #3, we're fine because it's fixed. If not, we need to look more. Original change's description: > Enable icu-timezone-data by default > > This will introduce a new behavior on POSIX(-like) platforms. Timezone > names inside parentheses after GMT offset will not be 3-4 letter > abbreviation any longer. They'll be human-readable names in the current > default locale. This matches the current Windows behavior. > > new Date(2017, 5, 22).toString() > new Date(2017, 11, 22).toString() > > Current: > > Thu Jun 22 2017 00:00:00 GMT-0700 (PDT) > Fri Dec 22 2017 00:00:00 GMT-0800 (PST) > > New in en-US locale: > > Thu Jun 22 2017 00:00:00 GMT-0700 (Pacific Daylight Time) > Fri Dec 22 2017 00:00:00 GMT-0800 (Pacific Standard Time) > > New in German locale: > > Thu Jun 22 2017 00:00:00 GMT-0700 (Nordamerikanische Westküsten-Sommerzeit) > Fri Dec 22 2017 00:00:00 GMT-0800 (Nordamerikanische Westküsten-Normalzeit) > > BUG=v8:6031, v8:2137, v8:6076 > TEST=mjsunit/icu-date-lord-howe.js, mjsunit/icu-date-to-string.js > > Change-Id: I4e7fd8b3ddae5c7779e220c4c101e45904fcdc01 > Reviewed-on: https://chromium-review.googlesource.com/625164 > Commit-Queue: Jungshik Shin <jshin@chromium.org> > Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47953} TBR=adamk@chromium.org,littledan@chromium.org,jshin@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6031, v8:2137, v8:6076, chromium:769706, chromium:612010, chromium:771868 Change-Id: I60d75467ee21975d3a235344b01c0d2d44a7da96 Reviewed-on: https://chromium-review.googlesource.com/713404Reviewed-by:
-
Alexey Kozyatinskiy authored
This roll includes: - [inspector_protocol] fixed compatibility with latest jinja 2.9.6 - [inspector_protocol] removed unused variable - Follow up on alph's review comments. - Provide default escape implementation for latin and wide strings. - Allow escaping utf8 strings in embedders that operate std::string. - Upload inspector_protocol changes to Gerrit by default - [inspector_protocol] Fix building with non-ASCII paths - [inspector_protocol] added StringUtil::toDouble method as requirement - Add const char* overloads to ErrorSupport BUG=chromium:743313 R=dgozman@chromium.org Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ic81a62c638bf592ae65c84055d53d926e50715ac Reviewed-on: https://chromium-review.googlesource.com/713538Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#48477}
-
John Barboza authored
Port fc413158 Original Commit Message: ObjectTriple isn't used since f1ec44e2. Delete it, and simplify CEntryStub on all backends. R=martyn.capewell@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I4897783bb848e016d93731585e6891033fa4d4cf Reviewed-on: https://chromium-review.googlesource.com/714022Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#48476}
-
