NPE when AOTing overrided clojure.core functions
Description
Environment
Attachments
Activity
Alex Miller March 31, 2014 at 5:57 PM
To me, Triage (and Vetting) is all about having good problem statements. For a defect, it is most important to demonstrate the problem (what happens now) and what you expect to happen instead. I do not usually expect there to necessarily be "by ____" in the ticket - to me that is part of working through the solution (although it is typical to have this in an enhancement). This ticket, as it stands now, seems to have both a good problem statement and a good cause/solution statement so seems to exceed Triaging standards afaik.
Two places where I have tried to write about these things in the past are http://dev.clojure.org/display/community/Creating+Tickets and in the Triage process on the workflow page http://dev.clojure.org/display/community/JIRA+workflow.
Andy Fingerhut March 31, 2014 at 3:34 PM
Alex, I have looked through the existing wiki pages on the ticket tracking process, and do not recall seeing anything about this desired aspect of a triaged ticket. Is it already documented somewhere and I missed it? Not that it has to be documented, necessarily, but Rich saying "triage guidelines" makes it sound like a filter he applies that ticket creators and screeners maybe should know about.
Alex Miller March 27, 2014 at 5:00 PM
I think Rich meant that a ticket should have a plan of that form but does not. My own take on "triaged" is that it should state actual and expected results demonstrating a problem - I don't think it needs to actually describe the solution (as that can happen later in development). It is entirely possible that Rich and I differ in our interpretation of that. I will see if I can rework the description a bit to match what I've been doing elsewhere.
Nicola Mometto March 26, 2014 at 7:13 PM
Andy, I added the two last lines in the description after reading Rich's comment to explain why this bug happens and how the patch I attached works around this.
I don't know if this is what he was asking for though.
Andy Fingerhut March 26, 2014 at 7:07 PM
It may help if someone could clarify Rich's comment.
Does it mean that the ticket should include a plan of the form "therefore we will fix it by _____ so it then does _____", but this ticket doesn't have that?
Or perhaps it means that the ticket should not include a plan of that form, but this ticket does? If so, I don't see it, except perhaps the very last sentence of the description. If that is a problem for vetting a ticket, perhaps we could just delete that sentence and proceed from there?
Something else?
Details
Details
Assignee
Reporter
Approval
Patch
Priority

When performing AOT compilation on a namespace that overrides a clojure.core function without excluding the original clojure.core function from the ns, you get a NullPointerException.
To reproduce aot compile a namespace like "(ns x) (defn get [])"
For example:
Cause: DefExpr.parse does not call registerVar for vars overridding clojure.core ones, thus when AOT compiling the var is not registered in the constant table.
Proposed: The attached patch makes DefExpr.parse call registerVar for vars overridding clojure.core ones.
Patch: 0001-fix-CLJ-1241.patch
Screened by: Alex Miller