Why would ::test/once-fixtures (where test is an alias of the clojure.test ns) be an invalid token in clojure-1.9 but not in clojure-1.8?

Background: https://github.com/clojure-emacs/cider-nrepl/pull/446

It should be :test/once-fixtures not ::test/once-fixtures as I recall.

I believe in Clojure 1.9 that ::full.name.space/kw-name is now an error. ::namespace-alias/kw-name was accepted before Clojure 1.9, and still is, but now only if namespace-alias is a currently valid namespace alias, and the actual keyword is the resolved full namespace name.

By which I mean, when you use ::namespace-alias/kw-name while namespace-alias is an alias for foo, then the namespace of the keyword produced by reading ::namespace-alias/kw-name will be foo, the same as if you had typed :foo/kw-name

@cddr In the Github PR you link to, since there is a require of [clojure.test :as test], the syntax ::test/once-fixtures should result in the same keyword as :clojure.test/once-fixtures

That should have been the case before Clojure 1.9, and should still be the case with Clojure 1.9, so it isn't clear to me why you would be getting any errors with the code before that change.

That's what I would have thought too. I'll do a bit more digging to see if I can pin it down.

@cddr That PR is odd. The error message referred to has ::clojure.test/once-fixtures which was definitely made invalid in 1.9 (because it should have been invalid). I misread your question to be about that. I think that error was fixed on cider-nrepl master but either not yet released or you're not on the latest version: the fix was to change ::clojure.test/once-fixtures (invalid) to ::test/once-fixtures (valid). That PR suggests changing that again (unnecessary) to :clojure.test/once-fixtures (still valid) but the change is from ::test/once-fixtures (already valid).

(I should have looked at the PR in more detail -- but it was 1am... and I probably shouldn't have been responding to Slack questions anyway! 🙂 )

You're right. I forgot to try just lein install master before "fixing". I've closed the PR.

I’m having an issue analyzing stack traces when code has been direct linked, and I can’t work out what the right thing to do is. For example:

cursive_1865.core_test$is_true.invokeStatic (core_test.clj:6)
cursive_1865.core_test$is_true.invoke (core_test.clj:5)

Here the var is simply invoking the static version, but their source lines are different. From a fairly small sample, this always seems to be the case, and the static version seems to have the correct line number.

Can anyone explain this, or at a minimum just confirm that if I see a static invoke followed by an invoke in a stacktrace I should just use the line number from the static one?

I’m also curious why this happens, but mostly I want to know what to do 🙂

@cfleming - Not the complete answer you want, but an early discussion of the change before Clojure 1.8 was released; https://groups.google.com/forum/#!searchin/clojure-dev/invokestatic%7Csort:relevance/clojure-dev/xDx3qsjhLVs/MGyNh8ZeCQAJ

I'm pretty sure there was a relevant patch after that time that changed the line number reporting further, because at that time some of the line numbers were reported as -1, not 1 more than the other

This ticket also looks relevant: https://dev.clojure.org/jira/browse/CLJ-1854

@ghadi Given you wrote the patch for that ticket, maybe you recall the details and know the answer to cfleming's questions?