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

RFC: Implement @__LINE__ macro #12727

Merged
merged 1 commit into from
Aug 28, 2015
Merged

Conversation

ihnorton
Copy link
Member

(upated) Implements __LINE__ and __FILE__ magic macros returning the line number (integer) and filename (as string) for a given call location.

Fixes #8066

This is what happens when you force the riff-raff to learn a little scheme.

@ihnorton
Copy link
Member Author

Alternatively, could use the same pattern just for __LINE__ (and also for __FILE__ to make the implementation a little bit more robust?)

@timholy
Copy link
Member

timholy commented Aug 21, 2015

This is what happens when you force the riff-raff to learn a little scheme.

Quote of the week!

@ScottPJones
Copy link
Contributor

👏👏👏! 👍

@StefanKarpinski
Copy link
Member

Nice. Probably needs a once over by @JeffBezanson

@JeffBezanson
Copy link
Member

A LineNumberNode used as data should probably be wrapped in quote, since bits of the compiler might assume that LineNumberNodes don't execute, or can always be removed safely.

Wouldn't it be simpler just to replace @__LINE__ with the result of input-port-line at parse time?

@ihnorton ihnorton changed the title RFC: Implement @__LOCATION__ magic macro RFC: Implement @__LINE__ and @__FILE__ macros Aug 21, 2015
@ihnorton
Copy link
Member Author

That is much nicer. Updated to do so for both @__LINE__ and @__FILE__.

(I'm not sure how to document these now -- writing doc strings lead to a "Invalid doc expression" during sysimg build. Removed for now, will open a separate issue if I can't figure it out)

(if (ts:space? s)
(cond
((eqv? head '__LINE__) (input-port-line (ts:port s)))
((eqv? head '__FILE__) `(call string (quote ,current-filename)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could just be a constant string, (string current-filename).

@JeffBezanson
Copy link
Member

I'm not 100% sure how to make this doc-able either. Maybe we should parse @__LINE__ as (macrocall @__LINE__ 42). Then we could define it as an identity macro and document it there.

@mbauman
Copy link
Member

mbauman commented Aug 21, 2015

This is awesome. You could document them as keywords, which are checked first:

julia> Base.Docs.keywords[symbol("@__FILE__")] = "filedoc"
"filedoc"

help?> @__FILE__
search: @__FILE__

"filedoc"

@ihnorton
Copy link
Member Author

Perfect, thanks @mbauman. Updated.

Implementing @__FILE__ this way changes the result when used in include_string(..., fake_filename) ... It seems unlikely that anyone relies on this behavior, but I will revert that change if there are any objections.

@JeffBezanson
Copy link
Member

A filename gets passed through from include_string to jl-parse-string-stream, so I think it's possible to still get the right filename. Is that not happening?

@stevengj
Copy link
Member

@ihnorton, I think IJulia relies on the @__FILE__ behavior for include_string(..., fake_filename), where fake_filename is e.g. "In[23]", in order to get useful backtraces etc.

thefname = "the fname!//\\&\1*"
# passing a second argument to include_string should be reflected by @__FILE__
@test include_string("test_atsign_file() = @__FILE__", thefname)() == thefname
@test include_string("test_atsign_file() = @__FILE__")() == "string"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No test for @__LINE__?

@ihnorton
Copy link
Member Author

Sorry, I misunderstood what was going on with the test failure. This does not change the behavior of include_string at all, but rather of @__FILE__. include_string(..., filename) still works fine. The change is that now @__FILE__ actually reflects the filename that the parser sees (such as the argument to include_string). This feels arguably more accurate.

with /tmp/foo.jl as:

println(include_string("@__FILE__", "foo"))
println(Base.source_path())

on master the out of julia /tmp/foo.jl is:

/tmp/foo.jl
/tmp/foo.jl

on this branch:

foo
/tmp/foo.jl

There are only two packages that use include_string -- IJulia and Jewel -- and their usage should still work fine. On the other hand, a large number of packages use @__FILE__. I don't know of any other code path whereby @__FILE__ would not equal Base.source_path, but it is possible that this change could break some code.

@ihnorton ihnorton changed the title RFC: Implement @__LINE__ and @__FILE__ macros RFC: Implement @__LINE__ macro Aug 27, 2015
@ihnorton
Copy link
Member Author

I removed the @__FILE__ change for now. Will merge soon if there are no objections.

@ihnorton
Copy link
Member Author

... or not, I guess. Just saw the feature freeze announcement.

@__FILE__() -> AbstractString

`@__FILE__` expands to a string with the absolute path and file name of the script being run. Returns `nothing` if run from a REPL or an empty string if evaluated by `julia -e <expr>`.
`@__FILE__` expands to a string with the absolute path and file name of the script being run.
Returns `"none"` if run from a REPL or command-line context.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did this actually change from nothing to "none" here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ihnorton can you confirm? Just tried it and this looks wrong.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that was left from the proposed change. I'll fix the doc.
On Aug 28, 2015 7:35 PM, "Tony Kelman" [email protected] wrote:

In base/docs/helpdb.jl
#12727 (comment):

 @__FILE__() -> AbstractString

-@__FILE__ expands to a string with the absolute path and file name of the script being run. Returns nothing if run from a REPL or an empty string if evaluated by julia -e <expr>.
+@__FILE__ expands to a string with the absolute path and file name of the script being run.
+Returns "none" if run from a REPL or command-line context.

@ihnorton https://github.com/ihnorton can you confirm? Just tried it
and this looks wrong.


Reply to this email directly or view it on GitHub
https://github.com/JuliaLang/julia/pull/12727/files#r38254310.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

8fb7046 (on the docfix branch)

StefanKarpinski added a commit that referenced this pull request Aug 28, 2015
RFC: Implement @__LINE__ macro
@StefanKarpinski StefanKarpinski merged commit a4c2916 into JuliaLang:master Aug 28, 2015
@StefanKarpinski
Copy link
Member

Let's just pretend this got merged before that announcement.

ihnorton added a commit that referenced this pull request Aug 29, 2015
ihnorton added a commit that referenced this pull request Aug 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants