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

Use jl_filename/jl_lineno less #53799

Merged
merged 1 commit into from
Mar 22, 2024
Merged

Use jl_filename/jl_lineno less #53799

merged 1 commit into from
Mar 22, 2024

Conversation

Keno
Copy link
Member

@Keno Keno commented Mar 21, 2024

I don't like jl_filename/jl_lineno. They are weird internal state, and they are also not thread safe, so if different threads are evaling different things at the same time, line numbers can get confused.

This PR changes the core function jl_toplevel_eval_flex to keep track of its current file/line context on the stack, so at least there is no confusion within one call to this function.

With this PR and #53797, the global jl_filename/jl_lineno are used for three purposes:

  1. To initialize the filename/lineno used by lowering from Core.eval.
  2. To give binding deprecation warnings.
  3. For jl_critical_error.
  4. By humans in the debugger.

I think 3 and 4 are fine, they are exceptional cases. Case 2, I think could be changed to plumb through locations explicitly,
but it's a bit annoying, so I didn't tackle it here.
Case 1, I think can probably just be changed to consistently initialize,
and if you want a proper line number, you need to put it in there explicitly.
However, I didn't change that in this PR, because I think it could be slightly
breaking, so should be pkgeval'd.

@gbaraldi
Copy link
Member

This seems to reduce the surface area quite a bit at least so LGTM

I don't like `jl_filename`/`jl_lineno`. They are weird internal state,
and they are also not thread safe, so if different threads are evaling
different things at the same time, line numbers can get confused.

This PR changes the core function `jl_toplevel_eval_flex` to keep track
of its current file/line context on the stack, so at least there is no
confusion within one call to this function.

With this PR and #53797, the global `jl_filename`/`jl_lineno` are used
for three purposes:

1. To initialize the filename/lineno used by lowering from `Core.eval`.
2. To give binding deprecation warnings.
3. For `jl_critical_error`.
4. By humans in the debugger.

I think 3 and 4 are fine, they are exceptional cases.
Case 2, I think could be changed to plumb through locations explicitly,
 but it's a bit annoying, so I didn't tackle it here.
Case 1, I think can probably just be changed to consistently initialize,
 and if you want a proper line number, you need to put it in there explicitly.
 However, I didn't change that in this PR, because I think it could be slightly
 breaking, so should be pkgeval'd.
@Keno Keno merged commit 9145571 into master Mar 22, 2024
5 of 7 checks passed
@Keno Keno deleted the kf/lesslocglobals branch March 22, 2024 09:37
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.

2 participants