And to be as specific as possible, the actual test that worked in 1.9 but not in 1.10 is: https://github.com/Engelberg/instaparse/blob/dcfffad5b065e750f0f5835f017cdd8188b8ca2e/test/instaparse/defparser_test.cljc#L34
I've temporarily elided the test from the instaparse test suite, but wanted to report it. Again, I apologize for not realizing the eval/quote was an important aspect and leading you down a rabbit hole. On Tue, Dec 18, 2018 at 12:21 PM Mark Engelberg <mark.engelb...@gmail.com> wrote: > Sorry, I tried to "shrink the error case" and I appear to have gone too > far. The actual problem would be more like: > => (is (thrown? AssertionError (eval (quote (f true)))) > > On Tue, Dec 18, 2018 at 11:11 AM Alex Miller <a...@puredanger.com> wrote: > >> Oh, if you're testing with thrown-with-msg?, that definitely can have an >> impact due to the nested exception. In clojure.test, I'm using a variant to >> test the message with the root cause: >> >> >> https://github.com/clojure/clojure/blob/master/test/clojure/test_helper.clj#L134-L151 >> >> On Tuesday, December 18, 2018 at 12:06:18 PM UTC-6, Andy Fingerhut wrote: >>> >>> I do not know if Leiningen is involved in the difference in the >>> reproduction project linked below yet (I am testing with the latest >>> Leiningen 2.8.3 here), but I do see a clojure.test `(is (thrown-with-msg? >>> ...` expression that gives no error when running 'lein test' with Clojure >>> 1.9.0, but does with Clojure 1.10.0. I do not know if it is the same root >>> cause as Mark's example or not, but wanted to create this in hopes it >>> represents a minimal test case to reproduce the behavior difference. >>> >>> https://github.com/jafingerhut/clojure-110-is-thrown >>> >>> Andy >>> >>> On Tue, Dec 18, 2018 at 7:07 AM Alex Miller <a...@puredanger.com> wrote: >>> >>>> In particular, I am challenging this assertion from the original post: >>>> >>>> However, the following test (using is from clojure.test) used to work >>>> prior to 1.10, but now fails: >>>> >>>> => (is (thrown? AssertionError (f true))) >>>> Unexpected error (AssertionError) macroexpanding f at >>>> (test:localhost:62048(clj)*:268:56). >>>> Assert failed: (number? x) >>>> >>>> >>>> When I do this on 1.9 I see: >>>> >>>> user=> (is (thrown? AssertionError (f true))) >>>> CompilerException java.lang.AssertionError: Assert failed: (number? x), >>>> compiling:(NO_SOURCE_PATH:20:29) >>>> >>>> >>>> Which is printed differently but is the same behavior, because this is >>>> happening while expanding the is, not during execution. >>>> >>>> I believe you're seeing a change in your test suite, I'm just having a >>>> hard time reproducing what you're seeing. >>>> >>>> >>>> On Tuesday, December 18, 2018 at 8:47:11 AM UTC-6, Alex Miller wrote: >>>>> >>>>> This particular example given fails in a similar way on 1.9. Could you >>>>> give me something closer to what you are actually seeing in your test >>>>> suite? Specifically something that is a passing clojure.test test on 1.9 >>>>> but a failure/error on 1.10? >>>>> >>>>> The problem with the given example is that it fails during >>>>> macroexpansion of the test itself, not during test execution, and I don't >>>>> think that's the case you're trying to replicate. >>>>> >>>>> On Tuesday, December 18, 2018 at 8:35:54 AM UTC-6, Alex Miller wrote: >>>>>> >>>>>> I think the relevant change here is that exceptions thrown during >>>>>> macroexpansion are now wrapped into CompilerExceptions as a way to attach >>>>>> all of the source context information. The REPL understands this and >>>>>> still >>>>>> prints the original cause so the printing hides some of that structure >>>>>> (but >>>>>> you can see it by looking at the exception chain). >>>>>> >>>>>> This here is a particularly tricky case here though and I think there >>>>>> might be something else coming into play, still looking at it. There was >>>>>> a >>>>>> couple other changes inside the compiler exception handling that might >>>>>> also >>>>>> be coming into play. >>>>>> >>>>>> (Would have been great to see this during a pre-release build rather >>>>>> than after release! ;) >>>>>> >>>>>> >>>>>> On Tuesday, December 18, 2018 at 3:51:58 AM UTC-6, puzzler wrote: >>>>>>> >>>>>>> Agreed. It is not a problem for functions which throw >>>>>>> AssertionErrors, only macros. But this is a change in behavior which >>>>>>> breaks test suites which passed previously. >>>>>>> >>>>>>> On Tue, Dec 18, 2018 at 1:48 AM alex <fmno...@gmail.com> wrote: >>>>>>> >>>>>>>> I'm not sure, but probably it behaves so because of throwing at >>>>>>>> macroexpand stage. >>>>>>>> >>>>>>>> вторник, 18 декабря 2018 г., 11:29:09 UTC+2 пользователь puzzler >>>>>>>> написал: >>>>>>>>> >>>>>>>>> Consider the following macro: >>>>>>>>> >>>>>>>>> (defmacro f [x] {:pre [(number? x)]} `(+ ~x 5)) >>>>>>>>> => (f 3) >>>>>>>>> 8 >>>>>>>>> => (f true) >>>>>>>>> Unexpected error (AssertionError) macroexpanding f at >>>>>>>>> (test:localhost:62048(clj)*:265:28). >>>>>>>>> Assert failed: (number? x) >>>>>>>>> >>>>>>>>> So, as expected it throws an AssertionError if passed a non-number. >>>>>>>>> However, the following test (using is from clojure.test) used to >>>>>>>>> work prior to 1.10, but now fails: >>>>>>>>> >>>>>>>>> => (is (thrown? AssertionError (f true))) >>>>>>>>> Unexpected error (AssertionError) macroexpanding f at >>>>>>>>> (test:localhost:62048(clj)*:268:56). >>>>>>>>> Assert failed: (number? x) >>>>>>>>> >>>>>>>>> What's odd is that the macro still throws an AssertionError, but >>>>>>>>> the `thrown?` inside the `is` is no longer intercepting the >>>>>>>>> AssertionError, >>>>>>>>> so the test doesn't pass -- instead the error causes a failure in the >>>>>>>>> test >>>>>>>>> suite. >>>>>>>>> >>>>>>>> -- >>>> 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. >>>> >>> -- >> 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. >> > -- 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.
