Skip to content
This repository has been archived by the owner on May 19, 2018. It is now read-only.

Type-check UtilParser #485

Merged
merged 1 commit into from Apr 25, 2017
Merged

Type-check UtilParser #485

merged 1 commit into from Apr 25, 2017

Conversation

ghost
Copy link

@ghost ghost commented Apr 25, 2017

Q A
Bug fix? no
Breaking change? no
New feature? no
Deprecations? no
Spec compliancy? no
Tests added/pass? Tests pass
Fixed tickets
License MIT

Enables type-checking in util.js and annotates every method.

@codecov
Copy link

codecov bot commented Apr 25, 2017

Codecov Report

Merging #485 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff           @@
##           master    #485   +/-   ##
======================================
  Coverage    98.2%   98.2%           
======================================
  Files          21      21           
  Lines        3519    3519           
  Branches      974     974           
======================================
  Hits         3456    3456           
  Misses         24      24           
  Partials       39      39
Flag Coverage Δ
#babel 80.9% <84.61%> (ø) ⬆️
#babylon 97.04% <100%> (ø) ⬆️
Impacted Files Coverage Δ
src/parser/util.js 90% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 68967bf...b6c07e4. Read the comment docs.

@hzoo
Copy link
Member

hzoo commented Apr 25, 2017

Thanks again!

@hzoo hzoo merged commit 7627c5a into babel:master Apr 25, 2017
@ghost ghost deleted the util branch April 25, 2017 22:02
return this.eat(tt.semi) || this.canInsertSemicolon();
}

// Consume a semicolon, or, failing that, see if we are allowed to
// pretend that there is a semicolon at this position.

semicolon() {
semicolon(): void {
Copy link
Member

@xtuc xtuc Apr 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to explicitly write void for the returned type?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without the return type, you should still get errors if there are errors, but they will be more confusing: If you have function f() { return g(); } and call f().toUpperCase(), and there's an error, is it in f, g, or .toUpperCase()?

@xtuc
Copy link
Member

xtuc commented Apr 26, 2017

I was thinking it will infer the void type since It returns nothing, doesn't it?

@ghost
Copy link
Author

ghost commented Apr 26, 2017

Yes, in the case of 100% correct code everything will be inferred with no problem. But there are also some functions in the code that should be void but contain unnecessary return statements -- can't catch that without an annotation.

@xtuc
Copy link
Member

xtuc commented Apr 26, 2017

Ok, thanks

@ghost ghost mentioned this pull request May 19, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants