New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disabling warning for W100 not working in 2.9.3 #3013
Disabling warning for W100 not working in 2.9.3 #3013
Comments
Thanks for the report! This is indeed a regression. Not that it helps you much, but it looks like the new release has surfaced a previously-existing bug--in the process of reducing the input you shared, I was able to experience this problem in version 2.9.2, as well. I need to step away for a bit, but I hope to have a patch ready this evening (EST). |
Here's the story: Upon encountering an open parenthesis character ( JSHint does this by tokenizing all the input that follows until it finds a While it is looking ahead, it does not apply in-line directives it encounters This regression came about because of a seemingly-unrelated patch: gh-3003. (function() {
;//<-- lookahead ends at this semicolon token
}()); ...however, that was found to be an invalid heuristic because arrow function (x = function() {
;//<-- lookahead should *not* end at this semicolon token
}) => x; So we removed it in order to properly recognize arrow functions in those cases. With that in mind, the fully-reduced test case may be a little more clear (that (function() {
;
/*jshint -W100 */
"";
})(); Prior to gh-3003 (e.g. JSHint at version 2.9.2), the semicolon would stop the This also demonstrates how the fundamental problem exists even in JSHint 2.9.2. (function() {
/*jshint -W100 */
"";
})(); Because here, the parenthesis-triggered lookahead is not interrupted in either The ideal fix would be to apply directives during lookahead. Unfortunately, due I've submitted a fix here: gh-3016. In the long term, I think we ought to consider |
Thanks for the detailed explanation! |
* [[CHORE]] Remove `lex.start` method This method simply proxies `lex.nextLine` to scan a single line of the program. It is currently only used to scan the very first line of input, which is problematic for two reasons: 1. Linting options have not yet been applied via the `assume` function, so linting options that effect the parser's behavior are not honored for this first line (see the unit test corrected in this patch for an example) 2. So-called "checks" for asynchronously-reported warnings on the first line cannot be associated with a token. This makes it impossible to issue warnings asynchronously for the first line. Because the `lex.token` method itself invokes `lex.nextLine`, these problems may be avoided by removing `lex.start` and deferring the invocation of `nextLine` until the first token is requested. * [[FIX]] Allow W100 to be ignored during lookahead Defer the reporting of warning W100 until parse time (using `triggerAsync`) so that it may be disabled via in-line directives even in contexts where a "lookahead" is taking place. * fixup! [[FIX]] Allow W100 to be ignored during lookahead
* [[CHORE]] Remove `lex.start` method This method simply proxies `lex.nextLine` to scan a single line of the program. It is currently only used to scan the very first line of input, which is problematic for two reasons: 1. Linting options have not yet been applied via the `assume` function, so linting options that effect the parser's behavior are not honored for this first line (see the unit test corrected in this patch for an example) 2. So-called "checks" for asynchronously-reported warnings on the first line cannot be associated with a token. This makes it impossible to issue warnings asynchronously for the first line. Because the `lex.token` method itself invokes `lex.nextLine`, these problems may be avoided by removing `lex.start` and deferring the invocation of `nextLine` until the first token is requested. * [[FIX]] Allow W100 to be ignored during lookahead Defer the reporting of warning W100 until parse time (using `triggerAsync`) so that it may be disabled via in-line directives even in contexts where a "lookahead" is taking place. * fixup! [[FIX]] Allow W100 to be ignored during lookahead
The fix for this bug is now available in the newly-published JSHint version 2.9.4: http://jshint.com/blog/2016-10-20/release-2-9-4/ Please let us know if you're still having trouble with that version! |
The bug with -W100 was fixed in 2.9.4. See jshint/jshint#3013 (comment)
See IgniteUI/ignite-ui#243:
First build passed with 2.9.2, consecutive builds with 2.9.3 update fail, with a line wrapped with /*jshint -W100 */
Don't see anything related in the update blog, but has something changed in the way those are handled?
The text was updated successfully, but these errors were encountered: