Skip to content
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

TS compiler swallows a syntax error #7602

Closed
wycats opened this issue Mar 20, 2016 · 6 comments
Closed

TS compiler swallows a syntax error #7602

wycats opened this issue Mar 20, 2016 · 6 comments
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead

Comments

@wycats
Copy link

wycats commented Mar 20, 2016

http://www.typescriptlang.org/Playground#src=test(%22foo%22%20function()%20%7B%20%7D)%3B

Input: test("foo" function() { });

Output: test("foo", function() { }); (it "fixed" the missing comma)

Expected: an error of some kind

@vladima
Copy link
Contributor

vladima commented Mar 20, 2016

If I open your Playground link I can see the expected error
image

Command line compiler yields similar results

vladima@vladima-ux31a:~/sources/playground/7602$ cat t.ts
test("foo" function() { });
vladima@vladima-ux31a:~/sources/playground/7602$ ./node_modules/.bin/tsc --version
Version 1.8.9
vladima@vladima-ux31a:~/sources/playground/7602$ ./node_modules/.bin/tsc t.ts
t.ts(1,12): error TS1005: ',' expected.
vladima@vladima-ux31a:~/sources/playground/7602$

@vladima vladima added the Needs More Info The issue still hasn't been fully clarified label Mar 20, 2016
@ghost
Copy link

ghost commented Mar 21, 2016

But if you wait for few seconds on the page, the right hand output window will show the undesired fixed output which @wycats is referring to.

image

It turned out the output window tend to fix errors in many other cases and it never shows fatal errors. So this is probably not a real bug per se, but certainly an undesired outcome..

@vladima
Copy link
Contributor

vladima commented Mar 21, 2016

TS compiler does not guarantee correctness of the emit output if errors were reported. If you don't want to emit anything in presence of errors you can use noEmitOnError compiler option.

@dead-claudia
Copy link

@vladima Syntax errors resulting in a code emit is surprising, though. It's not like you're dealing with type errors, in which the code may still work, or an external API changed, and you're having to migrate types (the types might not check, but the output still works).

@vladima
Copy link
Contributor

vladima commented Mar 22, 2016

AFAIR initially policy regarding syntax errors was exactly as you've described it. However later we've changed it I think based on user requests, pinging @mhegazy if he remembers more details

@mhegazy
Copy link
Contributor

mhegazy commented Mar 22, 2016

that is correct. previously syntax errors blocked emit, where as semantic errors did not. Users have found that confusing. we switched to a model where errors, regardless of their source, would not block emit, and added a flag, --noEmitOnError, to allow to disable this behavior.
The current behavior is by design, and the recommendation is to use --noEmitOnError if generating output is not desired if errors occurred.

@mhegazy mhegazy closed this as completed Mar 22, 2016
@mhegazy mhegazy added the By Design Deprecated - use "Working as Intended" or "Design Limitation" instead label Mar 22, 2016
@RyanCavanaugh RyanCavanaugh removed the Needs More Info The issue still hasn't been fully clarified label Mar 22, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
By Design Deprecated - use "Working as Intended" or "Design Limitation" instead
Projects
None yet
Development

No branches or pull requests

5 participants