[CLJS-476] Reading a value from a module does not work if the module is def'ed Created: 22/Feb/13 Updated: 22/Feb/13 |
|
| Status: | Open |
| Project: | ClojureScript |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Paul Gearon | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Compiler, bug, scope | ||
| Environment: |
Clojure 1.5.0-RC16 |
||
| Description |
|
Referring to a value in a module can have a scoping issue when using the "static accessor" operator of module/VALUE_NAME. The static accessor works if the module is loaded into a local value but not if def'ed. This example uses the mmap module for Node.js, and successfully reads the PROT_READ value: (ns stat.core) This correctly prints "value: 1" However, if the value for m is def'ed instead, then the compiler assumes that the reference to m is local to the function and therefore not defined: (ns stat.core) /Users/pag/src/test/clj/stat/target/stat.js:12836 In this case, the value of m.PROT_READ should have been stat.core.m.PROT_READ. On the other hand, using . syntax fixes the scoping issue: |
[CLJS-475] Node.js target fails with optimizations set to :none or :whitespace Created: 21/Feb/13 Updated: 01/Mar/13 |
|
| Status: | Open |
| Project: | ClojureScript |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Paul Gearon | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Compiler, bug | ||
| Environment: |
Clojure 1.5.0-RC16 |
||
| Attachments: |
|
| Description |
|
Compiling a hello world program for Node.js works fine if using optimizations of :advanced or :simple, but if using :none or :whitespace then an error will be reported for either "goog undefined" or "goog.string" undefined respectively. The program is shown here: (ns pr.core) This program is in src/cljs/pr/core.cljs. The repl line used to compile is: When compiled with optimizations of :none, the output is: $ node src/js/pr.js /Users/pag/src/test/clj/pr/src/js/pr.js:1 — $ node src/js/pr.js /Users/pag/src/test/clj/pr/src/js/pr.js:493 — $ node src/js/pr.js — |
| Comments |
| Comment by Paul Gearon [ 21/Feb/13 4:40 PM ] |
|
Remaining generated files |
| Comment by David Nolen [ 25/Feb/13 3:46 PM ] |
|
This is a known bug. We need goog.require/provide to actually mean something to Node.js. I'm not sure how this can be made to work. I've been hoping for a patch for this since ClojureScript was first announced, but I haven't seen anything yet. |
[CLJS-100] binding breaks in macros Created: 11/Nov/11 Updated: 10/Jan/12 Resolved: 10/Jan/12 |
|
| Status: | Resolved |
| Project: | ClojureScript |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Major |
| Reporter: | Heinz N. Gies | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | Compiler | ||
| Environment: |
unimportant |
||
| Description |
|
When creating a macro that results in a binding the name of the global bound variables resolves into namespace bound names - this breaks the assert in clojurescripts let code. example (simplified): (ns clgl.core |
| Comments |
| Comment by David Nolen [ 20/Nov/11 1:18 PM ] |
|
I'm not sure I follow. What does gl and prog get namespaced to? |
| Comment by Jozef Wagner [ 09/Jan/12 2:46 PM ] |
|
I think he has a problem with *gl* clgl.macros/*gl* Solution is to use ~'*gl* *gl* So IMO this issue is not a CLJS defect and should be closed. |
| Comment by David Nolen [ 10/Jan/12 11:20 PM ] |
[CLJ-1184] Evaling #{do ...} or [do ...] is treated as the do special form Created: 16/Mar/13 Updated: 12/Apr/13 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.5 |
| Fix Version/s: | Release 1.6 |
| Type: | Defect | Priority: | Trivial |
| Reporter: | Jiří Maršík | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Compiler, bug | ||
| Approval: | Vetted |
| Description |
|
Evaluating a persistent collection for which the function 'first' returns the symbol 'do' leads to that collection being treated as the do special form, even though it may be a vector or even a set. IMHO, the expected result would be to report that 'do' cannot be resolved. For the cause, see the if condition on line 6604 of Compiler.java in clojure-1.5.1. E.g.: #{"hello" "goodbye" do} |
[CLJ-1136] Type hinting for array classes does not work in binding forms Created: 20/Dec/12 Updated: 21/Dec/12 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4, Release 1.5 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Major |
| Reporter: | Luke VanderHart | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Compiler, bug | ||
| Environment: |
replicated on OpenJDK 7u9 on Ubuntu 12.04, and Hotspot 1.6.0_37 on OSX Lion |
||
| Description |
|
Type hints don't work as expected in binding forms. The following form results in a reflection warning: (let [^{:tag (Class/forName "[Ljava.lang.Object;")} a (make-array Object 2)] However, hinting does appear to work correctly on vars: (def ^{:tag (Class/forName "[Ljava.lang.Object;")} a (make-array Object 2)) |
| Comments |
| Comment by Ghadi Shayban [ 20/Dec/12 10:51 PM ] |
|
It's a little more insidious than type hinting: the compiler doesn't evaluate metadata in the binding vec. This doesn't throw the necessary exception... (let [^{:foo (Class/forName "not real")} bar 42] neither this... (let [^{gyorgy ligeti} a 42] Gyorgy Ligeti never resolves. These two equivalent examples don't reflect: (let [a ^objects (make-array Object 2)] |
| Comment by Ghadi Shayban [ 21/Dec/12 11:09 AM ] |
|
On only the left-hand side of a local binding, metadata on a symbol is not analyzed or evaluated. |
[CLJ-1028] (compile) crashes with NullPointerException if public function 'load' is defined Created: 20/Jul/12 Updated: 20/Jul/12 Resolved: 20/Jul/12 |
|
| Status: | Closed |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Ben Kelly | Assignee: | Unassigned |
| Resolution: | Declined | Votes: | 0 |
| Labels: | Compiler, bug | ||
| Environment: |
Linux, OpenJDK 1.6.0 64bit |
||
| Attachments: |
|
| Description |
|
When performing AOT compilation, if the namespace being compiled or one of the namespaces :required by it defines a public function named 'load', the compiler will crash with a NullPointerException. The following code demonstrates this: (ns ca.ancilla.kessler.core (:gen-class)) (defn load [x] x) (defn -main [& args] 0) When run directly, with 'clojure -m ca.ancilla.kessler.core' or 'clojure ca/ancilla/kessler/core.clj', it runs as expected. When loaded with 'clojure -i' and (compile)d, however, or when automatically compiled by 'lein run', it results in a NullPointerException (the complete stack trace is attached). This occurs whether or not 'load' or actually called. It does not, however, occur if 'load' is private. |
| Comments |
| Comment by Ben Kelly [ 20/Jul/12 12:43 PM ] |
|
If you add (:refer-clojure :exclude [load]) to the (ns), it works fine: (ns ca.ancilla.kessler.core (:refer-clojure :exclude [load]) (:gen-class)) Thanks to llasram on IRC for discovering this. |
| Comment by Stuart Halloway [ 20/Jul/12 4:35 PM ] |
|
You should not replace functions in clojure.core. This is left legal (with a loud CONSOLE warning) for compatibility, but programs that do it are in error. |
| Comment by Ben Kelly [ 20/Jul/12 10:06 PM ] |
|
So, just to make sure that I have this right, then... If I want to create a namespace with a public function that shares a name with a function in clojure.core, the only supported way of doing this is to (:refer-clojure :exclude [list of all such functions])? If so, it would be nice if the warning were replaced with an error, rather than having the compiler emit an error and then crash. |
[CLJ-918] Vars with {:macro true} meta data do not work when loaded from AOT compiled file Created: 23/Jan/12 Updated: 13/Sep/12 Resolved: 13/Sep/12 |
|
| Status: | Closed |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Enhancement | Priority: | Trivial |
| Reporter: | Jannik Schorg | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | Compiler, enhancement, metadata | ||
| Environment: |
Tested with 1.3.0 and 1.4.0 |
||
| Patch: | New |
| Description |
|
When defining a var with ^{:macro true} the call of the binded macro does emit a warning when the definition has been AOT compiled. See example outputs with demo code here: https://refheap.com/paste/389 Bronsa on #clojure created a patch: http://sprunge.us/bWcc |
| Comments |
| Comment by Andy Fingerhut [ 13/Sep/12 2:29 PM ] |
|
Duplicate of CLJ-1021. Later ticket kept in preference to this one, because it has a patch and this one does not. |
[CLJ-874] defrecord factory inaccessibly from within type implementation Created: 11/Nov/11 Updated: 02/Dec/11 Resolved: 02/Dec/11 |
|
| Status: | Closed |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | Release 1.4 |
| Fix Version/s: | None |
| Type: | Defect | Priority: | Minor |
| Reporter: | Kurt Harriger | Assignee: | Unassigned |
| Resolution: | Completed | Votes: | 4 |
| Labels: | Compiler | ||
| Attachments: |
|
| Patch: | Code |
| Approval: | Ok |
| Description |
|
Discovered this issue working through https://github.com/relevance/labrepl when trying to use the new factory sytax for records: (defprotocol Player (defrecord Mean [last-winner] Notice that Mean returns a new instance with a different strategy. However, the factory methods are not defined until after the record has been created thus this results in a syntax error. To fix this I updated the macro to declare the factory methods before the record is emitted. |
| Comments |
| Comment by Kurt Harriger [ 11/Nov/11 11:33 AM ] |
|
On github: https://github.com/kurtharriger/clojure/tree/fix-defrecord |
| Comment by Kevin Downey [ 21/Nov/11 1:19 PM ] |
|
looks good to me |
| Comment by Aaron Bedra [ 26/Nov/11 11:58 AM ] |
|
Screened against e58a87fac72ed4b84a1d92f1e455b92d7ed3ef39 |
[CLJ-865] Macroexpansion discards &form metadata Created: 26/Oct/11 Updated: 06/Jun/12 |
|
| Status: | Open |
| Project: | Clojure |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Enhancement | Priority: | Major |
| Reporter: | Alan Malloy | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 7 |
| Labels: | Compiler | ||
| Attachments: |
|
| Patch: | Code and Test |
| Description |
|
As discussed in http://groups.google.com/group/clojure/browse_thread/thread/2690cb6ca0e8beb8 there is a "surprise factor" when type-hinting an expression that represents a macro, such as with (.length ^String (doto (identity "x") prn)). Here the doto macro discards the metadata on &form, causing a reflective lookup. This has the effect that while expressions representing function calls can be type-hinted, expressions representing macros in general cannot. The doto macro could be rewritten to respect its &form metadata, but doing this for every macro in existence would be tedious and error-prone. Instead, I propose a change to the compiler, to cause macroexpansion to hang onto the metadata automatically. The first patch attached adds a test for the behavior I propose: this test fails. After applying the second patch, the test passes. There are a couple points that merit further consideration before accepting my patch:
|
| Comments |
| Comment by Alan Malloy [ 28/Oct/11 1:12 AM ] |
|
So I went ahead and did the work of making this change in clojure.core/defmacro instead of clojure.lang.Compiler/macroexpand1. It was even worse than I expected: I didn't realize we don't yet have syntax-quote or apply at this stage in bootstrapping, so writing a non-trivial macroexpansion requires a huge amount of (list `foo (list `bar 'local-name)) and so forth. I'm sure the version I wrote is not optimal, but it seemed simpler to piggyback on defn, and then use alter-var-root to shim the metadata management in, than it would have been to expand to the correct thing in the first place. Anyway, attached patch #3 could be applied instead of #2 to resolve the issue in clojure.core instead of clojure.lang. The tests added in patch #1 pass either way. |
| Comment by Alan Malloy [ 13/Nov/11 8:29 PM ] |
|
I realized I can do this with a named private function instead of an anonymous function, reducing the amount of mess defmacro itself has to generate. Patch 4 is, I think, strictly better than Patch 3, if a Clojure implementation is preferred to one in Java. |
| Comment by Chouser [ 20/Nov/11 10:43 PM ] |
|
I prefer patch 0002 in Java over either 0003 or 0004. Patch 0002 keeps the knowledge of how to invoke macro fns (specifically the extra &form and &env args) in one place, macroexpand1 rather than duplicating that knowledge in core.clj as well. Note patch 0001 is just tests. The proposed default macroexpansion behavior is more useful than what we currently have, but there are two details I'd like to think about a bit more: 1) In exchange for a more useful default, macro writers lose the ability to consume their &form metadata and have control over the resulting form metadata without the &form metadata overridding it. That is, macros are no longer in complete control of their output form. 2) Rule (1) above has hardcoded exceptions for :line and :file, where &form metadata is unable to override the results returned by the macro. |
| Comment by Alan Malloy [ 01/Jun/12 2:04 PM ] |
|
This patch incorporates all previous patches to this issue. On the clj-dev mailing list, Andy Fingerhut suggested a new metadata key for allowing the macro author to specify "I've looked at their &form metadata, and this form is exactly what I want to expand to, please don't change the metadata any further." I've implemented this, and I think it addresses Chouser's concern about needing a way to "break out" of the improved-default behavior. One open question is, is :explicit-meta the right key to use? I spent some time tracking down a bug caused by my forgetting the keyword and using :explicit-metadata in my test; perhaps something more difficult to get confused by is available. |