- 22 Feb, 2018 1 commit
-
-
Sathya Gunasekaran authored
Bug: v8:5368 Change-Id: I7ec4bb6c0f50d8a72a12f5d4521c5fdcba526014 Reviewed-on: https://chromium-review.googlesource.com/929876Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#51479}
-
- 12 Jan, 2018 1 commit
-
-
Adam Klein authored
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}
-
- 22 Dec, 2017 1 commit
-
-
Daniel Ehrenberg authored
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}
-
- 28 Nov, 2017 2 commits
-
-
Sathya Gunasekaran authored
Bug: v8:5367 Change-Id: Ib24190f6cfc0765794a1a5d9ac33cf1c1e2b6fba Reviewed-on: https://chromium-review.googlesource.com/793150Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#49665}
-
Sathya Gunasekaran authored
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}
-
- 27 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
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}
-
- 14 Nov, 2017 1 commit
-
-
Andreas Haas authored
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/755033Reviewed-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}
-
- 29 Aug, 2017 1 commit
-
-
Adam Klein authored
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/639326Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47690}
-
- 10 Aug, 2017 1 commit
-
-
Michael Starzinger authored
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/584747Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47276}
-
- 13 Jul, 2017 1 commit
-
-
Ross McIlroy authored
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}
-
- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-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}
-
- 24 Feb, 2017 1 commit
-
-
caitp authored
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}
-
- 04 Oct, 2016 2 commits
-
-
neis authored
R=rmcilroy@chromium.org BUG= Review-Url: https://codereview.chromium.org/2393453003 Cr-Commit-Position: refs/heads/master@{#39963}
-
neis authored
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}
-
- 30 Sep, 2016 1 commit
-
-
rmcilroy authored
Review-Url: https://codereview.chromium.org/2385653002 Cr-Commit-Position: refs/heads/master@{#39911}
-
- 06 Sep, 2016 1 commit
-
-
leszeks authored
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}
-
- 31 Aug, 2016 1 commit
-
-
marja authored
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}
-
- 25 Jul, 2016 2 commits
-
-
neis authored
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}
-
jochen authored
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}
-
- 29 Jun, 2016 1 commit
-
-
jochen authored
BUG=none R=ulan@chromium.org Review-Url: https://codereview.chromium.org/2101413002 Cr-Commit-Position: refs/heads/master@{#37365}
-
- 08 Jun, 2016 1 commit
-
-
machenbach authored
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}
-
- 20 Apr, 2016 1 commit
-
-
rmcilroy authored
BUG=v8:4681 LOG=N Review URL: https://codereview.chromium.org/1894073007 Cr-Commit-Position: refs/heads/master@{#35679}
-
- 18 Apr, 2016 1 commit
-
-
neis authored
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}
-
- 22 Mar, 2016 1 commit
-
-
adamk authored
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}
-
- 16 Mar, 2016 1 commit
-
-
rmcilroy authored
BUG=v8:4682 LOG=N Review URL: https://codereview.chromium.org/1805503003 Cr-Commit-Position: refs/heads/master@{#34819}
-
- 01 Mar, 2016 1 commit
-
-
ssanfilippo authored
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}
-
- 26 Feb, 2016 1 commit
-
-
ssanfilippo authored
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}
-
- 25 Feb, 2016 1 commit
-
-
ssanfilippo authored
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}
-
- 19 Feb, 2016 3 commits
-
-
ssanfilippo authored
--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}
-
ssanfilippo authored
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}
-
ssanfilippo authored
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}
-
- 15 Feb, 2016 1 commit
-
-
ssanfilippo authored
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}
-
- 11 Feb, 2016 2 commits
-
-
ssanfilippo authored
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}
-
ssanfilippo authored
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}
-
- 10 Feb, 2016 2 commits
-
-
ssanfilippo authored
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}
-
ssanfilippo authored
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}
-