The JS++ core is now down to 9 low-priority bugs after 3.5 years of engineering and 400k+ lines of source code thanks to our lead engineer, Anton Rapetov.
Building on top of our release of “existent types” to prevent out-of-bounds errors, we’ve had enough time for testing and feedback to discover that existent types work, and they will remain a cornerstone of JS++ going forward into the future.
This latest release, version 0.9.1, focuses primarily on bug fixes. We value disciplined engineering, and we wanted to pay back technical debts. However, despite the bug fix theme, there are a few notable features and announcements. I’ll highlight what’s new or changed, and the list of bug fixes will be at the end.
Console.trace
While we’ve had Console.log for a long time, it doesn’t include critical information on where the log message originated from. You might find the new Console.trace method more useful:
filename.js++:3:0: Now we have the original file location, line number, and column number for our logs!
Block Scoping
We’ve also had block scoping semantics for a long time. JS++ brings you high-performance block scoping — even in ECMAScript 3 environments.
In the latest version, block scoping is finalized and all corner cases should be covered. Specifically, we fixed code generation corner cases of lowering to the function scoping semantics of ECMAScript 3.
(We are keenly aware of the block scoping available in ECMAScript 3+ ‘catch’ blocks, which we addressed since the very first release of JS++ as being too costly in terms of performance. This is a gem of the ECMAScript specification that few people know about, and it highlights why you should trust our knowledge and experience – rather than choosing Microsoft just on brand name – going into the future.)
Existent Types
In the last version, 0.9.0, we announced existent types to prevent runtime out-of-bounds errors. In this release (0.9.1), we are doubling down on existent types and revising the rules based on experience, feedback, and re-design:
- If type
Thas an implicit conversion toexternal,T+also has an implicit conversion toexternal - The safe navigation operator (
??) has a higher operator precedence. See the operator precedence documentation. - Relax getter/setter type rules for nullable and existent types
- Disallow
void+and any usages ofvoidexcept as a return type - Forbid
externalas a common type forintandstringfor the safe navigation operator (??). Thanks to user @h-h in the JS++ Community Chat for reporting this bug. - Fix error message when upcasting/downcasting in the context of nullable/existent types to make it clearer
Nested Generics with Generic Parameters
In previous releases, we had left nested generics (with generic parameters) unimplemented. Previously, the following code worked:
Array<Array<int>> arr1; // nested, non-parametric Array<T> arr2; // non-nested, parametric
The latest version now enables nested generics with generic parameters:
Array<Array<T>> foo; // nested *and* parametric
Bug Fixes
Finally, here is a list of all the other bug fixes. There are a lot. The latest 0.9.1 release brings JS++ software quality to its highest level yet by addressing technical debt rather than delivering new features.
Fixed:
- ‘foreach’ looping over external “array-like objects”
- SyntaxError in generated code for generic functions/casting
- Error message for
super()on base class - Duplicated error messages
- Line terminators in strings generated via escape sequences
- Fix segfault when casting away nullable type of non-static field
- Don’t raise a redundant error of accessing a parameter that was shadowed
- Raise a special error “Re-declaration of parameter”, if a parameter was shadowed
- Allow hoisting of static class fields across different classes in the same module
- Do parameter and arity checking on
new - Wrong line number for dot operator
- Inaccurate error message for generic instanceof
- Only one error message for method overriding when inheriting from generic class with non-existent argument
Conclusion
Software quality at JS++ has always remained high, and that’s a testament to the ability of our lead engineer, Anton Rapetov, and our engineering approach. In more than 3.5 years of engineering, we currently have fewer than 10 open bug reports in the core compiler.
Roger Poon