Thank you, I was not searching strictly for a bug or regression, a malpractice was also something I wanted to ear about. The let form generates this in both 1.8 & 1.9. No idea why the defrecord compiles in 1.8 but that could be related to the way it is expanded in each version. I don't see the point of going down further on this path.
I will change the macro code here accordingly. Luc P. On Tuesday, 2 January 2018 22:22:18 UTC, Nicola Mometto wrote: > > The code that caused this issue is > > https://github.com/clojure/clojure/commit/a1c3dafec01ab02fb10d91f98b9ffd3241e860c0?diff=unified#diff-03234b041c0917ec98f2ad9477a0a014R260 > > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fclojure%2Fclojure%2Fcommit%2Fa1c3dafec01ab02fb10d91f98b9ffd3241e860c0%3Fdiff%3Dunified%23diff-03234b041c0917ec98f2ad9477a0a014R260&sa=D&sntz=1&usg=AFQjCNHRjVcQGlXG4OrOts7U2jK06kc8ig> > > But this is not a bug in the clojure code nor a regression, in fact > you can reproduce this in any clojure version with the following code: > > (defmacro m [] `[~@(keys &env)]) > (defprotocol p (f [_])) > (deftype t [^int x] p (f [_] (m))) > > > This is happening for the same reason why (let [x (int 1)] (identity > ^int x)) throws the same error, the fix in your case is to use (map > #(with-meta % {}) (keys &env)) > > On Tue, Jan 2, 2018 at 11:03 PM, Luc <lprefo...@softaddicts.ca > <javascript:>> wrote: > > Hi, > > > > finally got some time to dig deeper. The minimal code to reproduce this > has > > shrunk: > > > > (defprotocol Anonymous > > (start-job! [this])) > > > > (defrecord NoopJob [] > > Anonymous > > (start-job! [this] > > (yabug.services.logger/environment))) > > > > The environment macro was called by log/error but not by the other > severity > > level macros. > > The error macro within a defrecord is the only case where it fails. > > > > This is the environment macro definition: > > > > (defmacro environment > > "Expands to code that generates a map of locals: names to values" > > [] > > (clojure.pprint/pprint (macroexpand `(zipmap '~(keys &env) [~@(keys > > &env)]))) > > `(zipmap '~(keys &env) [~@(keys &env)])) > > > > I added the macroexpand in the macro to get what it expands to in the > > context of the defrecord > > at compile time. > > Outside of the defrecord the compiler does not complain (let, ...)). The > > protocol by itself does not seem > > to be a significant factor. I got this at different places under > different > > protocols. > > > > This is the 1.9 macro expansion outputted at compile time before ending > up > > with exception while evaluating > > the resulting code: > > > > (clojure.core/zipmap > > '(__hash __meta this __hasheq __extmap) > > [__hash __meta this __hasheq __extmap]) > > > > This is the 1.8 macroexpansion of this macro which is a bit shorter, > there's > > seem to be less context generated by the defrecord macro > > expansion: > > > > (clojure.core/zipmap '(__meta this __extmap) [__meta this __extmap]) > > > > The expansion of the defrecord context is slightly bigger but nothing > hits > > me when I compare both expanded vectors at the end. > > I am assuming that this the expression that the compiler cannot evaluate > in > > 1.9 since it the error originates from the VectorExpr > > class. > > Is there anything obvious on with the evaluation of the last vector in > the > > 1.9 expansion that would explain this error ? > > I don't see it. > > > > Just to make things more puzzling the expansion literally works in the > 1.9 > > REPL: > > > > => (defrecord NoopJob [] > > impl/GatewayJob > > (start-job! [this] > > (clojure.core/zipmap > > '(__hash __meta this __hasheq __extmap) > > [__hash __meta this __hasheq __extmap]))) > > yabug.jobs.noop.NoopJob > > > > Grr... > > > > Will sleep on it and toy with it tomorrow by expanding a bit the test > cases. > > It's nearly 22:00 Morocco time here. > > I need a break and some sleep. > > > > Luc P. > > > > On Saturday, 30 December 2017 01:00:05 UTC, Alex Miller wrote: > >> > >> On Fri, Dec 29, 2017 at 6:17 PM, Luc <lprefo...@softaddicts.ca> wrote: > >> > >>> > >>> here it is, I did not get through the compiler source code yet, it > might > >>> be obvious to you: > >>> > >>> java.lang.UnsupportedOperationException: Can't type hint a primitive > >>> local, compiling:(yabug/jobs/noop.clj:21:9) > >>> Exception in thread "main" java.lang.UnsupportedOperationException: > Can't > >>> type hint a primitive local, compiling:(yabug/jobs/noop.clj:21:9) > >> > >> > >> What's the code here? ^^ > >> > >> > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com > <javascript:> > > Note that posts from new members are moderated - please be patient with > your > > first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > Groups > > "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to clojure+u...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
