add backdate_admonition to depwarn=error #58266
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vtjnash
added
deprecation
53 tasks
I think a majority of our users don't know |
|
tests run with depwarn by default in Pkg |
Isn't that I think it would save users a lot of trouble if the warning took a short backtrace and reported the file + line number from the first frame |
Related: #48282 |
Keno
reviewed
Apr 29, 2025
| { | ||
| if (jl_options.depwarn == JL_OPTIONS_DEPWARN_ERROR) | ||
| jl_undefined_var_error(b->globalref->name, (jl_value_t*)b->globalref->mod); | ||
| jl_safe_printf( |
There was a problem hiding this comment.
Should maybe mention --depwarn=error in this warning so that people know how to turn it on
There was a problem hiding this comment.
Good point. I'll steal the message from Vararg{T} where T
This is close to the expected behavior after deprecations are removed (other than that the b->globalref->mod in the printed message here will be the source module instead of the destination module, which may sometimes cause confusing printing here, but probably rarely). Closes #57969
KristofferC
pushed a commit
that referenced
this pull request
May 5, 2025
This is close to the expected behavior after deprecations are removed (other than that the b->globalref->mod in the printed message here will be the source module instead of the destination module, which may sometimes cause confusing printing here, but probably rarely). I also needed this recently to find a place this warning occurred, so I think it should be merged now and get feedback later. Closes #57969 (cherry picked from commit 0682158)
charleskawczynski
pushed a commit
to charleskawczynski/julia
that referenced
this pull request
May 12, 2025
This is close to the expected behavior after deprecations are removed (other than that the b->globalref->mod in the printed message here will be the source module instead of the destination module, which may sometimes cause confusing printing here, but probably rarely). I also needed this recently to find a place this warning occurred, so I think it should be merged now and get feedback later. Closes JuliaLang#57969
Keno
added a commit
that referenced
this pull request
Jun 6, 2025
This makes two changes to the backdate-warning-turned-error (#58266): 1. Fix a bug where the error would only trigger the first time. We do only want to print once per process, but of course, we do want to error every time if enabled. 2. If we are in speculative execution context (generators and speculatively run functions during inference), always use the UndefVarError. Effects from these functions are not supposed to be observable, and it's very confusing if the printed warning goes away when depwarns are enabled. This is marginally more breaking, but the burden is on generated function authors (which already have to be world-age aware and are somewhat more regularly broken) and is consistent with other things that are stronger errors in pure context. Fixes #58648
Keno
added a commit
that referenced
this pull request
Jun 6, 2025
This makes two changes to the backdate-warning-turned-error (#58266): 1. Fix a bug where the error would only trigger the first time. We do only want to print once per process, but of course, we do want to error every time if enabled. 2. If we are in speculative execution context (generators and speculatively run functions during inference), always use the UndefVarError. Effects from these functions are not supposed to be observable, and it's very confusing if the printed warning goes away when depwarns are enabled. This is marginally more breaking, but the burden is on generated function authors (which already have to be world-age aware and are somewhat more regularly broken) and is consistent with other things that are stronger errors in pure context. Fixes #58648
Keno
added a commit
that referenced
this pull request
Jun 6, 2025
This makes two changes to the backdate-warning-turned-error (#58266): 1. Fix a bug where the error would only trigger the first time. We do only want to print once per process, but of course, we do want to error every time if enabled. 2. If we are in speculative execution context (generators and speculatively run functions during inference), always use the UndefVarError. Effects from these functions are not supposed to be observable, and it's very confusing if the printed warning goes away when depwarns are enabled. This is marginally more breaking, but the burden is on generated function authors (which already have to be world-age aware and are somewhat more regularly broken) and is consistent with other things that are stronger errors in pure context. Fixes #58648
KristofferC
pushed a commit
that referenced
this pull request
Jun 6, 2025
This makes two changes to the backdate-warning-turned-error (#58266): 1. Fix a bug where the error would only trigger the first time. We do only want to print once per process, but of course, we do want to error every time if enabled. 2. If we are in speculative execution context (generators and speculatively run functions during inference), always use the UndefVarError. Effects from these functions are not supposed to be observable, and it's very confusing if the printed warning goes away when depwarns are enabled. This is marginally more breaking, but the burden is on generated function authors (which already have to be world-age aware and are somewhat more regularly broken) and is consistent with other things that are stronger errors in pure context. Fixes #58648 (cherry picked from commit d2cc061)
nilesh646
pushed a commit
to nilesh646/julia
that referenced
this pull request
Jun 17, 2025
This makes two changes to the backdate-warning-turned-error (JuliaLang#58266): 1. Fix a bug where the error would only trigger the first time. We do only want to print once per process, but of course, we do want to error every time if enabled. 2. If we are in speculative execution context (generators and speculatively run functions during inference), always use the UndefVarError. Effects from these functions are not supposed to be observable, and it's very confusing if the printed warning goes away when depwarns are enabled. This is marginally more breaking, but the burden is on generated function authors (which already have to be world-age aware and are somewhat more regularly broken) and is consistent with other things that are stronger errors in pure context. Fixes JuliaLang#58648
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is close to the expected behavior after deprecations are removed (other than that the b->globalref->mod in the printed message here will be the source module instead of the destination module, which may sometimes cause confusing printing here, but probably rarely). I also needed this recently to find a place this warning occurred, so I think it should be merged now and get feedback later.
Closes #57969