Fork me on GitHub
#cljs-dev
<
2020-05-02
>
dominicm08:05:55

@dnolen I'm still seeing delete be munged to delete$ with :language-out set to :es-next. It appears that :es5 first allowed delete to be used as a method.

dominicm08:05:18

I'm not sure if this particular version should work, but it's one instance of the problem:

❯ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.748"}}}' -m cljs.main -co '{:language-out :es5}' --repl
ClojureScript 1.10.748
cljs.user=> (str (fn [] (js/window.delete)))
"function (){\nreturn window.delete$();\n}"
cljs.user=> 

mfikes14:05:03

Found a regression (not in 1.10.753, but in 1.10.741): https://clojure.atlassian.net/browse/CLJS-3244 (This is why Planck started failing in Canary, but it took me a while to track down as an upstream compiler issue.)

dnolen15:05:21

@dominicm can you say more simply what the bug is :es-next does not work, but :es6 and :es5 do?

dominicm15:05:46

@dnolen Oops, I shouldn't have said ":es5 first allowed delete", I should have said "es5 first allowed...". None of the clojurescript languages support delete right now.

dnolen15:05:22

@mfikes but still present in 753 yes?

dnolen15:05:48

@dominicm that's a bit odd since that's exactly what somebody tried the other day and it worked for them.

dnolen15:05:07

@dominicm oh but that was default

dnolen15:05:35

@dominicm this is trivial patch if you wanna submit one 🙂

dominicm15:05:36

Yeah, default is explicitly whitelisted it seems. I think delete just needs adding to that list. I'm not sure if there's a list of the keywords that were added in es5

dominicm15:05:02

Cool :) Will do, wanted to make sure it made sense first.

dnolen15:05:01

@dominicm if you do that patch, it would be nice to just fix this up to include whatever reserved things became non-reserved

dominicm15:05:35

Yeah, looking for the spec now

dnolen15:05:35

@dominicm tests would be nice, but if you don't do that I can easily add those to test the different compiler settings

dnolen15:05:09

@mfikes thanks bumped to blocker though I think probably trivial - I suspect there's just a bad var in that file

dominicm16:05:16

Oh god, my eyes: > For web browsers, there is an exception to this rule, namely when reserved words are used. Most browsers support identifiers that unescape to a reserved word, as long as at least one character is escaped using a Unicode escape sequence. For example, var var; wouldn’t work, but e.g. var v\u0061r; would

mfikes16:05:43

I'm working on this minor self-host regression: https://clojure.atlassian.net/browse/CLJS-3245

mfikes16:05:55

^ Hah, this one is being caught by CI

dominicm16:05:25

looking closer, as far a I can tell function delete(){ } is not supported, but let x = {}; x.delete = function() { return 10 } works. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Property_accessors notes that properties must be an "IdentifierName", which means they can be any reserved keyword. That goes all the way back given the wording.

dominicm16:05:44

I think it's sensible to be generating functions without reserved keywords in but when emitting the syntax for things like js/window.xxx or react/xxx the name shouldn't be munged - it should generally be left alone.