jashkenas--coffeescript/test/error_messages.coffee

1343 lines
30 KiB
CoffeeScript
Raw Normal View History

2016-07-25 03:37:37 +00:00
# Error Formatting
# ----------------
# Ensure that errors of different kinds (lexer, parser and compiler) are shown
# in a consistent way.
assertErrorFormat = (code, expectedErrorFormat) ->
throws (-> CoffeeScript.run code), (err) ->
err.colorful = no
eq expectedErrorFormat, "#{err}"
yes
2016-07-25 03:37:37 +00:00
test "lexer errors formatting", ->
assertErrorFormat '''
normalObject = {}
insideOutObject = }{
''',
'''
[stdin]:2:19: error: unmatched }
insideOutObject = }{
^
'''
2016-07-25 03:37:37 +00:00
test "parser error formatting", ->
assertErrorFormat '''
foo in bar or in baz
''',
'''
[stdin]:1:15: error: unexpected in
foo in bar or in baz
^^
'''
test "compiler error formatting", ->
assertErrorFormat '''
evil = (foo, eval, bar) ->
''',
'''
[stdin]:1:14: error: 'eval' can't be assigned
evil = (foo, eval, bar) ->
^^^^
'''
2014-01-27 16:55:20 +00:00
if require?
Fix stack trace (#4428) * Revert aee27fbff03870c5479c6c33e6b1f1a32219420c * Patch Jison’s output so that it requires `fs` only if we’re truly in a CommonJS/Node environment, not a browser environment that may happen to have globals named `require` and `exports` (as would be the case if require.js is being used). Fixes #4391. * Temporary fix for exceptions getting thrown when trying to generate a stack trace for a file that has been deleted since compilation; fixes #3890, but not well. A better solution would not try to recompile the file when trying to retrieve its stack trace. * Save the test REPL history in the system temp folder, not in the CoffeeScript project folder * Rewrite `getSourceMap` to never read a file from disk, and therefore not throw IO-related exceptions; source maps are either retrieved from memory, or the related source code is retrieved from memory to generate a new source map. Fixes #3890 the proper way. * Add test to verify that stack traces reference the correct line number. Closes #4418. * Get the parser working in the browser compiler again; rather than detecting a CommonJS environment generally, just check for `fs` before trying to use it * Follow Node’s standard of 4-space indentation of stack trace data * Better .gitignore * Fix caching of compiled code and source maps; add more tests to verify correct line numbers in stack traces * Better fallback value for the parser source * Fix the stack traces and tests when running in a browser * Update the browser compiler so that @murrayju doesn’t have any extra work to do to test this branch
2017-01-22 21:20:18 +00:00
os = require 'os'
2014-01-27 16:55:20 +00:00
fs = require 'fs'
path = require 'path'
Fix stack trace (#4428) * Revert aee27fbff03870c5479c6c33e6b1f1a32219420c * Patch Jison’s output so that it requires `fs` only if we’re truly in a CommonJS/Node environment, not a browser environment that may happen to have globals named `require` and `exports` (as would be the case if require.js is being used). Fixes #4391. * Temporary fix for exceptions getting thrown when trying to generate a stack trace for a file that has been deleted since compilation; fixes #3890, but not well. A better solution would not try to recompile the file when trying to retrieve its stack trace. * Save the test REPL history in the system temp folder, not in the CoffeeScript project folder * Rewrite `getSourceMap` to never read a file from disk, and therefore not throw IO-related exceptions; source maps are either retrieved from memory, or the related source code is retrieved from memory to generate a new source map. Fixes #3890 the proper way. * Add test to verify that stack traces reference the correct line number. Closes #4418. * Get the parser working in the browser compiler again; rather than detecting a CommonJS environment generally, just check for `fs` before trying to use it * Follow Node’s standard of 4-space indentation of stack trace data * Better .gitignore * Fix caching of compiled code and source maps; add more tests to verify correct line numbers in stack traces * Better fallback value for the parser source * Fix the stack traces and tests when running in a browser * Update the browser compiler so that @murrayju doesn’t have any extra work to do to test this branch
2017-01-22 21:20:18 +00:00
test "patchStackTrace line patching", ->
err = new Error 'error'
ok err.stack.match /test[\/\\]error_messages\.coffee:\d+:\d+\b/
test "patchStackTrace stack prelude consistent with V8", ->
err = new Error
ok err.stack.match /^Error\n/ # Notice no colon when no message.
err = new Error 'error'
ok err.stack.match /^Error: error\n/
2014-01-27 16:55:20 +00:00
test "#2849: compilation error in a require()d file", ->
# Create a temporary file to require().
tempFile = path.join os.tmpdir(), 'syntax-error.coffee'
ok not fs.existsSync tempFile
fs.writeFileSync tempFile, 'foo in bar or in baz'
2014-01-27 16:55:20 +00:00
try
assertErrorFormat """
require '#{tempFile}'
""",
2014-01-27 16:55:20 +00:00
"""
#{fs.realpathSync tempFile}:1:15: error: unexpected in
2014-01-27 16:55:20 +00:00
foo in bar or in baz
^^
"""
finally
fs.unlinkSync tempFile
Fix stack trace (#4428) * Revert aee27fbff03870c5479c6c33e6b1f1a32219420c * Patch Jison’s output so that it requires `fs` only if we’re truly in a CommonJS/Node environment, not a browser environment that may happen to have globals named `require` and `exports` (as would be the case if require.js is being used). Fixes #4391. * Temporary fix for exceptions getting thrown when trying to generate a stack trace for a file that has been deleted since compilation; fixes #3890, but not well. A better solution would not try to recompile the file when trying to retrieve its stack trace. * Save the test REPL history in the system temp folder, not in the CoffeeScript project folder * Rewrite `getSourceMap` to never read a file from disk, and therefore not throw IO-related exceptions; source maps are either retrieved from memory, or the related source code is retrieved from memory to generate a new source map. Fixes #3890 the proper way. * Add test to verify that stack traces reference the correct line number. Closes #4418. * Get the parser working in the browser compiler again; rather than detecting a CommonJS environment generally, just check for `fs` before trying to use it * Follow Node’s standard of 4-space indentation of stack trace data * Better .gitignore * Fix caching of compiled code and source maps; add more tests to verify correct line numbers in stack traces * Better fallback value for the parser source * Fix the stack traces and tests when running in a browser * Update the browser compiler so that @murrayju doesn’t have any extra work to do to test this branch
2017-01-22 21:20:18 +00:00
test "#3890 Error.prepareStackTrace doesn't throw an error if a compiled file is deleted", ->
# Adapted from https://github.com/atom/coffee-cash/blob/master/spec/coffee-cash-spec.coffee
filePath = path.join os.tmpdir(), 'PrepareStackTraceTestFile.coffee'
fs.writeFileSync filePath, "module.exports = -> throw new Error('hello world')"
throwsAnError = require filePath
fs.unlinkSync filePath
try
throwsAnError()
catch error
eq error.message, 'hello world'
doesNotThrow(-> error.stack)
notEqual error.stack.toString().indexOf(filePath), -1
test "#4418 stack traces for compiled files reference the correct line number", ->
filePath = path.join os.tmpdir(), 'StackTraceLineNumberTestFile.coffee'
fileContents = """
testCompiledFileStackTraceLineNumber = ->
# `a` on the next line is undefined and should throw a ReferenceError
console.log a if true
do testCompiledFileStackTraceLineNumber
"""
fs.writeFileSync filePath, fileContents
try
require filePath
catch error
fs.unlinkSync filePath
# Make sure the line number reported is line 3 (the original Coffee source)
# and not line 6 (the generated JavaScript).
eq /StackTraceLineNumberTestFile.coffee:(\d)/.exec(error.stack.toString())[1], '3'
test "#4418 stack traces for compiled strings reference the correct line number", ->
try
CoffeeScript.run """
testCompiledStringStackTraceLineNumber = ->
# `a` on the next line is undefined and should throw a ReferenceError
console.log a if true
do testCompiledStringStackTraceLineNumber
"""
catch error
# Make sure the line number reported is line 3 (the original Coffee source)
# and not line 6 (the generated JavaScript).
eq /at testCompiledStringStackTraceLineNumber.*:(\d):/.exec(error.stack.toString())[1], '3'
test "#1096: unexpected generated tokens", ->
# Implicit ends
assertErrorFormat 'a:, b', '''
[stdin]:1:3: error: unexpected ,
a:, b
^
'''
# Explicit ends
assertErrorFormat '(a:)', '''
[stdin]:1:4: error: unexpected )
(a:)
^
'''
# Unexpected end of file
assertErrorFormat 'a:', '''
[stdin]:1:3: error: unexpected end of input
a:
^
'''
assertErrorFormat 'a +', '''
[stdin]:1:4: error: unexpected end of input
a +
^
'''
2015-02-07 19:16:59 +00:00
# Unexpected key in implicit object (an implicit object itself is _not_
# unexpected here)
assertErrorFormat '''
for i in [1]:
1
''', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:10: error: unexpected [
for i in [1]:
2015-02-07 19:16:59 +00:00
^
'''
# Unexpected regex
assertErrorFormat '{/a/i: val}', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:2: error: unexpected regex
{/a/i: val}
^^^^
'''
assertErrorFormat '{///a///i: val}', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:2: error: unexpected regex
{///a///i: val}
^^^^^^^^
'''
assertErrorFormat '{///#{a}///i: val}', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:2: error: unexpected regex
{///#{a}///i: val}
^^^^^^^^^^^
'''
2015-02-07 19:16:59 +00:00
# Unexpected string
Support import and export of ES2015 modules (#4300) This pull request adds support for ES2015 modules, by recognizing `import` and `export` statements. The following syntaxes are supported, based on the MDN [import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) and [export](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) pages: ```js import "module-name" import defaultMember from "module-name" import * as name from "module-name" import { } from "module-name" import { member } from "module-name" import { member as alias } from "module-name" import { member1, member2 as alias2, … } from "module-name" import defaultMember, * as name from "module-name" import defaultMember, { … } from "module-name" export default expression export class name export { } export { name } export { name as exportedName } export { name as default } export { name1, name2 as exportedName2, name3 as default, … } export * from "module-name" export { … } from "module-name" ``` As a subsitute for ECMAScript’s `export var name = …` and `export function name {}`, CoffeeScript also supports: ```js export name = … ``` CoffeeScript also supports optional commas within `{ … }`. This PR converts the supported `import` and `export` statements into ES2015 `import` and `export` statements; it **does not resolve the modules**. So any CoffeeScript with `import` or `export` statements will be output as ES2015, and will need to be transpiled by another tool such as Babel before it can be used in a browser. We will need to add a warning to the documentation explaining this. This should be fully backwards-compatible, as `import` and `export` were previously reserved keywords. No flags are used. There are extensive tests included, though because no current JavaScript runtime supports `import` or `export`, the tests compare strings of what the compiled CoffeeScript output is against what the expected ES2015 should be. I also conducted two more elaborate tests: * I forked the [ember-piqu](https://github.com/pauc/piqu-ember) project, which was an Ember CLI app that used ember-cli-coffeescript and [ember-cli-coffees6](https://github.com/alexspeller/ember-cli-coffees6) (which adds “support” for `import`/`export` by wrapping such statements in backticks before passing the result to the CoffeeScript compiler). I removed `ember-cli-coffees6` and replaced the CoffeeScript compiler used in the build chain with this code, and the app built without errors. [Demo here.](https://github.com/GeoffreyBooth/coffeescript-modules-test-piqu) * I also forked the [CoffeeScript version of Meteor’s Todos example app](https://github.com/meteor/todos/tree/coffeescript), and replaced all of its `require` statements with the `import` and `export` statements from the original ES2015 version of the app on its `master` branch. I then updated the `coffeescript` Meteor package in the app to use this new code, and again the app builds without errors. [Demo here.](https://github.com/GeoffreyBooth/coffeescript-modules-test-meteor-todos) The discussion history for this work started [here](https://github.com/jashkenas/coffeescript/pull/4160) and continued [here](https://github.com/GeoffreyBooth/coffeescript/pull/2). @lydell provided guidance, and @JimPanic and @rattrayalex contributed essential code.
2016-09-14 18:46:05 +00:00
assertErrorFormat 'import foo from "lib-#{version}"', '''
[stdin]:1:17: error: the name of the module to be imported from must be an uninterpolated string
import foo from "lib-#{version}"
^^^^^^^^^^^^^^^^
'''
2015-02-07 19:16:59 +00:00
# Unexpected number
assertErrorFormat '"a"0x00Af2', '''
[stdin]:1:4: error: unexpected number
"a"0x00Af2
^^^^^^^
'''
2014-01-26 05:25:13 +00:00
test "#1316: unexpected end of interpolation", ->
assertErrorFormat '''
"#{+}"
''', '''
[stdin]:1:5: error: unexpected end of interpolation
"#{+}"
^
'''
assertErrorFormat '''
"#{++}"
''', '''
[stdin]:1:6: error: unexpected end of interpolation
"#{++}"
^
'''
assertErrorFormat '''
"#{-}"
''', '''
[stdin]:1:5: error: unexpected end of interpolation
"#{-}"
^
'''
assertErrorFormat '''
"#{--}"
''', '''
[stdin]:1:6: error: unexpected end of interpolation
"#{--}"
^
'''
assertErrorFormat '''
"#{~}"
''', '''
[stdin]:1:5: error: unexpected end of interpolation
"#{~}"
^
'''
assertErrorFormat '''
"#{!}"
''', '''
[stdin]:1:5: error: unexpected end of interpolation
"#{!}"
^
'''
assertErrorFormat '''
"#{not}"
''', '''
[stdin]:1:7: error: unexpected end of interpolation
"#{not}"
^
'''
assertErrorFormat '''
"#{5) + (4}_"
''', '''
[stdin]:1:5: error: unmatched )
"#{5) + (4}_"
^
'''
# #2918
assertErrorFormat '''
"#{foo.}"
''', '''
[stdin]:1:8: error: unexpected end of interpolation
"#{foo.}"
^
'''
2014-01-26 05:25:13 +00:00
test "#3325: implicit indentation errors", ->
assertErrorFormat '''
i for i in a then i
''', '''
[stdin]:1:14: error: unexpected then
i for i in a then i
^^^^
'''
test "explicit indentation errors", ->
assertErrorFormat '''
a = b
c
''', '''
[stdin]:2:1: error: unexpected indentation
c
^^
'''
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
test "unclosed strings", ->
assertErrorFormat '''
'
''', '''
[stdin]:1:1: error: missing '
'
^
'''
assertErrorFormat '''
"
''', '''
[stdin]:1:1: error: missing "
"
^
'''
assertErrorFormat """
'''
""", """
[stdin]:1:1: error: missing '''
'''
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
"""
assertErrorFormat '''
"""
''', '''
[stdin]:1:1: error: missing """
"""
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
"#{"
''', '''
[stdin]:1:4: error: missing "
"#{"
^
'''
assertErrorFormat '''
"""#{"
''', '''
[stdin]:1:6: error: missing "
"""#{"
^
'''
assertErrorFormat '''
"#{"""
''', '''
[stdin]:1:4: error: missing """
"#{"""
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
"""#{"""
''', '''
[stdin]:1:6: error: missing """
"""#{"""
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
///#{"""
''', '''
[stdin]:1:6: error: missing """
///#{"""
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
"a
#{foo """
bar
#{ +'12 }
baz
"""} b"
''', '''
[stdin]:4:11: error: missing '
#{ +'12 }
^
'''
# https://github.com/jashkenas/coffeescript/issues/3301#issuecomment-31735168
assertErrorFormat '''
# Note the double escaping; this would be `"""a\"""` real code.
"""a\\"""
''', '''
[stdin]:2:1: error: missing """
"""a\\"""
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
test "unclosed heregexes", ->
assertErrorFormat '''
///
''', '''
[stdin]:1:1: error: missing ///
///
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
# https://github.com/jashkenas/coffeescript/issues/3301#issuecomment-31735168
assertErrorFormat '''
# Note the double escaping; this would be `///a\///` real code.
///a\\///
''', '''
[stdin]:2:1: error: missing ///
///a\\///
^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
test "unexpected token after string", ->
# Parsing error.
assertErrorFormat '''
'foo'bar
''', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:6: error: unexpected identifier
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'foo'bar
^^^
'''
assertErrorFormat '''
"foo"bar
''', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:6: error: unexpected identifier
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
"foo"bar
^^^
'''
# Lexing error.
assertErrorFormat '''
'foo'bar'
''', '''
[stdin]:1:9: error: missing '
'foo'bar'
^
'''
assertErrorFormat '''
"foo"bar"
''', '''
[stdin]:1:9: error: missing "
"foo"bar"
^
'''
test "#3348: Location data is wrong in interpolations with leading whitespace", ->
assertErrorFormat '''
2015-02-07 19:16:59 +00:00
"#{ * }"
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
''', '''
2015-02-07 19:16:59 +00:00
[stdin]:1:5: error: unexpected *
"#{ * }"
^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
test "octal escapes", ->
assertErrorFormat '''
"a\\0\\tb\\\\\\07c"
''', '''
[stdin]:1:10: error: octal escape sequences are not allowed \\07
"a\\0\\tb\\\\\\07c"
\ \ \ \ ^\^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
"a
#{b} \\1"
''', '''
[stdin]:2:8: error: octal escape sequences are not allowed \\1
#{b} \\1"
^\^
'''
assertErrorFormat '''
/a\\0\\tb\\\\\\07c/
''', '''
[stdin]:1:10: error: octal escape sequences are not allowed \\07
/a\\0\\tb\\\\\\07c/
\ \ \ \ ^\^^
'''
assertErrorFormat '''
///a
#{b} \\01///
''', '''
[stdin]:2:8: error: octal escape sequences are not allowed \\01
#{b} \\01///
^\^^
'''
test "#3795: invalid escapes", ->
assertErrorFormat '''
"a\\0\\tb\\\\\\x7g"
''', '''
[stdin]:1:10: error: invalid escape sequence \\x7g
"a\\0\\tb\\\\\\x7g"
\ \ \ \ ^\^^^
'''
assertErrorFormat '''
"a
#{b} \\uA02
c"
''', '''
[stdin]:2:8: error: invalid escape sequence \\uA02
#{b} \\uA02
^\^^^^
'''
assertErrorFormat '''
/a\\u002space/
''', '''
[stdin]:1:3: error: invalid escape sequence \\u002s
/a\\u002space/
^\^^^^^
'''
assertErrorFormat '''
///a \\u002 0 space///
''', '''
[stdin]:1:6: error: invalid escape sequence \\u002 \n\
///a \\u002 0 space///
^\^^^^^
'''
assertErrorFormat '''
///a
#{b} \\x0
c///
''', '''
[stdin]:2:8: error: invalid escape sequence \\x0
#{b} \\x0
^\^^
'''
assertErrorFormat '''
/ab\\u/
''', '''
[stdin]:1:4: error: invalid escape sequence \\u
/ab\\u/
^\^
'''
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
test "illegal herecomment", ->
assertErrorFormat '''
###
Regex: /a*/g
###
''', '''
[stdin]:2:12: error: block comments cannot contain */
Regex: /a*/g
^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
test "#1724: regular expressions beginning with *", ->
assertErrorFormat '''
/* foo/
''', '''
[stdin]:1:2: error: regular expressions cannot begin with *
/* foo/
^
'''
assertErrorFormat '''
///
* foo
///
''', '''
[stdin]:2:3: error: regular expressions cannot begin with *
* foo
^
'''
test "invalid regex flags", ->
assertErrorFormat '''
/a/ii
''', '''
[stdin]:1:4: error: invalid regular expression flags ii
/a/ii
^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
/a/G
''', '''
[stdin]:1:4: error: invalid regular expression flags G
/a/G
^
'''
assertErrorFormat '''
/a/gimi
''', '''
[stdin]:1:4: error: invalid regular expression flags gimi
/a/gimi
^^^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
/a/g_
''', '''
[stdin]:1:4: error: invalid regular expression flags g_
/a/g_
^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
assertErrorFormat '''
///a///ii
''', '''
[stdin]:1:8: error: invalid regular expression flags ii
///a///ii
^^
Refactor interpolation (and string and regex) handling in lexer - Fix #3394: Unclosed single-quoted strings (both regular ones and heredocs) used to pass through the lexer, causing a parsing error later, while double-quoted strings caused an error already in the lexing phase. Now both single and double-quoted unclosed strings error out in the lexer (which is the more logical option) with consistent error messages. This also fixes the last comment by @satyr in #3301. - Similar to the above, unclosed heregexes also used to pass through the lexer and not error until in the parsing phase, which resulted in confusing error messages. This has been fixed, too. - Fix #3348, by adding passing tests. - Fix #3529: If a string starts with an interpolation, an empty string is no longer emitted before the interpolation (unless it is needed to coerce the interpolation into a string). - Block comments cannot contain `*/`. Now the error message also shows exactly where the offending `*/`. This improvement might seem unrelated, but I had to touch that code anyway to refactor string and regex related code, and the change was very trivial. Moreover, it's consistent with the next two points. - Regexes cannot start with `*`. Now the error message also shows exactly where the offending `*` is. (It might actually not be exatly at the start in heregexes.) It is a very minor improvement, but it was trivial to add. - Octal escapes in strings are forbidden in CoffeeScript (just like in JavaScript strict mode). However, this used to be the case only for regular strings. Now they are also forbidden in heredocs. Moreover, the errors now point at the offending octal escape. - Invalid regex flags are no longer allowed. This includes repeated modifiers and unknown ones. Moreover, invalid modifiers do not stop a heregex from being matched, which results in better error messages. - Fix #3621: `///a#{1}///` compiles to `RegExp("a" + 1)`. So does `RegExp("a#{1}")`. Still, those two code snippets used to generate different tokens, which is a bit weird, but more importantly causes problems for coffeelint (see clutchski/coffeelint#340). This required lots of tests in test/location.coffee to be updated. Note that some updates to those tests are unrelated to this point; some have been updated to be more consistent (I discovered this because the refactored code happened to be seemingly more correct). - Regular regex literals used to erraneously allow newlines to be escaped, causing invalid JavaScript output. This has been fixed. - Heregexes may now be completely empty (`//////`), instead of erroring out with a confusing message. - Fix #2388: Heredocs and heregexes used to be lexed simply, which meant that you couldn't nest a heredoc within a heredoc (double-quoted, that is) or a heregex inside a heregex. - Fix #2321: If you used division inside interpolation and then a slash later in the string containing that interpolation, the division slash and the latter slash was erraneously matched as a regex. This has been fixed. - Indentation inside interpolations in heredocs no longer affect how much indentation is removed from each line of the heredoc (which is more intuitive). - Whitespace is now correctly trimmed from the start and end of strings in a few edge cases. - Last but not least, the lexing of interpolated strings now seems to be more efficient. For a regular double-quoted string, we used to use a custom function to find the end of it (taking interpolations and interpolations within interpolations etc. into account). Then we used to re-find the interpolations and recursively lex their contents. In effect, the same string was processed twice, or even more in the case of deeper nesting of interpolations. Now the same string is processed just once. - Code duplication between regular strings, heredocs, regular regexes and heregexes has been reduced. - The above two points should result in more easily read code, too.
2015-01-03 22:40:43 +00:00
'''
doesNotThrow -> CoffeeScript.compile '/a/ymgi'
test "missing `)`, `}`, `]`", ->
assertErrorFormat '''
(
''', '''
[stdin]:1:1: error: missing )
(
^
'''
assertErrorFormat '''
{
''', '''
[stdin]:1:1: error: missing }
{
^
'''
assertErrorFormat '''
[
''', '''
[stdin]:1:1: error: missing ]
[
^
'''
assertErrorFormat '''
obj = {a: [1, (2+
''', '''
[stdin]:1:15: error: missing )
obj = {a: [1, (2+
^
'''
assertErrorFormat '''
"#{
''', '''
[stdin]:1:3: error: missing }
"#{
^
'''
assertErrorFormat '''
"""
foo#{ bar "#{1}"
''', '''
[stdin]:2:7: error: missing }
foo#{ bar "#{1}"
^
'''
Fix #3410, #3182: Allow regex to start with space or = A regex may not follow a specific set of tokens. These were already known before in the `NOT_REGEX` and `NOT_SPACED_REGEX` arrays. (However, I've refactored them to be more correct and to add a few missing tokens). In all other cases (except after a spaced callable) a slash is the start of a regex, and may now start with a space or an equals sign. It’s really that simple! A slash after a spaced callable is the only ambigous case. We cannot know if that's division or function application with a regex as the argument. The spacing determines which is which: Space on both sides: - `a / b/i` -> `a / b / i` - `a /= b/i` -> `a /= b / i` No spaces: - `a/b/i` -> `a / b / i` - `a/=b/i` -> `a /= b / i` Space on the right side: - `a/ b/i` -> `a / b / i` - `a/= b/i` -> `a /= b / i` Space on the left side: - `a /b/i` -> `a(/b/i)` - `a /=b/i` -> `a(/=b/i)` The last case used to compile to `a /= b / i`, but that has been changed to be consistent with the `/` operator. The last case really looks like a regex, so it should be parsed as one. Moreover, you may now also space the `/` and `/=` operators with other whitespace characters than a space (such as tabs and non-breaking spaces) for consistency. Lastly, unclosed regexes are now reported as such, instead of generating some other confusing error message. It should perhaps also be noted that apart from escaping (such as `a /\ b/`) you may now also use parentheses to disambiguate division and regex: `a (/ b/)`. See https://github.com/jashkenas/coffeescript/issues/3182#issuecomment-26688427.
2015-01-10 00:48:00 +00:00
test "unclosed regexes", ->
assertErrorFormat '''
/
''', '''
[stdin]:1:1: error: missing / (unclosed regex)
/
^
'''
assertErrorFormat '''
# Note the double escaping; this would be `/a\/` real code.
/a\\/
''', '''
[stdin]:2:1: error: missing / (unclosed regex)
/a\\/
^
'''
assertErrorFormat '''
/// ^
a #{""" ""#{if /[/].test "|" then 1 else 0}"" """}
///
''', '''
[stdin]:2:18: error: missing / (unclosed regex)
a #{""" ""#{if /[/].test "|" then 1 else 0}"" """}
^
'''
test "duplicate function arguments", ->
assertErrorFormat '''
(foo, bar, foo) ->
''', '''
2016-09-25 06:23:24 +00:00
[stdin]:1:12: error: multiple parameters named 'foo'
(foo, bar, foo) ->
^^^
'''
assertErrorFormat '''
(@foo, bar, @foo) ->
''', '''
2016-09-25 06:23:24 +00:00
[stdin]:1:13: error: multiple parameters named '@foo'
(@foo, bar, @foo) ->
^^^^
'''
test "reserved words", ->
assertErrorFormat '''
case
''', '''
[stdin]:1:1: error: reserved word 'case'
case
^^^^
'''
assertErrorFormat '''
case = 1
''', '''
[stdin]:1:1: error: reserved word 'case'
case = 1
^^^^
'''
assertErrorFormat '''
for = 1
''', '''
[stdin]:1:1: error: keyword 'for' can't be assigned
for = 1
^^^
'''
assertErrorFormat '''
unless = 1
''', '''
[stdin]:1:1: error: keyword 'unless' can't be assigned
unless = 1
^^^^^^
'''
assertErrorFormat '''
for += 1
''', '''
[stdin]:1:1: error: keyword 'for' can't be assigned
for += 1
^^^
'''
assertErrorFormat '''
for &&= 1
''', '''
[stdin]:1:1: error: keyword 'for' can't be assigned
for &&= 1
^^^
'''
# Make sure token look-behind doesn't go out of range.
assertErrorFormat '''
&&= 1
''', '''
[stdin]:1:1: error: unexpected &&=
&&= 1
^^^
'''
# #2306: Show unaliased name in error messages.
assertErrorFormat '''
on = 1
''', '''
[stdin]:1:1: error: keyword 'on' can't be assigned
on = 1
^^
'''
test "strict mode errors", ->
assertErrorFormat '''
eval = 1
''', '''
[stdin]:1:1: error: 'eval' can't be assigned
eval = 1
^^^^
'''
assertErrorFormat '''
class eval
''', '''
[stdin]:1:7: error: 'eval' can't be assigned
class eval
^^^^
'''
assertErrorFormat '''
arguments++
''', '''
[stdin]:1:1: error: 'arguments' can't be assigned
arguments++
^^^^^^^^^
'''
assertErrorFormat '''
--arguments
''', '''
[stdin]:1:3: error: 'arguments' can't be assigned
--arguments
^^^^^^^^^
'''
test "invalid numbers", ->
assertErrorFormat '''
0X0
''', '''
[stdin]:1:2: error: radix prefix in '0X0' must be lowercase
0X0
^
'''
assertErrorFormat '''
10E0
''', '''
[stdin]:1:3: error: exponential notation in '10E0' must be indicated with a lowercase 'e'
10E0
^
'''
assertErrorFormat '''
018
''', '''
[stdin]:1:1: error: decimal literal '018' must not be prefixed with '0'
018
^^^
'''
assertErrorFormat '''
010
''', '''
[stdin]:1:1: error: octal literal '010' must be prefixed with '0o'
010
^^^
2015-02-07 19:16:59 +00:00
'''
test "unexpected object keys", ->
assertErrorFormat '''
{[[]]}
''', '''
[stdin]:1:2: error: unexpected [
{[[]]}
^
'''
assertErrorFormat '''
{[[]]: 1}
''', '''
[stdin]:1:2: error: unexpected [
{[[]]: 1}
^
'''
assertErrorFormat '''
[[]]: 1
''', '''
[stdin]:1:1: error: unexpected [
[[]]: 1
^
'''
assertErrorFormat '''
{(a + "b")}
''', '''
[stdin]:1:2: error: unexpected (
{(a + "b")}
^
'''
assertErrorFormat '''
{(a + "b"): 1}
''', '''
[stdin]:1:2: error: unexpected (
{(a + "b"): 1}
^
'''
assertErrorFormat '''
(a + "b"): 1
''', '''
[stdin]:1:1: error: unexpected (
(a + "b"): 1
^
'''
assertErrorFormat '''
a: 1, [[]]: 2
''', '''
[stdin]:1:7: error: unexpected [
a: 1, [[]]: 2
^
'''
assertErrorFormat '''
{a: 1, [[]]: 2}
''', '''
[stdin]:1:8: error: unexpected [
{a: 1, [[]]: 2}
^
'''
test "invalid object keys", ->
assertErrorFormat '''
@a: 1
''', '''
[stdin]:1:1: error: invalid object key
@a: 1
^^
'''
assertErrorFormat '''
f
@a: 1
''', '''
[stdin]:2:3: error: invalid object key
@a: 1
^^
'''
assertErrorFormat '''
{a=2}
''', '''
[stdin]:1:3: error: unexpected =
{a=2}
^
'''
test "invalid destructuring default target", ->
assertErrorFormat '''
{'a' = 2} = obj
''', '''
[stdin]:1:6: error: unexpected =
{'a' = 2} = obj
^
'''
test "#4070: lone expansion", ->
assertErrorFormat '''
[...] = a
''', '''
[stdin]:1:2: error: Destructuring assignment has no target
[...] = a
^^^
'''
assertErrorFormat '''
[ ..., ] = a
''', '''
[stdin]:1:3: error: Destructuring assignment has no target
[ ..., ] = a
^^^
'''
test "#3926: implicit object in parameter list", ->
assertErrorFormat '''
(a: b) ->
''', '''
[stdin]:1:3: error: unexpected :
(a: b) ->
^
'''
assertErrorFormat '''
(one, two, {three, four: five}, key: value) ->
''', '''
[stdin]:1:36: error: unexpected :
(one, two, {three, four: five}, key: value) ->
^
'''
test "#4130: unassignable in destructured param", ->
assertErrorFormat '''
fun = ({
@param : null
}) ->
console.log "Oh hello!"
''', '''
[stdin]:2:12: error: keyword 'null' can't be assigned
@param : null
^^^^
'''
assertErrorFormat '''
({a: null}) ->
''', '''
[stdin]:1:6: error: keyword 'null' can't be assigned
({a: null}) ->
^^^^
'''
assertErrorFormat '''
({a: 1}) ->
''', '''
[stdin]:1:6: error: '1' can't be assigned
({a: 1}) ->
^
'''
assertErrorFormat '''
({1}) ->
''', '''
[stdin]:1:3: error: '1' can't be assigned
({1}) ->
^
'''
assertErrorFormat '''
({a: true = 1}) ->
''', '''
[stdin]:1:6: error: keyword 'true' can't be assigned
({a: true = 1}) ->
^^^^
'''
test "`yield` outside of a function", ->
assertErrorFormat '''
yield 1
''', '''
[stdin]:1:1: error: yield can only occur inside functions
yield 1
^^^^^^^
'''
assertErrorFormat '''
yield return
''', '''
[stdin]:1:1: error: yield can only occur inside functions
yield return
^^^^^^^^^^^^
'''
test "#4097: `yield return` as an expression", ->
assertErrorFormat '''
-> (yield return)
''', '''
[stdin]:1:5: error: cannot use a pure statement in an expression
-> (yield return)
^^^^^^^^^^^^
'''
test "`&&=` and `||=` with a space in-between", ->
assertErrorFormat '''
a = 0
a && = 1
''', '''
[stdin]:2:6: error: unexpected =
a && = 1
^
'''
assertErrorFormat '''
a = 0
a and = 1
''', '''
[stdin]:2:7: error: unexpected =
a and = 1
^
'''
assertErrorFormat '''
a = 0
a || = 1
''', '''
[stdin]:2:6: error: unexpected =
a || = 1
^
'''
assertErrorFormat '''
a = 0
a or = 1
''', '''
[stdin]:2:6: error: unexpected =
a or = 1
^
'''
Support import and export of ES2015 modules (#4300) This pull request adds support for ES2015 modules, by recognizing `import` and `export` statements. The following syntaxes are supported, based on the MDN [import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) and [export](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) pages: ```js import "module-name" import defaultMember from "module-name" import * as name from "module-name" import { } from "module-name" import { member } from "module-name" import { member as alias } from "module-name" import { member1, member2 as alias2, … } from "module-name" import defaultMember, * as name from "module-name" import defaultMember, { … } from "module-name" export default expression export class name export { } export { name } export { name as exportedName } export { name as default } export { name1, name2 as exportedName2, name3 as default, … } export * from "module-name" export { … } from "module-name" ``` As a subsitute for ECMAScript’s `export var name = …` and `export function name {}`, CoffeeScript also supports: ```js export name = … ``` CoffeeScript also supports optional commas within `{ … }`. This PR converts the supported `import` and `export` statements into ES2015 `import` and `export` statements; it **does not resolve the modules**. So any CoffeeScript with `import` or `export` statements will be output as ES2015, and will need to be transpiled by another tool such as Babel before it can be used in a browser. We will need to add a warning to the documentation explaining this. This should be fully backwards-compatible, as `import` and `export` were previously reserved keywords. No flags are used. There are extensive tests included, though because no current JavaScript runtime supports `import` or `export`, the tests compare strings of what the compiled CoffeeScript output is against what the expected ES2015 should be. I also conducted two more elaborate tests: * I forked the [ember-piqu](https://github.com/pauc/piqu-ember) project, which was an Ember CLI app that used ember-cli-coffeescript and [ember-cli-coffees6](https://github.com/alexspeller/ember-cli-coffees6) (which adds “support” for `import`/`export` by wrapping such statements in backticks before passing the result to the CoffeeScript compiler). I removed `ember-cli-coffees6` and replaced the CoffeeScript compiler used in the build chain with this code, and the app built without errors. [Demo here.](https://github.com/GeoffreyBooth/coffeescript-modules-test-piqu) * I also forked the [CoffeeScript version of Meteor’s Todos example app](https://github.com/meteor/todos/tree/coffeescript), and replaced all of its `require` statements with the `import` and `export` statements from the original ES2015 version of the app on its `master` branch. I then updated the `coffeescript` Meteor package in the app to use this new code, and again the app builds without errors. [Demo here.](https://github.com/GeoffreyBooth/coffeescript-modules-test-meteor-todos) The discussion history for this work started [here](https://github.com/jashkenas/coffeescript/pull/4160) and continued [here](https://github.com/GeoffreyBooth/coffeescript/pull/2). @lydell provided guidance, and @JimPanic and @rattrayalex contributed essential code.
2016-09-14 18:46:05 +00:00
test "anonymous functions cannot be exported", ->
assertErrorFormat '''
export ->
console.log 'hello, world!'
''', '''
[stdin]:1:8: error: unexpected ->
export ->
^^
'''
test "anonymous classes cannot be exported", ->
assertErrorFormat '''
export class
constructor: ->
console.log 'hello, world!'
''', '''
[stdin]:1:8: error: anonymous classes cannot be exported
export class
^^^^^
Support import and export of ES2015 modules (#4300) This pull request adds support for ES2015 modules, by recognizing `import` and `export` statements. The following syntaxes are supported, based on the MDN [import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) and [export](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) pages: ```js import "module-name" import defaultMember from "module-name" import * as name from "module-name" import { } from "module-name" import { member } from "module-name" import { member as alias } from "module-name" import { member1, member2 as alias2, … } from "module-name" import defaultMember, * as name from "module-name" import defaultMember, { … } from "module-name" export default expression export class name export { } export { name } export { name as exportedName } export { name as default } export { name1, name2 as exportedName2, name3 as default, … } export * from "module-name" export { … } from "module-name" ``` As a subsitute for ECMAScript’s `export var name = …` and `export function name {}`, CoffeeScript also supports: ```js export name = … ``` CoffeeScript also supports optional commas within `{ … }`. This PR converts the supported `import` and `export` statements into ES2015 `import` and `export` statements; it **does not resolve the modules**. So any CoffeeScript with `import` or `export` statements will be output as ES2015, and will need to be transpiled by another tool such as Babel before it can be used in a browser. We will need to add a warning to the documentation explaining this. This should be fully backwards-compatible, as `import` and `export` were previously reserved keywords. No flags are used. There are extensive tests included, though because no current JavaScript runtime supports `import` or `export`, the tests compare strings of what the compiled CoffeeScript output is against what the expected ES2015 should be. I also conducted two more elaborate tests: * I forked the [ember-piqu](https://github.com/pauc/piqu-ember) project, which was an Ember CLI app that used ember-cli-coffeescript and [ember-cli-coffees6](https://github.com/alexspeller/ember-cli-coffees6) (which adds “support” for `import`/`export` by wrapping such statements in backticks before passing the result to the CoffeeScript compiler). I removed `ember-cli-coffees6` and replaced the CoffeeScript compiler used in the build chain with this code, and the app built without errors. [Demo here.](https://github.com/GeoffreyBooth/coffeescript-modules-test-piqu) * I also forked the [CoffeeScript version of Meteor’s Todos example app](https://github.com/meteor/todos/tree/coffeescript), and replaced all of its `require` statements with the `import` and `export` statements from the original ES2015 version of the app on its `master` branch. I then updated the `coffeescript` Meteor package in the app to use this new code, and again the app builds without errors. [Demo here.](https://github.com/GeoffreyBooth/coffeescript-modules-test-meteor-todos) The discussion history for this work started [here](https://github.com/jashkenas/coffeescript/pull/4160) and continued [here](https://github.com/GeoffreyBooth/coffeescript/pull/2). @lydell provided guidance, and @JimPanic and @rattrayalex contributed essential code.
2016-09-14 18:46:05 +00:00
'''
test "unless enclosed by curly braces, only * can be aliased", ->
assertErrorFormat '''
import foo as bar from 'lib'
''', '''
[stdin]:1:12: error: unexpected as
import foo as bar from 'lib'
^^
'''
test "unwrapped imports must follow constrained syntax", ->
assertErrorFormat '''
import foo, bar from 'lib'
''', '''
[stdin]:1:13: error: unexpected identifier
import foo, bar from 'lib'
^^^
'''
assertErrorFormat '''
import foo, bar, baz from 'lib'
''', '''
[stdin]:1:13: error: unexpected identifier
import foo, bar, baz from 'lib'
^^^
'''
assertErrorFormat '''
import foo, bar as baz from 'lib'
''', '''
[stdin]:1:13: error: unexpected identifier
import foo, bar as baz from 'lib'
^^^
'''
test "cannot export * without a module to export from", ->
assertErrorFormat '''
export *
''', '''
[stdin]:1:9: error: unexpected end of input
export *
^
'''
test "imports and exports must be top-level", ->
assertErrorFormat '''
if foo
import { bar } from 'lib'
''', '''
[stdin]:2:3: error: import statements must be at top-level scope
import { bar } from 'lib'
^^^^^^^^^^^^^^^^^^^^^^^^^
'''
assertErrorFormat '''
foo = ->
export { bar }
''', '''
[stdin]:2:3: error: export statements must be at top-level scope
export { bar }
^^^^^^^^^^^^^^
'''
test "cannot import the same member more than once", ->
assertErrorFormat '''
import { foo, foo } from 'lib'
''', '''
[stdin]:1:15: error: 'foo' has already been declared
import { foo, foo } from 'lib'
^^^
'''
assertErrorFormat '''
import { foo, bar, foo } from 'lib'
''', '''
[stdin]:1:20: error: 'foo' has already been declared
import { foo, bar, foo } from 'lib'
^^^
'''
assertErrorFormat '''
import { foo, bar as foo } from 'lib'
''', '''
[stdin]:1:15: error: 'foo' has already been declared
import { foo, bar as foo } from 'lib'
^^^^^^^^^^
'''
assertErrorFormat '''
import foo, { foo } from 'lib'
''', '''
[stdin]:1:15: error: 'foo' has already been declared
import foo, { foo } from 'lib'
^^^
'''
assertErrorFormat '''
import foo, { bar as foo } from 'lib'
''', '''
[stdin]:1:15: error: 'foo' has already been declared
import foo, { bar as foo } from 'lib'
^^^^^^^^^^
'''
assertErrorFormat '''
import foo from 'libA'
import foo from 'libB'
''', '''
[stdin]:2:8: error: 'foo' has already been declared
import foo from 'libB'
^^^
'''
assertErrorFormat '''
import * as foo from 'libA'
import { foo } from 'libB'
''', '''
[stdin]:2:10: error: 'foo' has already been declared
import { foo } from 'libB'
^^^
'''
test "imported members cannot be reassigned", ->
assertErrorFormat '''
import { foo } from 'lib'
foo = 'bar'
''', '''
[stdin]:2:1: error: 'foo' is read-only
foo = 'bar'
^^^
'''
assertErrorFormat '''
import { foo } from 'lib'
export default foo = 'bar'
''', '''
[stdin]:2:16: error: 'foo' is read-only
export default foo = 'bar'
^^^
'''
assertErrorFormat '''
import { foo } from 'lib'
export foo = 'bar'
''', '''
[stdin]:2:8: error: 'foo' is read-only
export foo = 'bar'
^^^
'''
[CS2] Output ES2015 arrow functions, default parameters, rest parameters (#4311) * Eliminate wrapper around “bound” (arrow) functions; output `=>` for such functions * Remove irrelevant (and breaking) tests * Minor cleanup * When a function parameter is a splat (i.e., it uses the ES2015 rest parameter syntax) output that parameter as ES2015 * Rearrange function parameters when one of the parameters is a splat and isn’t the last parameter (very WIP) * Handle params like `@param`, adding assignment expressions for them when they appear; ensure splat parameter is last * Add parameter names (not a text like `'\nValue IdentifierLiteral: a'`) to the scope, so that parameters can’t be deleted; move body-related lines together; more explanation of what’s going on * For parameters with a default value, correctly add the parameter name to the function scope * Handle expansions in function parameters: when an expansion is found, set the parameters to only be the original parameters left of the expansion, then an `...args` parameter; and in the function body define variables for the parameters to the right of the expansion, including setting default values * Handle splat parameters the same way we handle expansions: if a splat parameter is found, it becomes the last parameter in the function definition, and all following parameters get declared in the function body. Fix the splat/rest parameter values after the post-splat parameters have been extracted from it. Clean up `Code.compileNode` so that we loop through the parameters only once, and we create all expressions using calls like `new IdentifierLiteral` rather than `@makeCode`. * Fix parameter name when a parameter is a splat attached to `this` (e.g. `@param...`) * Rather than assigning post-splat parameters based on index, use slice; passes test “Functions with splats being called with too few arguments” * Dial back our w00t indentation * Better parsing of parameter names (WIP) * Refactor processing of splat/expansion parameters * Fix assignment of default parameters for parameters that come after a splat * Better check for whether a param is attached to `this` * More understandable variable names * For parameters after a splat or expansion, assign them similar to the 1.x destructuring method of using `arguments`, except only concern ourselves with the post-splat parameters instead of all parameters; and use the splat/expansion parameter name, since `arguments` in ES fat arrow functions refers to the parent function’s `arguments` rather than the fat arrow function’s arguments/parameters * Don’t add unnamed parameters (like `[]` as a parameter) to the function scope * Disallow multiple splat/expansion parameters in function definitions; disallow lone expansion parameters * Fix `this` params not getting assigned if the parameter is after a splat parameter * Allow names of function parameters attached to `this` to be reserved words * Always add a statement to the function body defining a variable with its default value, if it has one, if the variable `== null`; this covers the case when ES doesn’t apply the default value when `null` is passed in as a value, but CoffeeScript expects `null` and `undefined` to act interchangeably * Aftermath of having both `undefined` and `null` trigger the use of default values for parameters with default values * More careful parsing of destructured parameters * Fall back to processing destructured parameters in the function body, to account for `this` or default values within destructured objects * Clean up comments * Restore new bare function test, minus the arrow function part of it * Test that bound/arrow functions aren’t overwriting the `arguments` object, which should refer to the parent scope’s `arguments` (like `this`) * Follow ES2015 spec for parameter default values: `null` gets assigned as as `null`, not the default value * Mimic ES default parameters behavior for parameters after a splat or expansion parameter * Bound functions cannot be generators: remove no-longer-relevant test, add check to throw error if `yield` appears inside a bound (arrow) function * Error for bound generator functions should underline the `yield`
2016-10-26 05:26:13 +00:00
test "bound functions cannot be generators", ->
assertErrorFormat 'f = => yield this', '''
[stdin]:1:8: error: yield cannot occur inside bound (fat arrow) functions
f = => yield this
^^^^^^^^^^
'''
test "CoffeeScript keywords cannot be used as unaliased names in import lists", ->
assertErrorFormat """
import { unless, baz as bar } from 'lib'
bar.barMethod()
""", '''
[stdin]:1:10: error: unexpected unless
import { unless, baz as bar } from 'lib'
^^^^^^
'''
test "CoffeeScript keywords cannot be used as local names in import list aliases", ->
assertErrorFormat """
import { bar as unless, baz as bar } from 'lib'
bar.barMethod()
""", '''
[stdin]:1:17: error: unexpected unless
import { bar as unless, baz as bar } from 'lib'
^^^^^^
'''
test "function cannot contain both `await` and `yield`", ->
assertErrorFormat '''
f = () ->
yield 5
await a
''', '''
[stdin]:3:3: error: function can't contain both yield and await
await a
^^^^^^^
'''
test "function cannot contain both `await` and `yield from`", ->
assertErrorFormat '''
f = () ->
yield from a
await b
''', '''
[stdin]:3:3: error: function can't contain both yield and await
await b
^^^^^^^
'''
test "cannot have `await` outside a function", ->
assertErrorFormat '''
await 1
''', '''
[stdin]:1:1: error: await can only occur inside functions
await 1
^^^^^^^
'''
test "indexes are not supported in for-from loops", ->
assertErrorFormat "x for x, i from [1, 2, 3]", '''
[stdin]:1:10: error: cannot use index with for-from
x for x, i from [1, 2, 3]
^
'''
test "own is not supported in for-from loops", ->
assertErrorFormat "x for own x from [1, 2, 3]", '''
[stdin]:1:7: error: cannot use own with for-from
x for own x from [1, 2, 3]
^^^
'''
CS1 tagged template literals (and CS2 interpolated strings as template literals) (#4352) * Add initial support for template literals with no interpolation * Change ‘unexpected string’ error message tests to use number not identifier prefix. Identifer prefixes are now valid as tagged template literals * Test tagged template literals for non-interpolated strings and tag function. * Tagged template literals work for pure Strings. Pull tagged template definition up to Invocation level in grammar, enabling chained invocation calls. We can view a tagged template is a special form of function call. * Readying for StringWithInterpolations work. * Tweaks. * Fix style * Pass StringWithInterpolations parameter straight into Call constructor. StringWithInterpolations will be output as template literal, so already in correct form for outputting tagged template literal. * Strip down compileNode for StringWithInterpolations * Done StringLiteral case for interpolated Strings * Remove need for TemplateLiteral * Simplify code. * Small code tidy * Interpolated strings now outputting as template literals. Still needs comprehensive testing. * Move error message tests into error_messages.coffee; remove test that is testing for a Node runtime error * Split up tests that were testing multiple things per test, so that each test tests only one thing * Edge cases: tagged template literals containing interpolated strings or even internal tagged template literals * Make more concise, more idiomatic style * Pull back extreme indentation * Restore and fix commented-out tests * Edge case: tagged template literal with empty string * Only use new ES2015 interpolated string syntax if we’re inside a tagged template literal; this keeps this PR safe to merge into CoffeeScript 1.x. Remove the code from this commit to make all interpolated strings use ES2015 syntax, for CoffeeScript 2. * Compiler now _doesn’t_ use template literals. * Expand tagged template literal tests * Move ‘Unexpected string’ error message tests into tagged template literal section. ‘Unexpected string’ is not reported in these test scenarios anymore. Instead, we error that the prefixing literal is not a function. * Don’t unwrap StringWithInterpolations. Saw bug with program consisting of “#{2}” not compiling with template literals. Root cause was that Block.compileNode was unwrapping interpolated string and so didn’t use compileNode logic at StringWithInterpolations level. * No need to bracket interpolated strings any more. When interpolated string looks like `hello ${2}`, no extract brackets are needed, as the `s mark the beginning and end. * Show html templating with tagged template literals * Multiline should match multiline * Comment out unnecessary `unwrap`, which is only needed for CoffeeScript 2 all-ES2015 syntax output
2016-11-18 18:25:03 +00:00
test "tagged template literals must be called by an identifier", ->
assertErrorFormat "1''", '''
[stdin]:1:1: error: literal is not a function
1''
^
'''
assertErrorFormat '1""', '''
[stdin]:1:1: error: literal is not a function
1""
^
'''
assertErrorFormat "1'b'", '''
[stdin]:1:1: error: literal is not a function
1'b'
^
'''
assertErrorFormat '1"b"', '''
[stdin]:1:1: error: literal is not a function
1"b"
^
'''
assertErrorFormat "1'''b'''", """
[stdin]:1:1: error: literal is not a function
1'''b'''
^
"""
assertErrorFormat '1"""b"""', '''
[stdin]:1:1: error: literal is not a function
1"""b"""
^
'''
assertErrorFormat '1"#{b}"', '''
[stdin]:1:1: error: literal is not a function
1"#{b}"
^
'''
assertErrorFormat '1"""#{b}"""', '''
[stdin]:1:1: error: literal is not a function
1"""#{b}"""
^
'''
[CS2] Compile class constructors to ES2015 classes (#4354) * Compile classes to ES2015 classes Rather than compiling classes to named functions with prototype and class assignments, they are now compiled to ES2015 class declarations. Backwards compatibility has been maintained by compiling ES2015- incompatible properties as prototype or class assignments. `super` continues to be compiled as before. Where possible, classes will be compiled "bare", without an enclosing IIFE. This is possible when the class contains only ES2015 compatible expressions (methods and static methods), and has no parent (this last constraint is a result of the legacy `super` compilation, and could be removed once ES2015 `super` is being used). Classes are still assigned to variables to maintain compatibility for assigned class expressions. There are a few changes to existing functionality that could break backwards compatibility: - Derived constructors that deliberately don't call `super` are no longer possible. ES2015 derived classes can't use `this` unless the parent constructor has been called, so it's now called implicitly when not present. - As a consequence of the above, derived constructors with @ parameters or bound methods and explicit `super` calls are not allowed. The implicit `super` must be used in these cases. * Add tests to verify class interoperability with ES * Refactor class nodes to separate executable body logic Logic has been redistributed amongst the class nodes so that: - `Class` contains the logic necessary to compile an ES class declaration. - `ExecutableClassBody` contains the logic necessary to compile CS' class extensions that require an executable class body. `Class` still necessarily contains logic to determine whether an expression is valid in an ES class initializer or not. If any invalid expressions are found then `Class` will wrap itself in an `ExecutableClassBody` when compiling. * Rename `Code#static` to `Code#isStatic` This naming is more consistent with other `Code` flags. * Output anonymous classes when possible Anonymous classes can be output when: - The class has no parent. The current super compilation needs a class variable to reference. This condition will go away when ES2015 super is in use. - The class contains no bound static methods. Bound static methods have their context set to the class name. * Throw errors at compile time for async or generator constructors * Improve handling of anonymous classes Anonymous classes are now always anonymous. If a name is required (e.g. for bound static methods or derived classes) then the class is compiled in an `ExecutableClassBody` which will give the anonymous class a stable reference. * Add a `replaceInContext` method to `Node` `replaceInContext` will traverse children looking for a node for which `match` returns true. Once found, the matching node will be replaced by the result of calling `replacement`. * Separate `this` assignments from function parameters This change has been made to simplify two future changes: 1. Outputting `@`-param assignments after a `super` call. In this case it is necessary that non-`@` parameters are available before `super` is called, so destructuring has to happen before `this` assignment. 2. Compiling destructured assignment to ES6 In this case also destructuring has to happen before `this`, as destructuring can happen in the arguments list, but `this` assignment can not. A bonus side-effect is that default values for `@` params are now output as ES6 default parameters, e.g. (@a = 1) -> becomes function a (a = 1) { this.a = a; } * Change `super` handling in class constructors Inside an ES derived constructor (a constructor for a class that extends another class), it is impossible to access `this` until `super` has been called. This conflicts with CoffeeScript's `@`-param and bound method features, which compile to `this` references at the top of a function body. For example: class B extends A constructor: (@param) -> super method: => This would compile to something like: class B extends A { constructor (param) { this.param = param; this.method = bind(this.method, this); super(...arguments); } } This would break in an ES-compliant runtime as there are `this` references before the call to `super`. Before this commit we were dealing with this by injecting an implicit `super` call into derived constructors that do not already have an explicit `super` call. Furthermore, we would disallow explicit `super` calls in derived constructors that used bound methods or `@`-params, meaning the above example would need to be rewritten as: class B extends A constructor: (@param) -> method: => This would result in a call to `super(...arguments)` being generated as the first expression in `B#constructor`. Whilst this approach seems to work pretty well, and is arguably more convenient than having to manually call `super` when you don't particularly care about the arguments, it does introduce some 'magic' and separation from ES, and would likely be a pain point in a project that made use of significant constructor overriding. This commit introduces a mechanism through which `super` in constructors is 'expanded' to include any generated `this` assignments, whilst retaining the same semantics of a super call. The first example above now compiles to something like: class B extends A { constructor (param) { var ref ref = super(...arguments), this.param = param, this.method = bind(this.method, this), ref; } } * Improve `super` handling in constructors Rather than functions expanding their `super` calls, the `SuperCall` node can now be given a list of `thisAssignments` to apply when it is compiled. This allows us to use the normal compiler machinery to determine whether the `super` result needs to be cached, whether it appears inline or not, etc. * Fix anonymous classes at the top level Anonymous classes in ES are only valid within expressions. If an anonymous class is at the top level it will now be wrapped in parenthses to force it into an expression. * Re-add Parens wrapper around executable class bodies This was lost in the refactoring, but it necessary to ensure `new class ...` works as expected when there's an executable body. * Throw compiler errors for badly configured derived constructors Rather than letting them become runtime errors, the following checks are now performed when compiling a derived constructor: - The constructor **must** include a call to `super`. - The constructor **must not** reference `this` in the function body before `super` has been called. * Add some tests exercising new class behaviour - async methods in classes - `this` access after `super` in extended classes - constructor super in arrow functions - constructor functions can't be async - constructor functions can't be generators - derived constructors must call super - derived constructors can't reference `this` before calling super - generator methods in classes - 'new' target * Improve constructor `super` errors Add a check for `super` in non-extended class constructors, and explicitly mention derived constructors in the "can't reference this before super" error. * Fix compilation of multiple `super` paths in derived constructors `super` can only be called once, but it can be called conditionally from multiple locations. The chosen fix is to add the `this` assignments to every super call. * Additional class tests, added as a separate file to simplify testing and merging. Some methods are commented out because they currently throw and I'm not sure how to test for compilation errors like those. There is also one test which I deliberately left without passing, `super` in an external prototype override. This test should 'pass' but is really a variation on the failing `super only allowed in an instance method` tests above it. * Changes to the tests. Found bug in super in prototype method. fixed. * Added failing test back in, dealing with bound functions in external prototype overrides. * Located a bug in the compiler relating to assertions and escaped ES6 classes. * Move tests from classes-additional.coffee into classes.coffee; comment out console.log * Cleaned up tests and made changes based on feedback. Test at the end still has issues, but it's commented out for now. * Make HoistTarget.expand recursive It's possible that a hoisted node may itself contain hoisted nodes (e.g. a class method inside a class method). For this to work the hoisted fragments need to be expanded recursively. * Uncomment final test in classes.coffee The test case now compiles, however another issue is affecting the test due to the error for `this` before `super` triggering based on source order rather than execution order. These have been commented out for now. * Fixed last test TODOs in test/classes.coffee Turns out an expression like `this.foo = super()` won't run in JS as it attempts to lookup `this` before evaluating `super` (i.e. throws "this is not defined"). * Added more tests for compatability checks, statics, prototypes and ES6 expectations. Cleaned test "nested classes with super". * Changes to reflect feedback and to comment out issues that will be addressed seperately. * Clean up test/classes.coffee - Trim trailing whitespace. - Rephrase a condition to be more idiomatic. * Remove check for `super` in derived constructors In order to be usable at runtime, an extended ES class must call `super` OR return an alternative object. This check prevented the latter case, and checking for an alternative return can't be completed statically without control flow analysis. * Disallow 'super' in constructor parameter defaults There are many edge cases when combining 'super' in parameter defaults with @-parameters and bound functions (and potentially property initializers in the future). Rather than attempting to resolve these edge cases, 'super' is now explicitly disallowed in constructor parameter defaults. * Disallow @-params in derived constructors without 'super' @-parameters can't be assigned unless 'super' is called.
2017-01-13 05:55:30 +00:00
test "constructor functions can't be async", ->
assertErrorFormat 'class then constructor: -> await x', '''
[stdin]:1:12: error: Class constructor may not be async
class then constructor: -> await x
^^^^^^^^^^^
'''
test "constructor functions can't be generators", ->
assertErrorFormat 'class then constructor: -> yield', '''
[stdin]:1:12: error: Class constructor may not be a generator
class then constructor: -> yield
^^^^^^^^^^^
'''
test "non-derived constructors can't call super", ->
[CS2] Compile all super calls to ES2015 super (#4424) * Compile all super calls to ES2015 super This breaks using `super` in non-methods, meaning several tests are failing. Self-compilation still works. * Use bound functions for IIFEs containing `super` `super` can only be called directly in a method, or in an arrow function. * Fix handling of `class @A extends A` This behaviour worked 'for free' when the parent reference was being cached by the executable class body wrapper. There now needs to be special handling in place to check if the parent name matches the class name, and if so to cache the parent reference. * Fix tests broken by compiling ES2015 `super` * Disallow bare super This removes syntax support for 'bare' super calls, e.g.: class B extends A constructor: -> super `super` must now always be followed with arguments like a regular function call. This also removes the capability of implicitly forwarding arguments. The above can be equivalently be written as: class B extends A constructor: -> super arguments... * Support super with accessors `super` with following accessor(s) is now compiled to ES2015 equivalents. In particular, expressions such as `super.name`, `super[name]`, and also `super.name.prop` are all now valid, and can be used as expected as calls (i.e. `super.name()`) or in expressions (i.e. `if super.name? ...`). `super` without accessors is compiled to a constructor super call in a constructor, and otherwise, as before, to a super call to the method of the same name, i.e. speak: -> super() ...is equivalent to speak: -> super.speak() A neat side-effect of the changes is that existential calls now work properly with super, meaning `super?()` will only call if the super property exists (and is a function). This is not valid for super in constructors. * Prevent calling `super` methods with `new` This fixes a bug in the previous super handling whereby using the `new` operator with a `super` call would silently drop the `new`. This is now an explicit compiler error, as it is invalid JS at runtime. * Clean up some old super handling code This was mostly code for tracking the source classes and variables for methods, which were needed to build the old lookups on `__super__`. * Add TODO to improve bare super parse error * Add some TODOs to improve some of the class tests
2017-02-04 20:03:17 +00:00
assertErrorFormat 'class then constructor: -> super()', '''
[CS2] Compile class constructors to ES2015 classes (#4354) * Compile classes to ES2015 classes Rather than compiling classes to named functions with prototype and class assignments, they are now compiled to ES2015 class declarations. Backwards compatibility has been maintained by compiling ES2015- incompatible properties as prototype or class assignments. `super` continues to be compiled as before. Where possible, classes will be compiled "bare", without an enclosing IIFE. This is possible when the class contains only ES2015 compatible expressions (methods and static methods), and has no parent (this last constraint is a result of the legacy `super` compilation, and could be removed once ES2015 `super` is being used). Classes are still assigned to variables to maintain compatibility for assigned class expressions. There are a few changes to existing functionality that could break backwards compatibility: - Derived constructors that deliberately don't call `super` are no longer possible. ES2015 derived classes can't use `this` unless the parent constructor has been called, so it's now called implicitly when not present. - As a consequence of the above, derived constructors with @ parameters or bound methods and explicit `super` calls are not allowed. The implicit `super` must be used in these cases. * Add tests to verify class interoperability with ES * Refactor class nodes to separate executable body logic Logic has been redistributed amongst the class nodes so that: - `Class` contains the logic necessary to compile an ES class declaration. - `ExecutableClassBody` contains the logic necessary to compile CS' class extensions that require an executable class body. `Class` still necessarily contains logic to determine whether an expression is valid in an ES class initializer or not. If any invalid expressions are found then `Class` will wrap itself in an `ExecutableClassBody` when compiling. * Rename `Code#static` to `Code#isStatic` This naming is more consistent with other `Code` flags. * Output anonymous classes when possible Anonymous classes can be output when: - The class has no parent. The current super compilation needs a class variable to reference. This condition will go away when ES2015 super is in use. - The class contains no bound static methods. Bound static methods have their context set to the class name. * Throw errors at compile time for async or generator constructors * Improve handling of anonymous classes Anonymous classes are now always anonymous. If a name is required (e.g. for bound static methods or derived classes) then the class is compiled in an `ExecutableClassBody` which will give the anonymous class a stable reference. * Add a `replaceInContext` method to `Node` `replaceInContext` will traverse children looking for a node for which `match` returns true. Once found, the matching node will be replaced by the result of calling `replacement`. * Separate `this` assignments from function parameters This change has been made to simplify two future changes: 1. Outputting `@`-param assignments after a `super` call. In this case it is necessary that non-`@` parameters are available before `super` is called, so destructuring has to happen before `this` assignment. 2. Compiling destructured assignment to ES6 In this case also destructuring has to happen before `this`, as destructuring can happen in the arguments list, but `this` assignment can not. A bonus side-effect is that default values for `@` params are now output as ES6 default parameters, e.g. (@a = 1) -> becomes function a (a = 1) { this.a = a; } * Change `super` handling in class constructors Inside an ES derived constructor (a constructor for a class that extends another class), it is impossible to access `this` until `super` has been called. This conflicts with CoffeeScript's `@`-param and bound method features, which compile to `this` references at the top of a function body. For example: class B extends A constructor: (@param) -> super method: => This would compile to something like: class B extends A { constructor (param) { this.param = param; this.method = bind(this.method, this); super(...arguments); } } This would break in an ES-compliant runtime as there are `this` references before the call to `super`. Before this commit we were dealing with this by injecting an implicit `super` call into derived constructors that do not already have an explicit `super` call. Furthermore, we would disallow explicit `super` calls in derived constructors that used bound methods or `@`-params, meaning the above example would need to be rewritten as: class B extends A constructor: (@param) -> method: => This would result in a call to `super(...arguments)` being generated as the first expression in `B#constructor`. Whilst this approach seems to work pretty well, and is arguably more convenient than having to manually call `super` when you don't particularly care about the arguments, it does introduce some 'magic' and separation from ES, and would likely be a pain point in a project that made use of significant constructor overriding. This commit introduces a mechanism through which `super` in constructors is 'expanded' to include any generated `this` assignments, whilst retaining the same semantics of a super call. The first example above now compiles to something like: class B extends A { constructor (param) { var ref ref = super(...arguments), this.param = param, this.method = bind(this.method, this), ref; } } * Improve `super` handling in constructors Rather than functions expanding their `super` calls, the `SuperCall` node can now be given a list of `thisAssignments` to apply when it is compiled. This allows us to use the normal compiler machinery to determine whether the `super` result needs to be cached, whether it appears inline or not, etc. * Fix anonymous classes at the top level Anonymous classes in ES are only valid within expressions. If an anonymous class is at the top level it will now be wrapped in parenthses to force it into an expression. * Re-add Parens wrapper around executable class bodies This was lost in the refactoring, but it necessary to ensure `new class ...` works as expected when there's an executable body. * Throw compiler errors for badly configured derived constructors Rather than letting them become runtime errors, the following checks are now performed when compiling a derived constructor: - The constructor **must** include a call to `super`. - The constructor **must not** reference `this` in the function body before `super` has been called. * Add some tests exercising new class behaviour - async methods in classes - `this` access after `super` in extended classes - constructor super in arrow functions - constructor functions can't be async - constructor functions can't be generators - derived constructors must call super - derived constructors can't reference `this` before calling super - generator methods in classes - 'new' target * Improve constructor `super` errors Add a check for `super` in non-extended class constructors, and explicitly mention derived constructors in the "can't reference this before super" error. * Fix compilation of multiple `super` paths in derived constructors `super` can only be called once, but it can be called conditionally from multiple locations. The chosen fix is to add the `this` assignments to every super call. * Additional class tests, added as a separate file to simplify testing and merging. Some methods are commented out because they currently throw and I'm not sure how to test for compilation errors like those. There is also one test which I deliberately left without passing, `super` in an external prototype override. This test should 'pass' but is really a variation on the failing `super only allowed in an instance method` tests above it. * Changes to the tests. Found bug in super in prototype method. fixed. * Added failing test back in, dealing with bound functions in external prototype overrides. * Located a bug in the compiler relating to assertions and escaped ES6 classes. * Move tests from classes-additional.coffee into classes.coffee; comment out console.log * Cleaned up tests and made changes based on feedback. Test at the end still has issues, but it's commented out for now. * Make HoistTarget.expand recursive It's possible that a hoisted node may itself contain hoisted nodes (e.g. a class method inside a class method). For this to work the hoisted fragments need to be expanded recursively. * Uncomment final test in classes.coffee The test case now compiles, however another issue is affecting the test due to the error for `this` before `super` triggering based on source order rather than execution order. These have been commented out for now. * Fixed last test TODOs in test/classes.coffee Turns out an expression like `this.foo = super()` won't run in JS as it attempts to lookup `this` before evaluating `super` (i.e. throws "this is not defined"). * Added more tests for compatability checks, statics, prototypes and ES6 expectations. Cleaned test "nested classes with super". * Changes to reflect feedback and to comment out issues that will be addressed seperately. * Clean up test/classes.coffee - Trim trailing whitespace. - Rephrase a condition to be more idiomatic. * Remove check for `super` in derived constructors In order to be usable at runtime, an extended ES class must call `super` OR return an alternative object. This check prevented the latter case, and checking for an alternative return can't be completed statically without control flow analysis. * Disallow 'super' in constructor parameter defaults There are many edge cases when combining 'super' in parameter defaults with @-parameters and bound functions (and potentially property initializers in the future). Rather than attempting to resolve these edge cases, 'super' is now explicitly disallowed in constructor parameter defaults. * Disallow @-params in derived constructors without 'super' @-parameters can't be assigned unless 'super' is called.
2017-01-13 05:55:30 +00:00
[stdin]:1:28: error: 'super' is only allowed in derived class constructors
[CS2] Compile all super calls to ES2015 super (#4424) * Compile all super calls to ES2015 super This breaks using `super` in non-methods, meaning several tests are failing. Self-compilation still works. * Use bound functions for IIFEs containing `super` `super` can only be called directly in a method, or in an arrow function. * Fix handling of `class @A extends A` This behaviour worked 'for free' when the parent reference was being cached by the executable class body wrapper. There now needs to be special handling in place to check if the parent name matches the class name, and if so to cache the parent reference. * Fix tests broken by compiling ES2015 `super` * Disallow bare super This removes syntax support for 'bare' super calls, e.g.: class B extends A constructor: -> super `super` must now always be followed with arguments like a regular function call. This also removes the capability of implicitly forwarding arguments. The above can be equivalently be written as: class B extends A constructor: -> super arguments... * Support super with accessors `super` with following accessor(s) is now compiled to ES2015 equivalents. In particular, expressions such as `super.name`, `super[name]`, and also `super.name.prop` are all now valid, and can be used as expected as calls (i.e. `super.name()`) or in expressions (i.e. `if super.name? ...`). `super` without accessors is compiled to a constructor super call in a constructor, and otherwise, as before, to a super call to the method of the same name, i.e. speak: -> super() ...is equivalent to speak: -> super.speak() A neat side-effect of the changes is that existential calls now work properly with super, meaning `super?()` will only call if the super property exists (and is a function). This is not valid for super in constructors. * Prevent calling `super` methods with `new` This fixes a bug in the previous super handling whereby using the `new` operator with a `super` call would silently drop the `new`. This is now an explicit compiler error, as it is invalid JS at runtime. * Clean up some old super handling code This was mostly code for tracking the source classes and variables for methods, which were needed to build the old lookups on `__super__`. * Add TODO to improve bare super parse error * Add some TODOs to improve some of the class tests
2017-02-04 20:03:17 +00:00
class then constructor: -> super()
^^^^^^^
[CS2] Compile class constructors to ES2015 classes (#4354) * Compile classes to ES2015 classes Rather than compiling classes to named functions with prototype and class assignments, they are now compiled to ES2015 class declarations. Backwards compatibility has been maintained by compiling ES2015- incompatible properties as prototype or class assignments. `super` continues to be compiled as before. Where possible, classes will be compiled "bare", without an enclosing IIFE. This is possible when the class contains only ES2015 compatible expressions (methods and static methods), and has no parent (this last constraint is a result of the legacy `super` compilation, and could be removed once ES2015 `super` is being used). Classes are still assigned to variables to maintain compatibility for assigned class expressions. There are a few changes to existing functionality that could break backwards compatibility: - Derived constructors that deliberately don't call `super` are no longer possible. ES2015 derived classes can't use `this` unless the parent constructor has been called, so it's now called implicitly when not present. - As a consequence of the above, derived constructors with @ parameters or bound methods and explicit `super` calls are not allowed. The implicit `super` must be used in these cases. * Add tests to verify class interoperability with ES * Refactor class nodes to separate executable body logic Logic has been redistributed amongst the class nodes so that: - `Class` contains the logic necessary to compile an ES class declaration. - `ExecutableClassBody` contains the logic necessary to compile CS' class extensions that require an executable class body. `Class` still necessarily contains logic to determine whether an expression is valid in an ES class initializer or not. If any invalid expressions are found then `Class` will wrap itself in an `ExecutableClassBody` when compiling. * Rename `Code#static` to `Code#isStatic` This naming is more consistent with other `Code` flags. * Output anonymous classes when possible Anonymous classes can be output when: - The class has no parent. The current super compilation needs a class variable to reference. This condition will go away when ES2015 super is in use. - The class contains no bound static methods. Bound static methods have their context set to the class name. * Throw errors at compile time for async or generator constructors * Improve handling of anonymous classes Anonymous classes are now always anonymous. If a name is required (e.g. for bound static methods or derived classes) then the class is compiled in an `ExecutableClassBody` which will give the anonymous class a stable reference. * Add a `replaceInContext` method to `Node` `replaceInContext` will traverse children looking for a node for which `match` returns true. Once found, the matching node will be replaced by the result of calling `replacement`. * Separate `this` assignments from function parameters This change has been made to simplify two future changes: 1. Outputting `@`-param assignments after a `super` call. In this case it is necessary that non-`@` parameters are available before `super` is called, so destructuring has to happen before `this` assignment. 2. Compiling destructured assignment to ES6 In this case also destructuring has to happen before `this`, as destructuring can happen in the arguments list, but `this` assignment can not. A bonus side-effect is that default values for `@` params are now output as ES6 default parameters, e.g. (@a = 1) -> becomes function a (a = 1) { this.a = a; } * Change `super` handling in class constructors Inside an ES derived constructor (a constructor for a class that extends another class), it is impossible to access `this` until `super` has been called. This conflicts with CoffeeScript's `@`-param and bound method features, which compile to `this` references at the top of a function body. For example: class B extends A constructor: (@param) -> super method: => This would compile to something like: class B extends A { constructor (param) { this.param = param; this.method = bind(this.method, this); super(...arguments); } } This would break in an ES-compliant runtime as there are `this` references before the call to `super`. Before this commit we were dealing with this by injecting an implicit `super` call into derived constructors that do not already have an explicit `super` call. Furthermore, we would disallow explicit `super` calls in derived constructors that used bound methods or `@`-params, meaning the above example would need to be rewritten as: class B extends A constructor: (@param) -> method: => This would result in a call to `super(...arguments)` being generated as the first expression in `B#constructor`. Whilst this approach seems to work pretty well, and is arguably more convenient than having to manually call `super` when you don't particularly care about the arguments, it does introduce some 'magic' and separation from ES, and would likely be a pain point in a project that made use of significant constructor overriding. This commit introduces a mechanism through which `super` in constructors is 'expanded' to include any generated `this` assignments, whilst retaining the same semantics of a super call. The first example above now compiles to something like: class B extends A { constructor (param) { var ref ref = super(...arguments), this.param = param, this.method = bind(this.method, this), ref; } } * Improve `super` handling in constructors Rather than functions expanding their `super` calls, the `SuperCall` node can now be given a list of `thisAssignments` to apply when it is compiled. This allows us to use the normal compiler machinery to determine whether the `super` result needs to be cached, whether it appears inline or not, etc. * Fix anonymous classes at the top level Anonymous classes in ES are only valid within expressions. If an anonymous class is at the top level it will now be wrapped in parenthses to force it into an expression. * Re-add Parens wrapper around executable class bodies This was lost in the refactoring, but it necessary to ensure `new class ...` works as expected when there's an executable body. * Throw compiler errors for badly configured derived constructors Rather than letting them become runtime errors, the following checks are now performed when compiling a derived constructor: - The constructor **must** include a call to `super`. - The constructor **must not** reference `this` in the function body before `super` has been called. * Add some tests exercising new class behaviour - async methods in classes - `this` access after `super` in extended classes - constructor super in arrow functions - constructor functions can't be async - constructor functions can't be generators - derived constructors must call super - derived constructors can't reference `this` before calling super - generator methods in classes - 'new' target * Improve constructor `super` errors Add a check for `super` in non-extended class constructors, and explicitly mention derived constructors in the "can't reference this before super" error. * Fix compilation of multiple `super` paths in derived constructors `super` can only be called once, but it can be called conditionally from multiple locations. The chosen fix is to add the `this` assignments to every super call. * Additional class tests, added as a separate file to simplify testing and merging. Some methods are commented out because they currently throw and I'm not sure how to test for compilation errors like those. There is also one test which I deliberately left without passing, `super` in an external prototype override. This test should 'pass' but is really a variation on the failing `super only allowed in an instance method` tests above it. * Changes to the tests. Found bug in super in prototype method. fixed. * Added failing test back in, dealing with bound functions in external prototype overrides. * Located a bug in the compiler relating to assertions and escaped ES6 classes. * Move tests from classes-additional.coffee into classes.coffee; comment out console.log * Cleaned up tests and made changes based on feedback. Test at the end still has issues, but it's commented out for now. * Make HoistTarget.expand recursive It's possible that a hoisted node may itself contain hoisted nodes (e.g. a class method inside a class method). For this to work the hoisted fragments need to be expanded recursively. * Uncomment final test in classes.coffee The test case now compiles, however another issue is affecting the test due to the error for `this` before `super` triggering based on source order rather than execution order. These have been commented out for now. * Fixed last test TODOs in test/classes.coffee Turns out an expression like `this.foo = super()` won't run in JS as it attempts to lookup `this` before evaluating `super` (i.e. throws "this is not defined"). * Added more tests for compatability checks, statics, prototypes and ES6 expectations. Cleaned test "nested classes with super". * Changes to reflect feedback and to comment out issues that will be addressed seperately. * Clean up test/classes.coffee - Trim trailing whitespace. - Rephrase a condition to be more idiomatic. * Remove check for `super` in derived constructors In order to be usable at runtime, an extended ES class must call `super` OR return an alternative object. This check prevented the latter case, and checking for an alternative return can't be completed statically without control flow analysis. * Disallow 'super' in constructor parameter defaults There are many edge cases when combining 'super' in parameter defaults with @-parameters and bound functions (and potentially property initializers in the future). Rather than attempting to resolve these edge cases, 'super' is now explicitly disallowed in constructor parameter defaults. * Disallow @-params in derived constructors without 'super' @-parameters can't be assigned unless 'super' is called.
2017-01-13 05:55:30 +00:00
'''
test "derived constructors can't reference `this` before calling super", ->
assertErrorFormat 'class extends A then constructor: -> @', '''
[stdin]:1:38: error: Can't reference 'this' before calling super in derived class constructors
class extends A then constructor: -> @
^
'''
test "derived constructors can't use @params without calling super", ->
assertErrorFormat 'class extends A then constructor: (@a) ->', '''
[stdin]:1:36: error: Can't use @params in derived class constructors without calling super
class extends A then constructor: (@a) ->
^^
'''
test "'super' is not allowed in constructor parameter defaults", ->
[CS2] Compile all super calls to ES2015 super (#4424) * Compile all super calls to ES2015 super This breaks using `super` in non-methods, meaning several tests are failing. Self-compilation still works. * Use bound functions for IIFEs containing `super` `super` can only be called directly in a method, or in an arrow function. * Fix handling of `class @A extends A` This behaviour worked 'for free' when the parent reference was being cached by the executable class body wrapper. There now needs to be special handling in place to check if the parent name matches the class name, and if so to cache the parent reference. * Fix tests broken by compiling ES2015 `super` * Disallow bare super This removes syntax support for 'bare' super calls, e.g.: class B extends A constructor: -> super `super` must now always be followed with arguments like a regular function call. This also removes the capability of implicitly forwarding arguments. The above can be equivalently be written as: class B extends A constructor: -> super arguments... * Support super with accessors `super` with following accessor(s) is now compiled to ES2015 equivalents. In particular, expressions such as `super.name`, `super[name]`, and also `super.name.prop` are all now valid, and can be used as expected as calls (i.e. `super.name()`) or in expressions (i.e. `if super.name? ...`). `super` without accessors is compiled to a constructor super call in a constructor, and otherwise, as before, to a super call to the method of the same name, i.e. speak: -> super() ...is equivalent to speak: -> super.speak() A neat side-effect of the changes is that existential calls now work properly with super, meaning `super?()` will only call if the super property exists (and is a function). This is not valid for super in constructors. * Prevent calling `super` methods with `new` This fixes a bug in the previous super handling whereby using the `new` operator with a `super` call would silently drop the `new`. This is now an explicit compiler error, as it is invalid JS at runtime. * Clean up some old super handling code This was mostly code for tracking the source classes and variables for methods, which were needed to build the old lookups on `__super__`. * Add TODO to improve bare super parse error * Add some TODOs to improve some of the class tests
2017-02-04 20:03:17 +00:00
assertErrorFormat 'class extends A then constructor: (a = super()) ->', '''
[CS2] Compile class constructors to ES2015 classes (#4354) * Compile classes to ES2015 classes Rather than compiling classes to named functions with prototype and class assignments, they are now compiled to ES2015 class declarations. Backwards compatibility has been maintained by compiling ES2015- incompatible properties as prototype or class assignments. `super` continues to be compiled as before. Where possible, classes will be compiled "bare", without an enclosing IIFE. This is possible when the class contains only ES2015 compatible expressions (methods and static methods), and has no parent (this last constraint is a result of the legacy `super` compilation, and could be removed once ES2015 `super` is being used). Classes are still assigned to variables to maintain compatibility for assigned class expressions. There are a few changes to existing functionality that could break backwards compatibility: - Derived constructors that deliberately don't call `super` are no longer possible. ES2015 derived classes can't use `this` unless the parent constructor has been called, so it's now called implicitly when not present. - As a consequence of the above, derived constructors with @ parameters or bound methods and explicit `super` calls are not allowed. The implicit `super` must be used in these cases. * Add tests to verify class interoperability with ES * Refactor class nodes to separate executable body logic Logic has been redistributed amongst the class nodes so that: - `Class` contains the logic necessary to compile an ES class declaration. - `ExecutableClassBody` contains the logic necessary to compile CS' class extensions that require an executable class body. `Class` still necessarily contains logic to determine whether an expression is valid in an ES class initializer or not. If any invalid expressions are found then `Class` will wrap itself in an `ExecutableClassBody` when compiling. * Rename `Code#static` to `Code#isStatic` This naming is more consistent with other `Code` flags. * Output anonymous classes when possible Anonymous classes can be output when: - The class has no parent. The current super compilation needs a class variable to reference. This condition will go away when ES2015 super is in use. - The class contains no bound static methods. Bound static methods have their context set to the class name. * Throw errors at compile time for async or generator constructors * Improve handling of anonymous classes Anonymous classes are now always anonymous. If a name is required (e.g. for bound static methods or derived classes) then the class is compiled in an `ExecutableClassBody` which will give the anonymous class a stable reference. * Add a `replaceInContext` method to `Node` `replaceInContext` will traverse children looking for a node for which `match` returns true. Once found, the matching node will be replaced by the result of calling `replacement`. * Separate `this` assignments from function parameters This change has been made to simplify two future changes: 1. Outputting `@`-param assignments after a `super` call. In this case it is necessary that non-`@` parameters are available before `super` is called, so destructuring has to happen before `this` assignment. 2. Compiling destructured assignment to ES6 In this case also destructuring has to happen before `this`, as destructuring can happen in the arguments list, but `this` assignment can not. A bonus side-effect is that default values for `@` params are now output as ES6 default parameters, e.g. (@a = 1) -> becomes function a (a = 1) { this.a = a; } * Change `super` handling in class constructors Inside an ES derived constructor (a constructor for a class that extends another class), it is impossible to access `this` until `super` has been called. This conflicts with CoffeeScript's `@`-param and bound method features, which compile to `this` references at the top of a function body. For example: class B extends A constructor: (@param) -> super method: => This would compile to something like: class B extends A { constructor (param) { this.param = param; this.method = bind(this.method, this); super(...arguments); } } This would break in an ES-compliant runtime as there are `this` references before the call to `super`. Before this commit we were dealing with this by injecting an implicit `super` call into derived constructors that do not already have an explicit `super` call. Furthermore, we would disallow explicit `super` calls in derived constructors that used bound methods or `@`-params, meaning the above example would need to be rewritten as: class B extends A constructor: (@param) -> method: => This would result in a call to `super(...arguments)` being generated as the first expression in `B#constructor`. Whilst this approach seems to work pretty well, and is arguably more convenient than having to manually call `super` when you don't particularly care about the arguments, it does introduce some 'magic' and separation from ES, and would likely be a pain point in a project that made use of significant constructor overriding. This commit introduces a mechanism through which `super` in constructors is 'expanded' to include any generated `this` assignments, whilst retaining the same semantics of a super call. The first example above now compiles to something like: class B extends A { constructor (param) { var ref ref = super(...arguments), this.param = param, this.method = bind(this.method, this), ref; } } * Improve `super` handling in constructors Rather than functions expanding their `super` calls, the `SuperCall` node can now be given a list of `thisAssignments` to apply when it is compiled. This allows us to use the normal compiler machinery to determine whether the `super` result needs to be cached, whether it appears inline or not, etc. * Fix anonymous classes at the top level Anonymous classes in ES are only valid within expressions. If an anonymous class is at the top level it will now be wrapped in parenthses to force it into an expression. * Re-add Parens wrapper around executable class bodies This was lost in the refactoring, but it necessary to ensure `new class ...` works as expected when there's an executable body. * Throw compiler errors for badly configured derived constructors Rather than letting them become runtime errors, the following checks are now performed when compiling a derived constructor: - The constructor **must** include a call to `super`. - The constructor **must not** reference `this` in the function body before `super` has been called. * Add some tests exercising new class behaviour - async methods in classes - `this` access after `super` in extended classes - constructor super in arrow functions - constructor functions can't be async - constructor functions can't be generators - derived constructors must call super - derived constructors can't reference `this` before calling super - generator methods in classes - 'new' target * Improve constructor `super` errors Add a check for `super` in non-extended class constructors, and explicitly mention derived constructors in the "can't reference this before super" error. * Fix compilation of multiple `super` paths in derived constructors `super` can only be called once, but it can be called conditionally from multiple locations. The chosen fix is to add the `this` assignments to every super call. * Additional class tests, added as a separate file to simplify testing and merging. Some methods are commented out because they currently throw and I'm not sure how to test for compilation errors like those. There is also one test which I deliberately left without passing, `super` in an external prototype override. This test should 'pass' but is really a variation on the failing `super only allowed in an instance method` tests above it. * Changes to the tests. Found bug in super in prototype method. fixed. * Added failing test back in, dealing with bound functions in external prototype overrides. * Located a bug in the compiler relating to assertions and escaped ES6 classes. * Move tests from classes-additional.coffee into classes.coffee; comment out console.log * Cleaned up tests and made changes based on feedback. Test at the end still has issues, but it's commented out for now. * Make HoistTarget.expand recursive It's possible that a hoisted node may itself contain hoisted nodes (e.g. a class method inside a class method). For this to work the hoisted fragments need to be expanded recursively. * Uncomment final test in classes.coffee The test case now compiles, however another issue is affecting the test due to the error for `this` before `super` triggering based on source order rather than execution order. These have been commented out for now. * Fixed last test TODOs in test/classes.coffee Turns out an expression like `this.foo = super()` won't run in JS as it attempts to lookup `this` before evaluating `super` (i.e. throws "this is not defined"). * Added more tests for compatability checks, statics, prototypes and ES6 expectations. Cleaned test "nested classes with super". * Changes to reflect feedback and to comment out issues that will be addressed seperately. * Clean up test/classes.coffee - Trim trailing whitespace. - Rephrase a condition to be more idiomatic. * Remove check for `super` in derived constructors In order to be usable at runtime, an extended ES class must call `super` OR return an alternative object. This check prevented the latter case, and checking for an alternative return can't be completed statically without control flow analysis. * Disallow 'super' in constructor parameter defaults There are many edge cases when combining 'super' in parameter defaults with @-parameters and bound functions (and potentially property initializers in the future). Rather than attempting to resolve these edge cases, 'super' is now explicitly disallowed in constructor parameter defaults. * Disallow @-params in derived constructors without 'super' @-parameters can't be assigned unless 'super' is called.
2017-01-13 05:55:30 +00:00
[stdin]:1:40: error: 'super' is not allowed in constructor parameter defaults
[CS2] Compile all super calls to ES2015 super (#4424) * Compile all super calls to ES2015 super This breaks using `super` in non-methods, meaning several tests are failing. Self-compilation still works. * Use bound functions for IIFEs containing `super` `super` can only be called directly in a method, or in an arrow function. * Fix handling of `class @A extends A` This behaviour worked 'for free' when the parent reference was being cached by the executable class body wrapper. There now needs to be special handling in place to check if the parent name matches the class name, and if so to cache the parent reference. * Fix tests broken by compiling ES2015 `super` * Disallow bare super This removes syntax support for 'bare' super calls, e.g.: class B extends A constructor: -> super `super` must now always be followed with arguments like a regular function call. This also removes the capability of implicitly forwarding arguments. The above can be equivalently be written as: class B extends A constructor: -> super arguments... * Support super with accessors `super` with following accessor(s) is now compiled to ES2015 equivalents. In particular, expressions such as `super.name`, `super[name]`, and also `super.name.prop` are all now valid, and can be used as expected as calls (i.e. `super.name()`) or in expressions (i.e. `if super.name? ...`). `super` without accessors is compiled to a constructor super call in a constructor, and otherwise, as before, to a super call to the method of the same name, i.e. speak: -> super() ...is equivalent to speak: -> super.speak() A neat side-effect of the changes is that existential calls now work properly with super, meaning `super?()` will only call if the super property exists (and is a function). This is not valid for super in constructors. * Prevent calling `super` methods with `new` This fixes a bug in the previous super handling whereby using the `new` operator with a `super` call would silently drop the `new`. This is now an explicit compiler error, as it is invalid JS at runtime. * Clean up some old super handling code This was mostly code for tracking the source classes and variables for methods, which were needed to build the old lookups on `__super__`. * Add TODO to improve bare super parse error * Add some TODOs to improve some of the class tests
2017-02-04 20:03:17 +00:00
class extends A then constructor: (a = super()) ->
^^^^^^^
[CS2] Compile class constructors to ES2015 classes (#4354) * Compile classes to ES2015 classes Rather than compiling classes to named functions with prototype and class assignments, they are now compiled to ES2015 class declarations. Backwards compatibility has been maintained by compiling ES2015- incompatible properties as prototype or class assignments. `super` continues to be compiled as before. Where possible, classes will be compiled "bare", without an enclosing IIFE. This is possible when the class contains only ES2015 compatible expressions (methods and static methods), and has no parent (this last constraint is a result of the legacy `super` compilation, and could be removed once ES2015 `super` is being used). Classes are still assigned to variables to maintain compatibility for assigned class expressions. There are a few changes to existing functionality that could break backwards compatibility: - Derived constructors that deliberately don't call `super` are no longer possible. ES2015 derived classes can't use `this` unless the parent constructor has been called, so it's now called implicitly when not present. - As a consequence of the above, derived constructors with @ parameters or bound methods and explicit `super` calls are not allowed. The implicit `super` must be used in these cases. * Add tests to verify class interoperability with ES * Refactor class nodes to separate executable body logic Logic has been redistributed amongst the class nodes so that: - `Class` contains the logic necessary to compile an ES class declaration. - `ExecutableClassBody` contains the logic necessary to compile CS' class extensions that require an executable class body. `Class` still necessarily contains logic to determine whether an expression is valid in an ES class initializer or not. If any invalid expressions are found then `Class` will wrap itself in an `ExecutableClassBody` when compiling. * Rename `Code#static` to `Code#isStatic` This naming is more consistent with other `Code` flags. * Output anonymous classes when possible Anonymous classes can be output when: - The class has no parent. The current super compilation needs a class variable to reference. This condition will go away when ES2015 super is in use. - The class contains no bound static methods. Bound static methods have their context set to the class name. * Throw errors at compile time for async or generator constructors * Improve handling of anonymous classes Anonymous classes are now always anonymous. If a name is required (e.g. for bound static methods or derived classes) then the class is compiled in an `ExecutableClassBody` which will give the anonymous class a stable reference. * Add a `replaceInContext` method to `Node` `replaceInContext` will traverse children looking for a node for which `match` returns true. Once found, the matching node will be replaced by the result of calling `replacement`. * Separate `this` assignments from function parameters This change has been made to simplify two future changes: 1. Outputting `@`-param assignments after a `super` call. In this case it is necessary that non-`@` parameters are available before `super` is called, so destructuring has to happen before `this` assignment. 2. Compiling destructured assignment to ES6 In this case also destructuring has to happen before `this`, as destructuring can happen in the arguments list, but `this` assignment can not. A bonus side-effect is that default values for `@` params are now output as ES6 default parameters, e.g. (@a = 1) -> becomes function a (a = 1) { this.a = a; } * Change `super` handling in class constructors Inside an ES derived constructor (a constructor for a class that extends another class), it is impossible to access `this` until `super` has been called. This conflicts with CoffeeScript's `@`-param and bound method features, which compile to `this` references at the top of a function body. For example: class B extends A constructor: (@param) -> super method: => This would compile to something like: class B extends A { constructor (param) { this.param = param; this.method = bind(this.method, this); super(...arguments); } } This would break in an ES-compliant runtime as there are `this` references before the call to `super`. Before this commit we were dealing with this by injecting an implicit `super` call into derived constructors that do not already have an explicit `super` call. Furthermore, we would disallow explicit `super` calls in derived constructors that used bound methods or `@`-params, meaning the above example would need to be rewritten as: class B extends A constructor: (@param) -> method: => This would result in a call to `super(...arguments)` being generated as the first expression in `B#constructor`. Whilst this approach seems to work pretty well, and is arguably more convenient than having to manually call `super` when you don't particularly care about the arguments, it does introduce some 'magic' and separation from ES, and would likely be a pain point in a project that made use of significant constructor overriding. This commit introduces a mechanism through which `super` in constructors is 'expanded' to include any generated `this` assignments, whilst retaining the same semantics of a super call. The first example above now compiles to something like: class B extends A { constructor (param) { var ref ref = super(...arguments), this.param = param, this.method = bind(this.method, this), ref; } } * Improve `super` handling in constructors Rather than functions expanding their `super` calls, the `SuperCall` node can now be given a list of `thisAssignments` to apply when it is compiled. This allows us to use the normal compiler machinery to determine whether the `super` result needs to be cached, whether it appears inline or not, etc. * Fix anonymous classes at the top level Anonymous classes in ES are only valid within expressions. If an anonymous class is at the top level it will now be wrapped in parenthses to force it into an expression. * Re-add Parens wrapper around executable class bodies This was lost in the refactoring, but it necessary to ensure `new class ...` works as expected when there's an executable body. * Throw compiler errors for badly configured derived constructors Rather than letting them become runtime errors, the following checks are now performed when compiling a derived constructor: - The constructor **must** include a call to `super`. - The constructor **must not** reference `this` in the function body before `super` has been called. * Add some tests exercising new class behaviour - async methods in classes - `this` access after `super` in extended classes - constructor super in arrow functions - constructor functions can't be async - constructor functions can't be generators - derived constructors must call super - derived constructors can't reference `this` before calling super - generator methods in classes - 'new' target * Improve constructor `super` errors Add a check for `super` in non-extended class constructors, and explicitly mention derived constructors in the "can't reference this before super" error. * Fix compilation of multiple `super` paths in derived constructors `super` can only be called once, but it can be called conditionally from multiple locations. The chosen fix is to add the `this` assignments to every super call. * Additional class tests, added as a separate file to simplify testing and merging. Some methods are commented out because they currently throw and I'm not sure how to test for compilation errors like those. There is also one test which I deliberately left without passing, `super` in an external prototype override. This test should 'pass' but is really a variation on the failing `super only allowed in an instance method` tests above it. * Changes to the tests. Found bug in super in prototype method. fixed. * Added failing test back in, dealing with bound functions in external prototype overrides. * Located a bug in the compiler relating to assertions and escaped ES6 classes. * Move tests from classes-additional.coffee into classes.coffee; comment out console.log * Cleaned up tests and made changes based on feedback. Test at the end still has issues, but it's commented out for now. * Make HoistTarget.expand recursive It's possible that a hoisted node may itself contain hoisted nodes (e.g. a class method inside a class method). For this to work the hoisted fragments need to be expanded recursively. * Uncomment final test in classes.coffee The test case now compiles, however another issue is affecting the test due to the error for `this` before `super` triggering based on source order rather than execution order. These have been commented out for now. * Fixed last test TODOs in test/classes.coffee Turns out an expression like `this.foo = super()` won't run in JS as it attempts to lookup `this` before evaluating `super` (i.e. throws "this is not defined"). * Added more tests for compatability checks, statics, prototypes and ES6 expectations. Cleaned test "nested classes with super". * Changes to reflect feedback and to comment out issues that will be addressed seperately. * Clean up test/classes.coffee - Trim trailing whitespace. - Rephrase a condition to be more idiomatic. * Remove check for `super` in derived constructors In order to be usable at runtime, an extended ES class must call `super` OR return an alternative object. This check prevented the latter case, and checking for an alternative return can't be completed statically without control flow analysis. * Disallow 'super' in constructor parameter defaults There are many edge cases when combining 'super' in parameter defaults with @-parameters and bound functions (and potentially property initializers in the future). Rather than attempting to resolve these edge cases, 'super' is now explicitly disallowed in constructor parameter defaults. * Disallow @-params in derived constructors without 'super' @-parameters can't be assigned unless 'super' is called.
2017-01-13 05:55:30 +00:00
'''
test "can't use pattern matches for loop indices", ->
assertErrorFormat 'a for b, {c} in d', '''
[stdin]:1:10: error: index cannot be a pattern matching expression
a for b, {c} in d
^^^
'''
[CS2] Compile all super calls to ES2015 super (#4424) * Compile all super calls to ES2015 super This breaks using `super` in non-methods, meaning several tests are failing. Self-compilation still works. * Use bound functions for IIFEs containing `super` `super` can only be called directly in a method, or in an arrow function. * Fix handling of `class @A extends A` This behaviour worked 'for free' when the parent reference was being cached by the executable class body wrapper. There now needs to be special handling in place to check if the parent name matches the class name, and if so to cache the parent reference. * Fix tests broken by compiling ES2015 `super` * Disallow bare super This removes syntax support for 'bare' super calls, e.g.: class B extends A constructor: -> super `super` must now always be followed with arguments like a regular function call. This also removes the capability of implicitly forwarding arguments. The above can be equivalently be written as: class B extends A constructor: -> super arguments... * Support super with accessors `super` with following accessor(s) is now compiled to ES2015 equivalents. In particular, expressions such as `super.name`, `super[name]`, and also `super.name.prop` are all now valid, and can be used as expected as calls (i.e. `super.name()`) or in expressions (i.e. `if super.name? ...`). `super` without accessors is compiled to a constructor super call in a constructor, and otherwise, as before, to a super call to the method of the same name, i.e. speak: -> super() ...is equivalent to speak: -> super.speak() A neat side-effect of the changes is that existential calls now work properly with super, meaning `super?()` will only call if the super property exists (and is a function). This is not valid for super in constructors. * Prevent calling `super` methods with `new` This fixes a bug in the previous super handling whereby using the `new` operator with a `super` call would silently drop the `new`. This is now an explicit compiler error, as it is invalid JS at runtime. * Clean up some old super handling code This was mostly code for tracking the source classes and variables for methods, which were needed to build the old lookups on `__super__`. * Add TODO to improve bare super parse error * Add some TODOs to improve some of the class tests
2017-02-04 20:03:17 +00:00
test "bare 'super' is no longer allowed", ->
# TODO Improve this error message (it should at least be 'unexpected super')
assertErrorFormat 'class extends A then constructor: -> super', '''
[stdin]:1:35: error: unexpected ->
class extends A then constructor: -> super
^^
'''
test "soaked 'super' in constructor", ->
assertErrorFormat 'class extends A then constructor: -> super?()', '''
[stdin]:1:38: error: Unsupported reference to 'super'
class extends A then constructor: -> super?()
^^^^^
'''
test "new with 'super'", ->
assertErrorFormat 'class extends A then foo: -> new super()', '''
[stdin]:1:34: error: Unsupported reference to 'super'
class extends A then foo: -> new super()
^^^^^
'''