NPE when AOTing overrided clojure.core functions
Description
Environment
Attachments
- 31 Jul 2013, 01:29 AM
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
Assignee
UnassignedUnassignedReporter
importimportApproval
OkPatch
CodePriority
MajorAffects versions
Fix versions
Details
Details
Assignee
Reporter
Approval
Patch
Priority
Major
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:
$ lein new aot-get $ cd aot-get $ sed -i s/foo/get/ $ lein compile :all WARNING: get already refers to: #'clojure.core/get in namespace: aot-get.core, being replaced by: #'aot-get.core/get Exception in thread "main" java.lang.NullPointerException at clojure.lang.Compiler$ObjExpr.emitVar(Compiler.java:4858) at clojure.lang.Compiler$DefExpr.emit(Compiler.java:428) at clojure.lang.Compiler.compile1(Compiler.java:7152) at clojure.lang.Compiler.compile(Compiler.java:7219) at clojure.lang.RT.compile(RT.java:398) at clojure.lang.RT.load(RT.java:438) at clojure.lang.RT.load(RT.java:411)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