Adding a custom lexer for asm.js parsing.
It takes advantage of a number of asm.js properties to simply things:
* Assumes 'use asm' is the only string.
* Does not handle unicode for now (tools don't emit it).
* Combines global + local string table with lexer.
R=marja@chromium.org,vogelheim@chromium.org,kschimpf@chromium.org
BUG=v8:4203
BUG=v8:6090
Review-Url: https://codereview.chromium.org/2751693002
Cr-Commit-Position: refs/heads/master@{#43874}
The current incarncation of DuplicateFinder does work that
AstValueFactory already does. All that remains is that
DuplicateFinder wraps a container.
Adding const-ness changes were necessary to have IsDuplicateSymbol
be const.
BUG=v8:6092
Change-Id: I8081cfeef363717405d5b6325e290fe7725390dc
Reviewed-on: https://chromium-review.googlesource.com/456317
Commit-Queue: Marja Hölttä <marja@chromium.org>
Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43872}
- Implement C++ builtins and ElementsAccessor for
%TypedArray%.prototype.lastIndexOf
- Remove TypedArrayLastIndexOf in src/js/typedarray.js
- Combine InnerArrayLastIndexOf and ArrayLastIndexOf in src/js/array.js
BUG=v8:5929
Review-Url: https://codereview.chromium.org/2744283002
Cr-Commit-Position: refs/heads/master@{#43870}
Previous to this CL, CSA-optimized Array builtins--like forEach, some, and
every--were written in a single, monolithic block of CSA code.
This CL teases the code for each of these builtins apart into two chunks, a main
body with optimizations for fast cases, and a "continuation" builtin that
performs a spec-compliant, but slower version of the main loop of the
builtin. The general idea is that when the "fast" main body builtin encounters
an unexpected condition that invalidates assumptions allowing fast-case code, it
tail calls to the slow, correct version of the loop that finishes the builtin
execution.
This separation currently doens't really provide any specific advantage over the
combined version. However, it paves the way to TF-optimized inlined Array
builtins. Inlined Array builtins may trigger deopts during the execution of the
builtin's loop, and those deopt must continue execution from the point at which
they failed. With some massaging of the deoptimizer, it will be possible to make
those deopt points create an extra frame on the top of the stack which resumes
execution in the slow-loop builtin created in this CL.
BUG=v8:1956
LOG=N
Review-Url: https://codereview.chromium.org/2753793002
Cr-Commit-Position: refs/heads/master@{#43867}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
For now, has a test that compares the stdout of --type-profile in test/message. We
will remove this test when --type-profile is fully integrated in
the debugger protocol. Adding
the test in test/inspector does not work, because the inspector
test itself consists of JavaScript code that would convolute the
output and be non-deterministic under stress.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43866}
This is another step towards making calls to builtins more convenient.
Builtins::CallableFor is an automatically generated Callable accessor for TFS
builtins (whereas previously we had to manually add an accessor to
code-factory.{h,cc}).
CSA::CallBuiltin is a convenience wrapper around CallStub for TFS builtins.
We can begin removing accessors for TFS builtins from CodeFactory in an
upcoming commit.
BUG=v8:5737
Review-Url: https://codereview.chromium.org/2752213002
Cr-Commit-Position: refs/heads/master@{#43865}
- Change test to avoid adding denormalized numbers. This flushes to
zero on ARM hardware when using Neon.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2754543007
Cr-Commit-Position: refs/heads/master@{#43864}
Adjusting the count requires us to call into Semaphore::WaitFor which
even on a z840 introduces a pause of at least 50us. We often call in
here from the unmapper that tries to add pages. E.g. for reducing the
new space size of 8M we call this for 16x2 pages, resulting in a pause
of 1.6ms for just checking the status of the sweeper tasks.
Avoiding reducing the count reduces the epilogue times. Example: FB
infinite scroll:
Before:
heap.epilogue
len: 102
min: 0.01
max: 4.83
avg: 0.140196078431
[0,5[: 102
After:
heap.epilogue
len: 106
min: 0.01
max: 0.24
avg: 0.0260377358491
[0,5[: 106
BUG=
Change-Id: I296c20ae3ac4b65218e4e038a9dbce504160a764
Reviewed-on: https://chromium-review.googlesource.com/455839
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43863}
Before adding stack unwinding of interpreted wasm frames, clean up the
respective method a bit.
Replace if-cascade by a switch, and inline the (previously public)
RemoveMaterializedObjectsOnUnwind method.
R=mstarzinger@chromium.org, jarin@chromium.org
BUG=v8:5822
Change-Id: Icf80c4adadc2f43551656ced8e92a67752d5c471
Reviewed-on: https://chromium-review.googlesource.com/453898
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43860}
This behaviour was missing before. If a trap is encountered in the
interpreter, we now throw the right error. With test.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2
Reviewed-on: https://chromium-review.googlesource.com/453839
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43859}
This is in preparation for linking the former only into mksnapshot.
Just shuffling code around, no changes in functionality.
BUG=v8:6055
Review-Url: https://codereview.chromium.org/2752143004
Cr-Commit-Position: refs/heads/master@{#43858}
We were converting an int to a Smi, calling ToString to create a String
object, then appending this String to an IncrementalStringBuilder.
It's much easier and more efficient to just sprintf to a local buffer
and append that instead.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I9302a07971cfd32350d69b1b8f182d0ba7245b77
Reviewed-on: https://chromium-review.googlesource.com/454018
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43857}
When instantiating the wasm interpreter for debugging, we unwrap all
wasm-to-js wrappers and store the callable objects. The handles are
stored in a DeferredHandleScope and deleted when the InterpreterHandle
(store in WasmDebugInfo) is freed.
A call to an imported function reads the arguments from the stack,
converts them to JS objects, calls the callable, converts back the
return value and pushes it onto the stack.
Reentering the interpreter from the calles JS code is not permitted
yet, but will be in a follow-up CL.
Also, indirect calls to imported functions will have to follow.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I66c35053bccb6cf8d416606e4f840d888ccb3b65
Reviewed-on: https://chromium-review.googlesource.com/453838
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43855}
This introduces iterators for the parameters and return types of a
signature. This required extending the constructor of iterator_range
for perfect forwarding.
I also moved the HasJSCompatibleSignature to a header file in order to
reuse it from the interpreter.
R=ahaas@chromium.org, titzer@chromium.org
Change-Id: Ie77f87ef87fdfd3138b2106640ac7c481cf247e6
Reviewed-on: https://chromium-review.googlesource.com/455777
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43854}
With this change we can remove all the old trap code.
R=titzer@chromium.org, clemensh@chromium.org
Change-Id: I85c10a6ac7d3eccc7b611e06f2a651d5a8a00a9c
Reviewed-on: https://chromium-review.googlesource.com/452379
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43853}
Reason for revert:
Still flaky
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43846}
> Committed: 5c32287390
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43849}
> Committed: 18c35e4958TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2745413006
Cr-Commit-Position: refs/heads/master@{#43852}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Commit-Position: refs/heads/master@{#43804}
Committed: 6cf880f4b8
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43846}
Committed: 5c32287390
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43849}
This unifies several of the places in CSA that convert various
string kinds (cons, thin, sliced) to direct strings
(sequential, external).
A couple of spots remain with duplicate code, but most of these are
more difficult to unify due to specific optimizations.
BUG=
Review-Url: https://codereview.chromium.org/2744263002
Cr-Commit-Position: refs/heads/master@{#43848}
Reason for revert:
Flaky under stress. Fix first.
Original issue's description:
> Collect type profile for DevTools
>
> Collect type information for JavaScript variables and display it
> in Chrome DevTools.
> Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
>
> When debugging JavaScript, it’s helpful to know the type of
> a variable, parameter, and return values. JavaScript is
> dynamically typed, and for complex
> source code it’s often hard to infer types. With type profiling, we
> can provide type information to JavaScript developers.
>
> This CL is a proof of concept. It collects type profile for
> assignments and simply prints the types to stdout.
>
> The output looks something like this:
>
> #my_var1
> #Object
> #number
> #string
> #number
> #undefined
> #string
> #Object
> #Object
>
>
> We use an extra slot in the feedback vector of assignments to
> carry the list of types for that assignment. The extra slot is
> only added when the flag --type-profile is given.
>
>
> Missing work:
> * Collect data for parameters and return values (currently only assignments).
> * Remove duplicates from the list of collected types and use a common base class.
> * Add line numbers or source position instead of the variable name.
>
>
>
> BUG=v8:5935
>
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Original-Commit-Position: refs/heads/master@{#43791}
> Committed: 0332bebde9
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Original-Commit-Position: refs/heads/master@{#43804}
> Committed: 6cf880f4b8
> Review-Url: https://codereview.chromium.org/2707873002
> Cr-Commit-Position: refs/heads/master@{#43846}
> Committed: 5c32287390TBR=yangguo@chromium.org,mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2747383004
Cr-Commit-Position: refs/heads/master@{#43847}
Collect type information for JavaScript variables and display it
in Chrome DevTools.
Design Doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing
When debugging JavaScript, it’s helpful to know the type of
a variable, parameter, and return values. JavaScript is
dynamically typed, and for complex
source code it’s often hard to infer types. With type profiling, we
can provide type information to JavaScript developers.
This CL is a proof of concept. It collects type profile for
assignments and simply prints the types to stdout.
The output looks something like this:
#my_var1
#Object
#number
#string
#number
#undefined
#string
#Object
#Object
We use an extra slot in the feedback vector of assignments to
carry the list of types for that assignment. The extra slot is
only added when the flag --type-profile is given.
Missing work:
* Collect data for parameters and return values (currently only assignments).
* Remove duplicates from the list of collected types and use a common base class.
* Add line numbers or source position instead of the variable name.
BUG=v8:5935
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Original-Commit-Position: refs/heads/master@{#43791}
Committed: 0332bebde9
Review-Url: https://codereview.chromium.org/2707873002
Cr-Original-Commit-Position: refs/heads/master@{#43804}
Committed: 6cf880f4b8
Review-Url: https://codereview.chromium.org/2707873002
Cr-Commit-Position: refs/heads/master@{#43846}
This moves most of the logic contained in RegExpExecStub to CSA. Benefits are
mostly easier readability and hackability, and removal of a large chunk of
platform-specific assembly.
Exit frame construction and the final call remain in RegExpExecStub.
BUG=v8:5339,v8:592
Review-Url: https://codereview.chromium.org/2738413002
Cr-Commit-Position: refs/heads/master@{#43844}
The fast-path for Array.prototype.indexOf first checks whether the
receiver is a fast-mode JSArray (and there are no elements in the
prototype chain in case of holey arrays), then loads the known
JSArray::length, and afterwards calls ToInteger on the fromIndex.
But this ToInteger(fromIndex) call can cause arbitrary side effects if
the fromIndex is a JSReceiver, in particular it can invalidate the
assumptions about the fast-mode of the receiver and the length. In the
worst case this leads to OOB memory access.
Quick-fix is to bailout to the runtime if the fromIndex is neither a Smi
nor undefined, which represents the common cases.
R=jarin@chromium.org
BUG=chromium:702058
Review-Url: https://codereview.chromium.org/2756663002
Cr-Commit-Position: refs/heads/master@{#43843}
- Adds new load/store opcodes (0xc0, 0xc1) for S128 type.
- Implements these for ARM.
- Enables more WASM SIMD tests, and adds new LoadStoreLoad test.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2745853002
Cr-Commit-Position: refs/heads/master@{#43841}
This reverts commit 58ff145ef0.
Reason for revert: the bug in git-numberer has been fixed and deployed.
Original change's description:
> [release] Temporarily disable gerrit for merge tools.
>
> BUG=chromium:698845
> NOTRY=true
> TBR=hablich@chromium.org,tandrii@chromium.org
>
> Change-Id: I970c984c5e9bd23ca3d951d13243d107fc2a2e3f
> Reviewed-on: https://chromium-review.googlesource.com/451280
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Hablich <hablich@chromium.org>
> Commit-Queue: Michael Hablich <hablich@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43646}
R=machenbach@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=chromium:698845
Change-Id: I34b12a36c21a2d7a46eb67bce0536298a0582dd5
Reviewed-on: https://chromium-review.googlesource.com/455799
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43840}
'const' type qualifier on return type has no effect and
produces compiler warnings.
BUG=
Review-Url: https://codereview.chromium.org/2751513004
Cr-Commit-Position: refs/heads/master@{#43839}
When generating the code for an illegal (non-js-compliant) wrapper for
a js function, we were generating a zero constant of the return type.
This failed on ia32 if the return type is i64.
The correct thing to do is to return two i32 zero constants.
R=titzer@chromium.org
BUG=v8:6104, v8:6096
Change-Id: Idc0dd8d3eef901c22d5278d97f1879b000a18588
Reviewed-on: https://chromium-review.googlesource.com/455857
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43835}
That way, we don't need to create a context-less constructor function.
Instead, we use the constructor_or_backpointer (or null) field, and
rename it to constructor_or_fti_or_backpointer so nobody is confused.
Note that technically, we still have JSFunctions without contexts, as
they're temporarily created in the deoptimizer.
BUG=v8:6084
R=dcheng@chromium.org,bmeurer@chromium.org,verwaest@chromium.org
Change-Id: I084f052533c317f2cbfb9c35e1acf40263c6257b
Reviewed-on: https://chromium-review.googlesource.com/454636
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43834}
Marking shared functions for tier-up was optimizing the functions
non-concurrently, to avoid the case where the same shared function is
optimized concurrently by multiple JS functions. This was particularly a
problem for small functions, which (if called in a loop) could get
marked for optimisation quite quickly.
In this CL, the shared function is instead marked as having an active
optimization job running, and these do not spawn a compilation job.
BUG=chromium:693590
BUG=chromium:700863
BUG=chromium:701665
Change-Id: I2b1c5af8e7aa8d779f86814c22c65c78bee0630f
Reviewed-on: https://chromium-review.googlesource.com/455779
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43833}
Adds a TestTypeof bytecode to deal with comparisons of the form:
typeof(object) === 'string';
Also adds support to Turbofan to perform these comparisons without
inserting checkpoints.
BUG=v8:4280,v8:5267
Change-Id: Ib5cc1c6816dfe70a4120838d8eada2fc0267750f
Reviewed-on: https://chromium-review.googlesource.com/454837
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43832}
This adds one of the release unittests to presubmit.
Different entry points for CI and CQ are required.
More tests will follow in subsequent CLs.
BUG=chromium:701296
NOTRY=true
Change-Id: Ie96fba873f77df14efb1dc54388f075c056b64a6
Reviewed-on: https://chromium-review.googlesource.com/454639
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43831}
There's no point in trying to convert to a string, as this runtime
function must always be called with Strings, otherwise there's a bug.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2748253004
Cr-Commit-Position: refs/heads/master@{#43830}
The function "foo" in "base_getter_test" was picking up a left-over
optimised code object from foo's code map, the third time that
base_getter_test was run, instead of optimising it itself. This
broke the assumptions of the test, that each case was functionally
independent from the others, and had started off with empty feedback
and no optimised code.
This breaks the test though, so we have to blacklist it pending a fix
to the root cause (http://crbug.com/v8/6101).
Review-Url: https://codereview.chromium.org/2750623004
Cr-Commit-Position: refs/heads/master@{#43828}
This fixes a TSAN data race when writing the forwarding pointer in
MigrateObject and reading the object as a LayoutDescriptor when trying
to figure out the layout of another object in parallel.
BUG=chromium:701732
Change-Id: I1e291fa1afb42771244e1346680164de71c3a838
Reviewed-on: https://chromium-review.googlesource.com/455817
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43826}
It does not really matter for the preparser
but do it for sake of consistency.
BUG=
Change-Id: I2f58486cb3a8b866bbfa35b398abc7b5ead02ee7
Reviewed-on: https://chromium-review.googlesource.com/455797
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#43825}
