- 11 May, 2021 1 commit
-
-
Luis Fernando Pardo Sixtos authored
This change adds support for `const` redeclaration on REPL mode with the semantincs recommended in the design doc: 1) REPL scripts should not be able to reassign bindings to `const` variables. 2) Re-declaring `const` variables of page scripts is not allowed in REPL scripts. 3) Re-declearing `const` variables is not allowed in the same REPL script. 4) `const` re-declaration is allowed across separate REPL scripts. 5) Old references to previously declared variables get updated with the new value, even those references from within optimized functions. Design doc: https://goo.gle/devtools-const-repl Bug: chromium:1076427 Change-Id: Ic73d2ae7fcfbfc1f5b58f61e0c3c69e9c4d85d77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865721Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74510}
-
- 06 Dec, 2019 1 commit
-
-
Simon Zünd authored
This is a reland of 5bddc0e1 The original CL was speculatively reverted as it was suspected to cause failures on the non-determinism bot. This was ultimately confirmed to not be the case, so this CL is safe to reland as-is. Original change's description: > Implement top-level await for REPL mode > > Design doc: bit.ly/v8-repl-mode > > This CL allows the usage of 'await' without wrapping code in an async > function when using REPL mode in global evaluate. REPL mode evaluate > is changed to *always* return a Promise. The resolve value of the > promise is the completion value of the REPL script. > > The implementation is based on two existing mechanisms: > - Similar to async functions, the content of a REPL script is > enclosed in a synthetic 'try' block. Any thrown error > is used to reject the Promise of the REPL script. > > - The content of the synthetic 'try' block is also re-written the > same way a normal script is. This is, artificial assignments to > a ".result" variable are inserted to simulate a completion > value. The difference for REPL scripts is, that ".result" is > used to resolve the Promise of the REPL script. > > - ".result" is not returned directly but wrapped in an object > literal: "{ .repl_result: .result}". This is done to prevent > resolved promises from being chained and resolved prematurely: > > > Promse.resolve(42); > > should evaluate to a promise, not 42. > > Bug: chromium:1021921 > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65273} TBR: yangguo@chromium.org,verwaest@chromium.org Bug: chromium:1021921 Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65360}
-
- 04 Dec, 2019 1 commit
-
-
Maya Lekova authored
This reverts commit 5bddc0e1. Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863 Original change's description: > Implement top-level await for REPL mode > > Design doc: bit.ly/v8-repl-mode > > This CL allows the usage of 'await' without wrapping code in an async > function when using REPL mode in global evaluate. REPL mode evaluate > is changed to *always* return a Promise. The resolve value of the > promise is the completion value of the REPL script. > > The implementation is based on two existing mechanisms: > - Similar to async functions, the content of a REPL script is > enclosed in a synthetic 'try' block. Any thrown error > is used to reject the Promise of the REPL script. > > - The content of the synthetic 'try' block is also re-written the > same way a normal script is. This is, artificial assignments to > a ".result" variable are inserted to simulate a completion > value. The difference for REPL scripts is, that ".result" is > used to resolve the Promise of the REPL script. > > - ".result" is not returned directly but wrapped in an object > literal: "{ .repl_result: .result}". This is done to prevent > resolved promises from being chained and resolved prematurely: > > > Promse.resolve(42); > > should evaluate to a promise, not 42. > > Bug: chromium:1021921 > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65273} TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1021921 Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65333}
-
- 02 Dec, 2019 1 commit
-
-
Simon Zünd authored
Design doc: bit.ly/v8-repl-mode This CL allows the usage of 'await' without wrapping code in an async function when using REPL mode in global evaluate. REPL mode evaluate is changed to *always* return a Promise. The resolve value of the promise is the completion value of the REPL script. The implementation is based on two existing mechanisms: - Similar to async functions, the content of a REPL script is enclosed in a synthetic 'try' block. Any thrown error is used to reject the Promise of the REPL script. - The content of the synthetic 'try' block is also re-written the same way a normal script is. This is, artificial assignments to a ".result" variable are inserted to simulate a completion value. The difference for REPL scripts is, that ".result" is used to resolve the Promise of the REPL script. - ".result" is not returned directly but wrapped in an object literal: "{ .repl_result: .result}". This is done to prevent resolved promises from being chained and resolved prematurely: > Promse.resolve(42); should evaluate to a promise, not 42. Bug: chromium:1021921 Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65273}
-
- 06 Nov, 2019 1 commit
-
-
Simon Zünd authored
Design doc: bit.ly/v8-repl-mode This CL adds a new REPL mode that can be used via DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration of 'let' bindings at the moment. Example: REPL Input 1: let x = 21; REPL Input 2: let x = 42; This would normally throw a SyntaxError, but works in REPL mode. The implementation is done by: - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo} and script {Scope}. - Each global let declaration still gets a slot reserved in the respective {ScriptContext}. - When a new REPL mode {ScriptContext} is created, name clashes for let bindings are not reported as errors. - Declarations, loads and stores for global let in REPL mode are now "load/store global" instead of accessing their respective context slot directly. This causes a lookup in the ScriptContextTable where the found slot for each name is guaranteed to be the same (the first one). Bug: chromium:1004193, chromium:1018158 Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64793}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 29 May, 2018 1 commit
-
-
Sebastien Marchand authored
see crbug.com/841460 , we recently hit some build issues when using Goma + jumbo builds because of a conflict on the definition of CONST, v8 defines it in globals.h and including windows.h also defines it. It should be possible to fix this by adding a bunch of #undef CONST but it seems a little bit hacky and might not always work (this could only fix the problem temporary if the jumbo merge limit changes and cause some include files to get included in a different order). Renaming the v8 definition of CONST to kConst, this follows the style guide guidelines: "there is no reason to change old code to use constant-style names, unless the old names are actually causing a compile-time problem" (https://google.github.io/styleguide/cppguide.html#Enumerator_Names) I also had to turn the PropertyConstness enum into an enum class to avoid some conflicts (both PropertyConstness and VariableMode define kConst). Bug: chromium:841460 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I2b70b9095374e88a5ae364cc557b39f20a3ab60f Reviewed-on: https://chromium-review.googlesource.com/1064197Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org> Cr-Commit-Position: refs/heads/master@{#53413}
-
- 26 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46229}
-
- 25 Jun, 2017 1 commit
-
-
machenbach authored
Revert of Make some functions that are hit during renderer startup available for inlining (patchset #3 id:40001 of https://codereview.chromium.org/2950993002/ ) Reason for revert: Blocks roll: https://codereview.chromium.org/2954833002/ E.g.: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/449680 https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/324953 Please include those chromium trybots on reland. Maybe missing symbol export? Original issue's description: > Make some functions that are hit during renderer startup available for inlining > > This is towards closing the perf gap between the MSVC build (which uses link- > time optimization) and Clang (where LTO isn't ready on Windows yet). We did > a study (see bug) to see which non-inlined functions are hit a lot during render > start-up, and which would be inlined during LTO. This should benefit performance > in all builds which currently don't use LTO (Android, Linux, Mac) as well as > the Win/Clang build. > > The binary size of chrome_child.dll increases by 2KB with this. > > BUG=chromium:728324 > > Review-Url: https://codereview.chromium.org/2950993002 > Cr-Commit-Position: refs/heads/master@{#46191} > Committed: https://chromium.googlesource.com/v8/v8/+/d00d52be1fce9c1bf5558c8b26bf984efd09e65b TBR=jochen@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org,vogelheim@chromium.org,marja@chromium.org,mlippautz@chromium.org,thakis@chromium.org,hans@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:728324 NOTRY=true NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2955793002 Cr-Commit-Position: refs/heads/master@{#46195}
-
- 23 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46191}
-
- 22 Jun, 2017 1 commit
-
-
Marja Hölttä authored
let f = function g() { ... } declares "g" inside the function. This CL makes the preparser declare it too, and saves + restores the scope data for it. BUG=v8:5516 Change-Id: Id4c64f446d30f5252038cfb0f0f473b85ba24a9b Reviewed-on: https://chromium-review.googlesource.com/544816 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#46133}
-
- 08 May, 2017 1 commit
-
-
Adam Klein authored
This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
-
- 10 Feb, 2017 1 commit
-
-
neis authored
R=gsathya@chromium.org TBR=adamk@chromium.org BUG= Review-Url: https://codereview.chromium.org/2688143002 Cr-Commit-Position: refs/heads/master@{#43096}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 03 Nov, 2016 1 commit
-
-
verwaest authored
This turns the ZoneList with minimum 6 words overhead into a linked list through variables, using 2 words for the empty list. Additionally the average number of pointers per entry goes down to the optimal 1 per variable that's in a list. This does introduce 1 pointer unnecessary overhead for dynamic variables. If that becomes a problem we could distinguish between variables in lists and variables not in lists. We can distinguish them at construction-time. BUG=v8:5209 Review-Url: https://codereview.chromium.org/2475433002 Cr-Commit-Position: refs/heads/master@{#40714}
-
- 07 Oct, 2016 1 commit
-
-
adamk authored
Both bits of code were pointed out by our test coverage tools. R=gsathya@chromium.org Review-Url: https://codereview.chromium.org/2394403002 Cr-Commit-Position: refs/heads/master@{#40095}
-
- 09 Sep, 2016 1 commit
-
-
marja authored
TBR=bmeurer@chromium.org BUG=v8:5294 Review-Url: https://codereview.chromium.org/2324783002 Cr-Commit-Position: refs/heads/master@{#39304}
-
- 31 Aug, 2016 1 commit
-
-
adamk authored
The only remaining use of this VariableMode is for the names of sloppy named function expressions. This patch instead uses CONST for such bindings (just as we do in strict mode) and instead marks those Variables specially. During code generation a new helper method, Variable::throw_on_const_assignment(), is called to decide whether to throw or silently ignore the assignment. Review-Url: https://codereview.chromium.org/2233673003 Cr-Commit-Position: refs/heads/master@{#39052}
-
- 26 Aug, 2016 1 commit
-
-
verwaest authored
This interleaves setting names and values in the scope info. It's a little messy since globals and locals are interleaved, but afaiu globals is going away. BUG=v8:5209 Review-Url: https://codereview.chromium.org/2272293004 Cr-Commit-Position: refs/heads/master@{#38925}
-
- 25 Aug, 2016 1 commit
-
-
heimbuef authored
Used a BitField to for Variable fields instead of relying on the compiler, saving some memory probably. This reduces sizeof(Variable) from 64 to 40 on x64 BUG=v8:5209 Review-Url: https://codereview.chromium.org/2257493002 Cr-Commit-Position: refs/heads/master@{#38891}
-
- 18 Aug, 2016 1 commit
-
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. Fixing it: - Don't include stuff in headers unless necessary. - Include the stuff you need, not some other stuff that happens to include the stuff you need. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2246203005 Cr-Commit-Position: refs/heads/master@{#38708}
-
- 16 Aug, 2016 2 commits
-
-
hablich authored
Revert of Better pack fields in Variable (patchset #1 id:1 of https://codereview.chromium.org/2253513002/ ) Reason for revert: Revert: Breaks ARM build: https://uberchromegw.corp.google.com/i/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/2999 Original issue's description: > Better pack fields in Variable > > This reduces sizeof(Variable) from 64 to 40 on x64 > > BUG=v8:5209 > > Committed: https://crrev.com/d84343568047c8621a6b8f88f20a7f34586321b8 > Cr-Commit-Position: refs/heads/master@{#38659} TBR=marja@chromium.org,jkummerow@chromium.org,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5209 Review-Url: https://codereview.chromium.org/2249203002 Cr-Commit-Position: refs/heads/master@{#38666}
-
verwaest authored
This reduces sizeof(Variable) from 64 to 40 on x64 BUG=v8:5209 Review-Url: https://codereview.chromium.org/2253513002 Cr-Commit-Position: refs/heads/master@{#38659}
-
- 12 Aug, 2016 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2231813003 Cr-Commit-Position: refs/heads/master@{#38599}
-
- 08 Aug, 2016 1 commit
-
-
neis authored
Introduces a new VariableLocation MODULE for variables that live in a module's export table. Scope analysis sets this for the approriate variables. Not yet supported by any backend. Also, treats all imports as CONST bindings (including namespace imports), rather than having new special variable modes. BUG= Review-Url: https://codereview.chromium.org/2199283002 Cr-Commit-Position: refs/heads/master@{#38426}
-
- 18 Jul, 2016 1 commit
-
-
neis authored
Highlights: - Record all imports and exports in the ModuleDescriptor. - Remove ImportDeclaration; instead, introduce a new variable kind for imports. - Set name on default exported anonymous functions. Still to do: declaration of namespace imports. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2108193003 Cr-Commit-Position: refs/heads/master@{#37815}
-
- 30 Jun, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2109773004 Cr-Commit-Position: refs/heads/master@{#37426}
-
- 20 Jun, 2016 1 commit
-
-
adamk authored
Runtime_DeclareLookupSlot is used when generating code for var and function declarations originating in an eval. Over time, it's accumulated quite a bit of cruft, which this CL removes: - With legacy const gone, lookup slots never have any property attributes. - There was a bit signaling that the variable was from an eval, but that was redundant since DeclareLookupSlot is only used for eval. - Some Proxy-related code didn't make sense here. Its name was also not terribly clear: while "LookupSlot" is used in several places, this particular function is only used for declaring variables and functions inside sloppy eval. Renamed (and split into two) to make this clear for future archeologists. Also added various DCHECKs to check the assumptions being made. Review-Url: https://codereview.chromium.org/2061173002 Cr-Commit-Position: refs/heads/master@{#37111}
-
- 19 Apr, 2016 1 commit
-
-
adamk authored
Now that all 'const' declarations are of the ES2015 variety, the only use of CONST_LEGACY is for function name bindings in sloppy mode named function expressions. This patch aims to delete all code meant to handle other cases, which mostly had to do with hole initialization/hole checks. Since function name bindings are initialized at entry to a function, it's impossible to ever observe one in an uninitialized state. To simplify the patch further, it removes the `IMPORT` VariableMode, as it's not likely to be needed (IMPORT is identical to CONST for the purpose of VariableMode). Review URL: https://codereview.chromium.org/1895973002 Cr-Commit-Position: refs/heads/master@{#35632}
-
- 18 Feb, 2016 1 commit
-
-
adamk authored
This frees up one bit in FunctionKind, which I plan to make slightly more syntactic info about functions available in SharedFunctionInfo (needed for ES2015 Function.name support). BUG=v8:3956, v8:4760 LOG=n Review URL: https://codereview.chromium.org/1704223002 Cr-Commit-Position: refs/heads/master@{#34125}
-
- 26 Nov, 2015 1 commit
-
-
rossberg authored
Moves all files related to AST and scopes into ast/, and all files related to scanner & parser to parsing/. Also eliminates a couple of spurious dependencies. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1481613002 Cr-Commit-Position: refs/heads/master@{#32351}
-
- 12 Oct, 2015 1 commit
-
-
littledan authored
Previously, name conflicts between var and let declarations were only made into exceptions if they were visible at parse-time. This patch adds runtime checks so that sloppy-mode direct eval can't introduce conflicting var declarations. The change is implemented by traversing the scope chain when a direct eval introduces a var declaration to look for conflicting let declarations, up to the function boundary. BUG=v8:4454 R=adamk LOG=Y Review URL: https://codereview.chromium.org/1382513003 Cr-Commit-Position: refs/heads/master@{#31211}
-
- 14 Aug, 2015 1 commit
-
-
mstarzinger authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/1297583002 Cr-Commit-Position: refs/heads/master@{#30172}
-
- 23 Jul, 2015 1 commit
-
-
rossberg authored
While at it, remove the notion of INTERNAL variables. @caitp: Took some parts from your CL, since I was blocked on the temp scope bug. R=mstarzinger@chromium.org BUG=512574 LOG=N Review URL: https://codereview.chromium.org/1250513004 Cr-Commit-Position: refs/heads/master@{#29812}
-
- 15 Jul, 2015 1 commit
-
-
https://codereview.chromium.org/1218783005ishell authored
Review URL: https://codereview.chromium.org/1228373011 Cr-Commit-Position: refs/heads/master@{#29682}
-
- 06 Jul, 2015 1 commit
-
-
ishell authored
Review URL: https://codereview.chromium.org/1218783005 Cr-Commit-Position: refs/heads/master@{#29498}
-
- 01 Jun, 2015 1 commit
-
-
erikcorry authored
When compiling on a laptop I like to concatenate the small test files. This makes a big difference to compile times. These changes make that easier. R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/1163803002 Cr-Commit-Position: refs/heads/master@{#28742}
-
- 19 May, 2015 2 commits
-
-
wingo authored
This reapplies https://codereview.chromium.org/1136073002, along with the followups: Remove Scope::scope_uses_this_ flag https://codereview.chromium.org/1128963005 and PPC: Resolve references to "this" the same way as normal variables https://codereview.chromium.org/1134073003 R=rossberg@chromium.org LOG=N BUG= Review URL: https://codereview.chromium.org/1136883006 Cr-Commit-Position: refs/heads/master@{#28458} Review URL: https://codereview.chromium.org/1140633003 Cr-Commit-Position: refs/heads/master@{#28484}
-
wingo authored
Revert of Reapply "Resolve references to "this" the same way as normal variables"" (patchset #2 id:20001 of https://codereview.chromium.org/1136883006/) Reason for revert: Something is deserializing "this" declarations as Variable::NORMAL and not Variable::THIS https://codereview.chromium.org/1136123010/ Original issue's description: > Reapply "Resolve references to "this" the same way as normal variables"" > > This reapplies https://codereview.chromium.org/1136073002, along with > the followups: > > Remove Scope::scope_uses_this_ flag > https://codereview.chromium.org/1128963005 > > and > > PPC: Resolve references to "this" the same way as normal variables > https://codereview.chromium.org/1134073003 > > R=yangguo@chromium.org, rossberg@chromium.org > LOG=N > BUG= > > Committed: https://crrev.com/1efc1e4f7a3d30d5225e9d5cb2585cad7cb17099 > Cr-Commit-Position: refs/heads/master@{#28458} TBR=rossberg@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1146733002 Cr-Commit-Position: refs/heads/master@{#28473}
-