I'd like to keep an issue open for the things we do that "patch" inconsistencies in the Espruino interpreter. The less we have to do to the compiled CLJS, the better I think. So if we close issues that "fix" bugs but don't really fix the interpreter, we should note that those bugs really still do exists and once they get fixed upstream, revert our change and really close the issue.
Issues we've patched that are also patched in upstream, waiting for binary release to revert our fix
I'd like to keep an issue open for the things we do that "patch" inconsistencies in the Espruino interpreter. The less we have to do to the compiled CLJS, the better I think. So if we close issues that "fix" bugs but don't really fix the interpreter, we should note that those bugs really still do exists and once they get fixed upstream, revert our change and really close the issue.
Issues we've patched that are also patched in upstream, waiting for binary release to revert our fix
ReferenceError
on(function(){return arguments[0];})(undefined);
(Exceptions thrown on undefined returns from muli-arity CLJS methods) #3 https://github.com/espruino/Espruino/issues/1691"b"
equivalent to"undefined"
inpr
#15 https://github.com/espruino/Espruino/issues/1906Issues we've patched, but still exist upstream
try/catch
doesn't return the value oftry
on success - it must be wrapped in a fn and called with returnIssues that we've not patched, but are patched upstream, waiting for binary release to close
Math/floor
broken #7 https://github.com/espruino/Espruino/issues/1865Issues that we've not patched and still exist upstream