-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Switch case fallthrough #393
Comments
👍 |
PR #1091 - Let's discuss here @RyanCavanaugh I thought JSHint is run on auto-generated JS files. Can you explain this |
Ah ! Similar issue is logged at Google Closure Compiler - https://code.google.com/p/closure-compiler/issues/detail?id=1104 |
@dekajp, if the compiler code itself, so for exapmle the two links in my start post had the /* falls through */ comment, then the intent from a developer perspective is clear... When I look at the code now, as somebody who isn't that familiar with the TypeScript compiler code base, I might think that somebody forgot the break or something. Also, I created a linter rule for TypeScript files which was giving me errors about this stuff (I tried it on the TypeScript code base) (lint rule) I agree an warning might be nice but as shown above, one could also used a linter to check the TypeScript files. So it is up to the other guys here if they want the extra code for a warning by the compiler or they might say to just use a linter |
@DickvdBrink if linter is already available to check this , i feel it is not necessary to have this check in compiler. You guys can decide |
What do you need here? |
emit |
I don't think the compiler should try to emit comments on your behalf. It's confusing and would actively work against tools that try to check for those things for you. We should, in the compiler code, add comments (us as humans 😄) to clarify where we have intentional fall-throughs, to avoid confusion. |
in reference to PR #1091 @DanielRosenwasser I am working on this , and i think we should only consider So whole subtree may not be needed . below is one example , i have more such in my test cases case 31:
var i = 0;
for (; i > 10;) {
i++;
break;
// never executes
}
/* fall through */ @RyanCavanaugh here is my working code , i am not sure how i should handle the comment |
This is already enforced by TSLint -- I'd prefer we not add linter-style rules to the compiler. We generally don't add style or convention-based rules, especially when existing tools can handle them fine. See https://github.com/palantir/tslint/blob/master/src/rules/noSwitchCaseFallThroughRule.ts |
Ahh !! I think i did not understand your earlier message very well. I thought in same way , but did not get an affirmation ( check my previous message) . Anyways i see your point you want to add |
#1287 👍 |
I think we can close this now. |
Yeah, think so :) |
There are numerous places where the code just fallsthrough a different case like here:
https://github.com/Microsoft/TypeScript/blob/02d0b024c695f059fb8209e301b30f80fddc3d08/src/compiler/checker.ts#L646 or here https://github.com/Microsoft/TypeScript/blob/02d0b024c695f059fb8209e301b30f80fddc3d08/src/compiler/emitter.ts#L118
There are also multiple places in the binder or parser where this is the case.
In my opinion it might be nice to write a comment there when it is intentional... or isn't it intentional?
Example for comment how for example jshint knows it is intentional:
In the above code both are written to the console.
The text was updated successfully, but these errors were encountered: