Commit Graph

35 Commits

Author SHA1 Message Date
Adam Klein
49898aad76 Remove always-true --harmony-async-iteration runtime flag
It was shipped in Chrome 63.

Bug: v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icc00b8300622d1c7b5662be8ac5e425b9781f666
Reviewed-on: https://chromium-review.googlesource.com/858381
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50558}
2018-01-12 20:14:34 +00:00
Daniel Ehrenberg
94d53d8742 [class] Split out static fields into a separate flag
This patch implements https://github.com/tc39/proposal-class-fields/pull/65
and https://github.com/tc39/proposal-static-class-features/ by
splitting out instance and static field declarations into separate
flags for the separate proposals. Instance class fields is currently
at Stage 3 whereas static class fields is currently at Stage 2.

Bug: v8:5367
Change-Id: I133c945fd0b22dc5718c7bb61b10f22348087acd
Reviewed-on: https://chromium-review.googlesource.com/839778
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50293}
2017-12-22 13:04:51 +00:00
Sathya Gunasekaran
42bc9e8c64 [class] Expand bytecode expectations coverage for class fields
Bug: v8:5367
Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba
Reviewed-on: https://chromium-review.googlesource.com/793150
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49665}
2017-11-28 13:21:36 +00:00
Sathya Gunasekaran
94dfb8a1f4 [class] Add harmony-public-fields flag
Change the existing uses of the harmony-class-fields flag to
harmony-public-fields so that we can stage this separately
from the upcoming harmony-private-fields to get some
clusterfuzz coverage.

Bug: v8:5367
Change-Id: I76cdefa4faf34eae73d3a5f6d6089cf75677732a
Reviewed-on: https://chromium-review.googlesource.com/792940
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49661}
2017-11-28 10:19:29 +00:00
Sathya Gunasekaran
4ca9d843f8 [class] Store class fields initializer on the constructor
Previously, the class fields initializer function was stored on a
synthetic context allocated variable. This approach had sevaral
problems:

- We didn't know that class literal had fields until after we had
completely parsed the class literal. This meant that we had to go back
and fix up the scope of the constructor to have this synthetic
variable. This resulted in mismatch between parser and preparsed scope
data.

- This synthetic variable could potentially resolve to an initializer
of an outer class.

For ex:
class X extends Object {
  c = 1;
  constructor() {
    var t = () => {
      class P extends Object {
        constructor() {
          var t = () => { super(); };
          t();
        }
      }
      super();
    }
    t();
  }
}

In this the inner class P could access the outer class X's initiliazer
function. We would have to maintain extra metadata to make sure this
doesn't happen.

Instead this new approach uses a private symbol to store the
initializer function on the class constructor itself.

For the base constructor case, we can simply check for a bit on the
constructor function literal to see if we need to emit code that loads
and calls this initializer function. Therefore, we don't pay the cost
of loading this function in case there are no class fields.

For the derived constructor case, there are two possiblities:
(a) We are in a super() call directly in the derived constructor:

In this case we can do a check similar to the base constructor check,
we can check for a bit on the derived constructor and emit code for
loading and calling the initializer function.

This is usually the common case and we don't pay any cost for not using
class fields.

(b) We are in a super() call inside an arrow function in the derived
constructor:

In this case, we /always/ emit code to load and call the initializer
function. If the function doesn't exist then we have undefined and we
don't call anything. Otherwise we call the function.

super() can't be called twice so even if we emit code to load and call
the initializer function multiple times, it doesn't matter because it
would have already been an error.

Bug: v8:5367
Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88
Reviewed-on: https://chromium-review.googlesource.com/781660
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49628}
2017-11-27 10:35:11 +00:00
Andreas Haas
ffee558e14 [cleanup] use unique_ptr for the DefaultPlatform
With this CL, {CreateDefaultPlatform} returns a unique_ptr to indicate
that the caller owns the returned memory. We had several memory leaks
where the memory of the DefaultPlatform did not get deallocated.

In addition, the {TracingController} of the {DefaultPlatform} also gets
received as a unique_ptr. Thereby we document that the {DefaultPlatform}
takes ownership of the {TracingController}. Note that the memory of the
{TracingController} was already owned by the {DefaultPlatform}, but it
was not documented in the interface, and it was used incorrectly in
tests.

This CL fixes the asan issues in 
https://chromium-review.googlesource.com/c/v8/v8/+/753583	
([platform] Implement TaskRunners in the DefaultPlatform)

R=rmcilroy@chromium.org

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d1a6d3b22bb8289dc050b1977e4f58381cec675
Reviewed-on: https://chromium-review.googlesource.com/755033
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49349}
2017-11-14 09:57:18 +00:00
Adam Klein
ce05578aa6 [api] Mark non-Isolate constructors of String::Utf8Value/Value for deprecation
Also remove last internal callers of the to-be-deprecated APIs.

Bug: v8:2487
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id72cf363eac86e4b4dbf7df83bdb848071260b90
Reviewed-on: https://chromium-review.googlesource.com/639326
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47690}
2017-08-29 17:42:34 +00:00
Michael Starzinger
45b4522e40 [fullcodegen] Remove --stress-fullcodegen flag.
This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.

R=rmcilroy@chromium.org
BUG=v8:6409

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
2017-08-10 09:52:49 +00:00
Ross McIlroy
05207b098a [Interpreter] Replace --ignition flag with a --stress-fullcodegen
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.

This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.

BUG=v8:5203, v8:6409, v8:6589

Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
2017-07-13 13:05:00 +00:00
Wiktor Garbacz
9a8efd8a4e [cleanup] Remove return after UNREACHABLE
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9
Reviewed-on: https://chromium-review.googlesource.com/507287
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#45458}
2017-05-22 13:10:01 +00:00
caitp
0423341034 [async-iteration] implement Async-from-Sync Iterator
Introduce a new Object to allow GetIterator("async") to function when the
iterable does not have a Symbol.asyncIterator method.

This patch has been split out from https://codereview.chromium.org/2622833002/
and incorporates test cases.

BUG=v8:5855, v8:4483
R=jgruber@chromium.org, rmcilroy@chromium.org, neis@chromium.org
TBR=hpayer@chromium.org, bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2645313003
Cr-Commit-Position: refs/heads/master@{#43419}
2017-02-24 17:48:49 +00:00
neis
1744727d82 [interpreter] Add some bytecode tests for modules.
R=rmcilroy@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2393453003
Cr-Commit-Position: refs/heads/master@{#39963}
2016-10-04 18:42:36 +00:00
neis
99cfa5f620 [interpreter] Remove redundant flag from bytecode cctest suite.
This removes the execute_ flag, which was always the negation of top_level_.

R=rmcilroy@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2390163003
Cr-Commit-Position: refs/heads/master@{#39961}
2016-10-04 16:30:15 +00:00
rmcilroy
38c57c5ddb [Test] Don't call deprecated readdir_r in generate-bytecode-expectations.
Review-Url: https://codereview.chromium.org/2385653002
Cr-Commit-Position: refs/heads/master@{#39911}
2016-09-30 11:05:40 +00:00
leszeks
b28b7e1328 [Interpreter] Remove constant pool type in tests
For historical reasons, the interpreter's bytecode expectations tests
required a type for the constant pool. This had two disadvantages:

 1. Strings and numbers were not visible in mixed pools, and
 2. Mismatches of pool types (e.g. when rebaselining) would cause parser
    errors

This removes the pool types, making everything 'mixed', but appending
the values to string and number valued constants. Specifying a pool type
in the *.golden header now prints a warning (for backwards compatibility).

BUG=v8:5350

Review-Url: https://codereview.chromium.org/2310103002
Cr-Commit-Position: refs/heads/master@{#39216}
2016-09-06 16:11:23 +00:00
marja
0645135446 Separate CompilationInfo into its own file.
This way, many files which only need CompilationInfo but not compiler.h
and its dependencies can include just compilation-info.h.

BUG=

Review-Url: https://codereview.chromium.org/2284313003
Cr-Commit-Position: refs/heads/master@{#39038}
2016-08-31 08:49:59 +00:00
neis
88a795d1c8 Remove the --ignition-generators flag.
This flag has been enabled by default for over a month now.

R=mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2176143002
Cr-Commit-Position: refs/heads/master@{#38020}
2016-07-25 12:56:27 +00:00
jochen
0a6ccaf268 Replace SmartPointer<T> with unique_ptr<T>
R=ishell@chromium.org,bmeurer@chromium.org
TBR=rossberg@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2175233003
Cr-Commit-Position: refs/heads/master@{#38009}
2016-07-25 11:14:34 +00:00
jochen
356a85be5d Provide a convenience array buffer allocator
BUG=none
R=ulan@chromium.org

Review-Url: https://codereview.chromium.org/2101413002
Cr-Commit-Position: refs/heads/master@{#37365}
2016-06-29 07:42:40 +00:00
machenbach
cec0ed0f77 [icu] Support loading data file from default location
This allows using icu data, bundled in the icudtl.dat file,
to be loaded automatically from a default location
side-by-side with the executable.

The v8 stand-alone default is still to use statically
linked ICU data, but this will be switched in a separate
follow-up CL.

BUG=chromium:616033
LOG=y

Review-Url: https://codereview.chromium.org/2042253002
Cr-Commit-Position: refs/heads/master@{#36823}
2016-06-08 12:11:34 +00:00
rmcilroy
04927031d0 [Interpreter] Fix typo in generate-bytecode-expectations.
BUG=v8:4681
LOG=N

Review URL: https://codereview.chromium.org/1894073007

Cr-Commit-Position: refs/heads/master@{#35679}
2016-04-20 21:05:42 +00:00
neis
d0ccddd032 First version of the new generators implementation.
Behind --ignition-generators. Does not yet support Turbofan.

TBR=bmeurer@chromium.org
BUG=v8:4907
LOG=n

Review URL: https://codereview.chromium.org/1884183002

Cr-Commit-Position: refs/heads/master@{#35584}
2016-04-18 14:13:30 +00:00
adamk
ed18aa65ea Remove support for legacy const, part 1
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
are no more. This lets us remove a bunch of code from many parts of the
codebase.

In this patch, I remove parser support for generating legacy const variables
from const declarations. This also removes the special "illegal declaration"
bit from Scope, which has ripples into all compiler backends.

Also gone are any tests which relied on legacy const declarations.

Note that we do still generate a Variable in mode CONST_LEGACY in one case:
function name bindings in sloppy mode. The likely fix there is to add a new
Variable::Kind for this case and handle it appropriately for stores in each
backend, but I leave that for a later patch to make this one completely
subtractive.

Review URL: https://codereview.chromium.org/1819123002

Cr-Commit-Position: refs/heads/master@{#35002}
2016-03-22 17:52:13 +00:00
rmcilroy
18109232c1 [Interpreter] Add bytecode generator expectations for super calls.
BUG=v8:4682
LOG=N

Review URL: https://codereview.chromium.org/1805503003

Cr-Commit-Position: refs/heads/master@{#34819}
2016-03-16 14:42:55 +00:00
ssanfilippo
dc71deb077 [Interpreter] Silence runtime errors in generate-bytecode-expectations.
Runtime errors will be suppressed in --rebaseline mode, unless the
--verbose flag is passed.

The reasoning behind (rebaseline && !verbose) and not just (verbose)
is to suppress harmless noise while updating the expectation for
existing, known good snippets, without hiding actually relevant
errors when the tool is used to write new expectation files.

In fact, some tests are supposed to produce a runtime error, which
might nevertheless alarm a developer who is just --rebaseline'ing.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1742723003

Cr-Commit-Position: refs/heads/master@{#34385}
2016-03-01 10:43:22 +00:00
ssanfilippo
e039f63a4f [Interpreter] Multiple input files for generate-bytecode-expectations.
When operating in --rebaseline mode, each of the files will be updated.
In --raw-js mode, all the expectations will be written to the same file.
In default mode no more than one input file is accepted.

On POSIX systems, --rebaseline will autodiscover golden files when run
from the project root and no input file is provided.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1737623002

Cr-Commit-Position: refs/heads/master@{#34324}
2016-02-26 12:04:24 +00:00
ssanfilippo
6ae030590d [Interpreter] Refactor bytecode generator test suite.
Bytecode expectations have been moved to external (.golden) files,
one per test. Each test in the suite builds a representation of the
the compiled bytecode using BytecodeExpectationsPrinter. The output is
then compared to the golden file. If the comparision fails, a textual
diff can be used to identify the discrepancies.

Only the test snippets are left in the cc file, which also allows to
make it more compact and meaningful. Leaving the snippets in the cc
file was a deliberate choice to allow keeping the "truth" about the
tests in the cc file, which will rarely change, as opposed to golden
files.

Golden files can be generated and kept up to date using
generate-bytecode-expectations, which also means that the test suite
can be batch updated whenever the bytecode or golden format changes.

The golden format has been slightly amended (no more comments about
`void*`, add size of the bytecode array) following the consideration
made while converting the tests.

There is also a fix: BytecodeExpectationsPrinter::top_level_ was left
uninitialized, leading to undefined behaviour.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1717293002

Cr-Commit-Position: refs/heads/master@{#34285}
2016-02-25 12:07:19 +00:00
ssanfilippo
67f75e30da [Interpreter] Fix generate-bytecode-expectations help message.
--pool-type=int and double have now been merged into number.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1717633002

Cr-Commit-Position: refs/heads/master@{#34164}
2016-02-19 16:14:22 +00:00
ssanfilippo
4f0be51987 [Interpreter] Support relevant FLAG_s in generate-bytecode-expectations.
FLAG_legacy_const and FLAG_harmony_do_expressions can now be toggled
both through the command line and through the option header.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1716793002

Cr-Commit-Position: refs/heads/master@{#34160}
2016-02-19 15:52:58 +00:00
ssanfilippo
d2187182a7 [Interpreter] generate-bytecode-expectations improvements.
A few options and features have been added to the tool:

* an output file might be specified using --output=file.name
* a shortcut when the output file is also the input, which is handy
   when fixing golden files, --rebaseline.
* the input snippet might be optionally not wrapped in a top function,
   or not executed after compilation (--no-wrap and --no-execute).
* the name of the wrapper can be configured using --wrapper-name=foo

The same options can be configured via setters on the usual
BytecodeExpectationsPrinter.

The output file now includes all the relevant flags to reproduce it
when running again through the tool (usually with --rebaseline).

In particular, when running in --rebaseline mode, options from the
file header will override options specified in the command line.

A couple of other fixes and improvements:

* description of the handlers is now emitted (closing the TODO).
* the snippet is now correctly unquoted when double quotes are used.
* special registers (closure, context etc.) are now emitted as such,
   instead of displaying their numeric value.
* the tool can now process top level code as well.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1698403002

Cr-Commit-Position: refs/heads/master@{#34152}
2016-02-19 12:37:16 +00:00
ssanfilippo
e082ebdbf3 [Interpreter] Change the output format of generate-bytecode-expectations.
Now the tool produces a far more readable output format, which bears a
lot of resemblance to YAML. In fact, the output should be machine
parseable as such, one document per testcase. However, the output format
may be subject to changes in future, so don't rely on this property.

In general, the output format has been optimized for producing a meaningful
textual diff, while keeping a decent readability as well. Therefore, not
everything is as compact as it could be, e.g. for an empty const pool we get:

    constant pool: [
    ]

instead of:

    constant pool: []

Also, trailing commas are always inserted in lists.

Additionally, now the tool accepts its output format as input. When
operating in this mode, all the snippets are extracted, processed and
the output is then emitted as usual. If nothing has changed, the output
should match the input. This is very useful for catching bugs in the
bytecode generation by running a textual diff against a known-good file.

The core (namely bytecode-expectations.cc) has been extracted from the
original cc file, which provides the utility as usual. The definitions
in the matching header of the library have been moved into the
v8::internal::interpreter namespace.

The library exposes a class ExpectationPrinter, with a method
PrintExpectation, which takes a test snippet as input, and writes the
formatted expectation to the supplied stream. One might then use a
std::stringstream to retrieve the results as a string and run it through
a diff utility.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1688383003

Cr-Commit-Position: refs/heads/master@{#33997}
2016-02-15 15:20:33 +00:00
ssanfilippo
2f0ac9a2cd Reland of [Interpreter] Rename GetCountOperand to GetRegisterCountOperand.
Apparently, this BytecodeArrayIterator method was missed during the
previous refactor. No other (collateral) change was done.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1691433002

Cr-Commit-Position: refs/heads/master@{#33909}
2016-02-11 16:43:00 +00:00
ssanfilippo
db52dbbbfe [Interpreter] Print constant pool in generate-bytecode-expectations
This is a follow-up to https://crrev.com/1671863002, adding the
capability to print the contents of the constant pool. The expected
type of the pool is taken from command line, and it's either:

* string/int/double: assume all constants have the specified type.
  This way, we can emit a meaningful representation, e.g. a quoted
  string for type string and so on. All the constants in the pool must
  have the same type, otherwise one or more CHECK() will fail and the
  program will eventually crash.

* mixed: print the InstanceType tag instead of the actual value.
  This is the choice for those tests where the type of the constants in
  the pool is not uniform, however only a type tag is printed, not the
  actual value of the entries. SMIs are an exception, since they do not
  have an InstanceType tag, so kInstanceTypeDontCare is printed instead.

In addition to that, functions Print{ExpectedSnippet,BytecodeSequence}
have been extracted with no functional change. It's just for improving
readability, since the code is becoming quite long.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1686963002

Cr-Commit-Position: refs/heads/master@{#33888}
2016-02-11 11:27:08 +00:00
ssanfilippo
8bfd4a5ac9 [Interpreter] Handle negative ints in generate-bytecode-expectations.
The previous implementation used GetRawOperand(), which allows a nicely
unified handling of all scalar types, but returns an unsigned type.
Because of this, generate-bytecode-expectations couldn't properly handle
negative numbers.

This commit differentiate between different types of scalar operands and
uses the appropriate getter from i::interpreter::BytecodeArrayIterator,
thus correctly handling signed types where needed.

Two new helpers have been added to i::interpreter::Bytecodes:

 * IsImmediateOperandType()
 * IsIndexOperandType()

with the intuitive semantic.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1684113002

Cr-Commit-Position: refs/heads/master@{#33874}
2016-02-10 18:35:56 +00:00
ssanfilippo
d3604cdb68 [Interpreter] Initial generate-bytecode-expectations implementation.
generate-bytecode-expectations is a tool intended to work together
with test/cctest/test-bytecode-generator.cc in order to produce a
meaningful diff between testcases and the actual bytecode being emitted.

It does so by parsing and compiling Javascript to bytecode,
constructing the same data structure in the testcase and then running a
textual diff between the expected (i.e. the one encoded in the unit test)
and actual (i.e. the one built from the compiler output) representation.

This commit is a first step in this direction, achieving just the first
half of what we desire. At the moment, bytecodechecker can:

* take a code snippet from the command line and emit the expected structure.
* adhere to the same formatting rules of the test cases
  (this one is important for text diff and for copy and pasting too)

Still to do:

* parse unit tests:
    + extract code snippets
    + indent the code to match the input test case
    + allow flexibility in the input format
    + try to recognize and work around some macro magic (i.e. REPEAT_127)
* emit the representation of the constant pool and handlers vector
* run a textual diff

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1671863002

Cr-Commit-Position: refs/heads/master@{#33863}
2016-02-10 11:26:34 +00:00