|
|
Created:
4 years, 5 months ago by bakkot Modified:
4 years, 5 months ago Reviewers:
Dan Ehrenberg, adamk CC:
adamk, v8-reviews_googlegroups.com Base URL:
https://chromium.googlesource.com/v8/v8.git@master Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
DescriptionAdd errors for declarations which conflict with catch parameters.
Catch parameters are largely treated as lexical declarations in the
block which contains their body for the purposes of early syntax errors,
with some exceptions outlined in B.3.5. This patch introduces most of
those errors, except those from `eval('for (var e of ...);')` inside of
a catch with a simple parameter named 'e'.
Note that annex B.3.5 allows var declarations to conflict with simple
catch parameters, except when the variable declaration is the init of a
for-of statement.
BUG=v8:5112, v8:4231
Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
Cr-Commit-Position: refs/heads/master@{#37462}
Patch Set 1 #
Total comments: 4
Patch Set 2 : const correctness #Patch Set 3 : add boolean #Patch Set 4 : remove outdated 'const' language #Patch Set 5 : rebase #Patch Set 6 : better error messages #Patch Set 7 : correct loop index #
Total comments: 7
Created: 4 years, 5 months ago
Messages
Total messages: 43 (17 generated)
Description was changed from ========== Add errors for declarations which conflict with catch parameters. Catch parameters are largely treated as lexical declarations in the block which contains their body for the purposes of early syntax errors, with some exceptions outlined in B.3.3. This patch introduces most of those errors, except those from `eval('for (var e of ...);')` inside of a catch with a simple parameter named 'e'. BUG=v8:5112,v8:4231 ========== to ========== Add errors for declarations which conflict with catch parameters. Catch parameters are largely treated as lexical declarations in the block which contains their body for the purposes of early syntax errors, with some exceptions outlined in B.3.5. This patch introduces most of those errors, except those from `eval('for (var e of ...);')` inside of a catch with a simple parameter named 'e'. Note that annex B.3.5 allows var declarations to conflict with simple catch parameters, except when the variable declaration is the init of a for-of statement. BUG=v8:5112,v8:4231 ==========
bakkot@google.com changed reviewers: + littledan@chromium.org
The CQ bit was checked by bakkot@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/8274) v8_linux_dbg_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/8251)
The CQ bit was checked by bakkot@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_nosnap_shared_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...) v8_win_nosnap_shared_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
https://codereview.chromium.org/2109733003/diff/1/src/parsing/parser.cc File src/parsing/parser.cc (right): https://codereview.chromium.org/2109733003/diff/1/src/parsing/parser.cc#newco... src/parsing/parser.cc:3643: // special case for legacy for (var/const x =.... in) It's only var at this point, right? Could you change the unrelated comment which happens to be adjacent to your change? https://codereview.chromium.org/2109733003/diff/1/src/parsing/parser.cc#newco... src/parsing/parser.cc:3723: parsing_result.descriptor.mode == VariableMode::VAR) Minor cleanup suggestion: since it occurs multiple times, make a boolean variable for this special case.
https://codereview.chromium.org/2109733003/diff/1/src/parsing/parser.cc File src/parsing/parser.cc (right): https://codereview.chromium.org/2109733003/diff/1/src/parsing/parser.cc#newco... src/parsing/parser.cc:3643: // special case for legacy for (var/const x =.... in) On 2016/06/29 at 20:24:32, Dan Ehrenberg wrote: > It's only var at this point, right? Could you change the unrelated comment which happens to be adjacent to your change? Done, and in a few other places. https://codereview.chromium.org/2109733003/diff/1/src/parsing/parser.cc#newco... src/parsing/parser.cc:3723: parsing_result.descriptor.mode == VariableMode::VAR) On 2016/06/29 at 20:24:32, Dan Ehrenberg wrote: > Minor cleanup suggestion: since it occurs multiple times, make a boolean variable for this special case. Done.
The CQ bit was checked by bakkot@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
This probably shouldn't be committed until after https://codereview.chromium.org/2110193002/, which touches some of the same code and is higher priority.
lgtm Thanks for the cleanup; I trust you to do the rebase when appropriate.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by bakkot@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...) v8_mac_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng/builds/4305) v8_mac_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel_ng_triggered/bui...)
The CQ bit was checked by bakkot@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Nontrivial changes since last lgtm (Adam's patch changed some semantics); PTAL.
lgtm Unfortunate, but makes sense. I wonder if it would've been OK to just use the location of the catch params rather than all the logic to find the declaration, but it's not too much and seems like a better error message.
By the way, any idea what's behind the failing Blink test http/tests/media/video-seek-to-middle.html ? I didn't see anything obvious. Should probably be figured out before submitting.
The CQ bit was checked by littledan@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by bakkot@google.com
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== Add errors for declarations which conflict with catch parameters. Catch parameters are largely treated as lexical declarations in the block which contains their body for the purposes of early syntax errors, with some exceptions outlined in B.3.5. This patch introduces most of those errors, except those from `eval('for (var e of ...);')` inside of a catch with a simple parameter named 'e'. Note that annex B.3.5 allows var declarations to conflict with simple catch parameters, except when the variable declaration is the init of a for-of statement. BUG=v8:5112,v8:4231 ========== to ========== Add errors for declarations which conflict with catch parameters. Catch parameters are largely treated as lexical declarations in the block which contains their body for the purposes of early syntax errors, with some exceptions outlined in B.3.5. This patch introduces most of those errors, except those from `eval('for (var e of ...);')` inside of a catch with a simple parameter named 'e'. Note that annex B.3.5 allows var declarations to conflict with simple catch parameters, except when the variable declaration is the init of a for-of statement. BUG=v8:5112,v8:4231 Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406 Cr-Commit-Position: refs/heads/master@{#37462} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406 Cr-Commit-Position: refs/heads/master@{#37462}
Message was sent while issue was closed.
A revert of this CL (patchset #6 id:100001) has been created in https://codereview.chromium.org/2112223002/ by bakkot@google.com. The reason for reverting is: Fuzzer claims it causes a crash..
Fixed the bug found by the fuzzer (was using the wrong index in a nested loop).
Message was sent while issue was closed.
adamk@chromium.org changed reviewers: + adamk@chromium.org
Message was sent while issue was closed.
Thanks for the fix, but I've got some comments on other parts of the CL (sorry I didn't take another pass on the original version). https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.cc File src/ast/scopes.cc (right): https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.cc#newc... src/ast/scopes.cc:613: Declaration* Scope::CheckLexDeclarationsConflictingWith( Is this only called on block scopes? Can you add a DCHECK to that effect if it's true? https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.cc#newc... src/ast/scopes.cc:615: int length = names->length(); Nit: should be no need to hoist this. https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.cc#newc... src/ast/scopes.cc:618: if (var != nullptr && IsLexicalVariableMode(var->mode())) { If my DCHECK suggestion above is correct, then can IsLexicalVariableMode ever be false here? https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.cc#newc... src/ast/scopes.cc:621: int decls_length = decls_.length(); Again, no need to hoist this out of the loop. https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.h File src/ast/scopes.h (right): https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.h#newco... src/ast/scopes.h:245: ZoneList<const AstRawString*>* names); Style: given that this arg isn't mutated by the callee, it ought to be a const reference (that is, "const ZoneList<const AstRawString*>&"). https://codereview.chromium.org/2109733003/diff/120001/src/ast/scopes.h#newco... src/ast/scopes.h:502: AstRawString* catch_variable_name() const { this should return a "const AstRawString*", non-const AstRawStrings really shouldn't exist (and only do because our hashmap is not typed enough). https://codereview.chromium.org/2109733003/diff/120001/src/parsing/parser.cc File src/parsing/parser.cc (right): https://codereview.chromium.org/2109733003/diff/120001/src/parsing/parser.cc#... src/parsing/parser.cc:3068: position == kNoSourcePosition When does this hold? |