Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LineNumber nodes in :toplevel expressions are ignored #28990

Closed
stevengj opened this issue Aug 31, 2018 · 1 comment · Fixed by #30641
Closed

LineNumber nodes in :toplevel expressions are ignored #28990

stevengj opened this issue Aug 31, 2018 · 1 comment · Fixed by #30641
Assignees

Comments

@stevengj
Copy link
Member

LineNumber nodes can be used to add line numbers to a :block expression, but are ignored in :toplevel expressions:

julia> eval(Expr(:block, LineNumberNode(4, :foo), :(error("blah"))))
ERROR: blah
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] top-level scope at foo:4                   #### ⟵ DESIRED LINE NUMBER
 [3] eval at ./boot.jl:319 [inlined]
 [4] eval(::Expr) at ./client.jl:399
 [5] top-level scope at none:0

julia> eval(Expr(:toplevel, LineNumberNode(4, :foo), :(error("blah"))))
ERROR: blah
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] top-level scope at none:0                   ### ⟵ MISSING LINE NUMBER
 [3] eval at ./boot.jl:319 [inlined]
 [4] eval(::Expr) at ./client.jl:399
 [5] top-level scope at none:0

This seems like it makes it unnecessarily hard to add a line number when evaluating an arbitrary expression, because you can't put toplevel-only expressions (e.g. module or struct) inside :block expressions.

(This came up in addressing JuliaLang/SoftGlobalScope.jl#3.)

@JeffBezanson
Copy link
Member

At the same time I notice [5] top-level scope at none:0, which is also wrong. This is a very long-standing bug; it should say [5] top-level scope at REPL[n]:1. I'll fix that too.

JeffBezanson added a commit that referenced this issue Jan 7, 2019
This gives better location info inside `:toplevel` expressions and
for REPL inputs that aren't block constructs.
The low-level parser entry points are simplified and renamed to parse-one,
parse-all, and parse-file.
JeffBezanson added a commit that referenced this issue Jan 8, 2019
This gives better location info inside `:toplevel` expressions and
for REPL inputs that aren't block constructs.
The low-level parser entry points are simplified and renamed to parse-one,
parse-all, and parse-file.
JeffBezanson added a commit that referenced this issue Jan 8, 2019
This gives better location info inside `:toplevel` expressions and
for REPL inputs that aren't block constructs.
The low-level parser entry points are simplified and renamed to parse-one,
parse-all, and parse-file.
JeffBezanson added a commit that referenced this issue Jan 8, 2019
This gives better location info inside `:toplevel` expressions and
for REPL inputs that aren't block constructs.
The low-level parser entry points are simplified and renamed to parse-one,
parse-all, and parse-file.
JeffBezanson added a commit that referenced this issue Jan 9, 2019
This gives better location info inside `:toplevel` expressions and
for REPL inputs that aren't block constructs.
The low-level parser entry points are simplified and renamed to parse-one,
parse-all, and parse-file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants