Summary: | Parser::parseVarDeclarationList gets the wrong JSToken for the last identifier | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Saam Barati <saam> | ||||||
Component: | JavaScriptCore | Assignee: | Saam Barati <saam> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | bfulgham, fpizlo, ggaren, mark.lam, mhahnenb, msaboff, oliver | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Saam Barati
2015-02-04 16:11:15 PST
Created attachment 246069 [details]
patch
will upload with changelog later tonight
Do you have a test case showing this problem so we can avoid hitting it in the future? (In reply to comment #2) > Do you have a test case showing this problem so we can avoid hitting it in > the future? Not directly for asserting the token is at a given location, but the tests I will include when I land: https://bugs.webkit.org/show_bug.cgi?id=141241 will fail if we break the token location. That said, this breakage is dependent on the Type Profiler's internal organization of data using text ranges. This is unlikely to change, but there is no guarantee. Is there a more direct way to assert against the token location of given statement in a JS test? Comment on attachment 246069 [details]
patch
Bug fix looks good. Needs a change log and a test case.
Created attachment 246316 [details]
patch
landed in: http://trac.webkit.org/changeset/179873 |