ClojureScript

Wrong line number reported when warning about undeclared Var

Details

  • Type: Defect Defect
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows 7 Home Premium 64 bit, Leiningen 2.1.2 on Java 1.7.0_05 Java HotSpot(TM) 64-Bit Server VM

Description

While using cljsbuild v.3.2 or v.3.3, and cljs v1859, an undeclared
Var error will report the error at the wrong line number (i.e. 11
instead of 6):

(ns example.hello)

(defn foo [a b]
(* a b))

(fooo 2 3)

A cljsbuild "clean" executes normally, but an "auto" yields an error:

C:\Users\Greg\simple - test>lein cljsbuild auto
Compiling ClojureScript.
Compiling "resources/public/js/main.js" from ["src-cljs"]...
WARNING: Use of undeclared Var example.hello/fooo at line 11 src-cljs\example\hello.cljs
←[32mSuccessfully compiled "resources/public/js/main.js" in 15.988207202 seconds.←[0m

When I deliberately create other undeclared Var
errors further down in the file, the line number discrepancies become
even larger.

I changed ClojureScript dependencies to isolate the problem. The wrong
line number errors seem to begin with cljs v0.0-1853. v1847 seems to work correctly. Minimal reproducing case
follows in the attachments.

  1. hello.cljs
    05/Oct/13 8:52 PM
    0.1 kB
    Greg Wanish
  2. project.clj
    05/Oct/13 8:52 PM
    0.6 kB
    Greg Wanish

Activity

Hide
David Nolen added a comment -

I've released ClojureScript 0.0-1933

Show
David Nolen added a comment - I've released ClojureScript 0.0-1933
Hide
Nicola Mometto added a comment -

Greg, there was an issue in the tools.reader version that clojurescript uses that caused wrong column info when reading \r\n, I've fixed it and released a new version.

Once it hits maven David will cut a new clojurescript release using the new tools.reader that will fix this issue.

Sorry for the inconvenience

Show
Nicola Mometto added a comment - Greg, there was an issue in the tools.reader version that clojurescript uses that caused wrong column info when reading \r\n, I've fixed it and released a new version. Once it hits maven David will cut a new clojurescript release using the new tools.reader that will fix this issue. Sorry for the inconvenience
Hide
Greg Wanish added a comment -

I am able to reproduce this issue when I recreate the test file from scratch using Light Table and Notepad++.

Show
Greg Wanish added a comment - I am able to reproduce this issue when I recreate the test file from scratch using Light Table and Notepad++.
Hide
Greg Wanish added a comment - - edited

This problem started while I was using Light Table. I read some time ago that LT uses Code Mirror as its editor. Do you know of any encoding issues with Code Mirror? What kind of encoding does tools.reader expect?

Show
Greg Wanish added a comment - - edited This problem started while I was using Light Table. I read some time ago that LT uses Code Mirror as its editor. Do you know of any encoding issues with Code Mirror? What kind of encoding does tools.reader expect?
Hide
David Nolen added a comment -

I am able to recreate the issue with the provided file. However if I make a file from scratch I am unable to reproduce. Perhaps this is encoding problem and tools.reader is reporting the wrong line number as a result?

Show
David Nolen added a comment - I am able to recreate the issue with the provided file. However if I make a file from scratch I am unable to reproduce. Perhaps this is encoding problem and tools.reader is reporting the wrong line number as a result?
Hide
Greg Wanish added a comment -

The first commit, 9f010ff...:

https://github.com/clojure/clojurescript/commit/9f010ff5d4a122b0f1dc93905647f309cc45c699

coming after 1847 reports the wrong line number.

Show
Greg Wanish added a comment - The first commit, 9f010ff...: https://github.com/clojure/clojurescript/commit/9f010ff5d4a122b0f1dc93905647f309cc45c699 coming after 1847 reports the wrong line number.
Hide
David Nolen added a comment -

If you have time to isolate the commit where things went wrong that would be extremely helpful. Thanks!

Show
David Nolen added a comment - If you have time to isolate the commit where things went wrong that would be extremely helpful. Thanks!
Hide
Greg Wanish added a comment -

I did try with 1913, same problem.

Show
Greg Wanish added a comment - I did try with 1913, same problem.
Hide
David Nolen added a comment -

Have tried testing this with a more recent release like 1913?

Show
David Nolen added a comment - Have tried testing this with a more recent release like 1913?

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: