Restore support for checking for UndefVarError variable name in at-test_throws #56231
Conversation
This file contains 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
testsystem
nickrobinson251
force-pushed
the
npr-testthrows-undefvarerr-var-match
branch
from
46b3997
to
3520ff8
Compare
giordano
pushed a commit
that referenced
this pull request
Oct 19, 2024
…st_throws (#56231) Fix #54082 Arguably this was a breaking change (as a consequence of #51979). But regardless, it seems like useful functionality to have a public API for testing that an `UndefVarError` was thrown for the expected variable name (regardless of scope). This is particularly useful if you don't know what the scope is (for example, in my use-case i want to test that a specific `UndefVarError` is thrown from a module with a `gensym`'d name). Pre-v1.11 the syntax for this was ```julia @test_throws UndefVarError(:x) foo() ``` but that stopped working in v1.11 when `UndefVarError` got a second field (in fact in v1.11.1 this is an error when before it would pass) This PR restores that functionality. We might want to backport it to v1.11.x so that v1.11 isn't the only version that doesn't support this. (cherry picked from commit b0c1525)
KristofferC
pushed a commit
that referenced
this pull request
Oct 21, 2024
…st_throws (#56231) Fix #54082 Arguably this was a breaking change (as a consequence of #51979). But regardless, it seems like useful functionality to have a public API for testing that an `UndefVarError` was thrown for the expected variable name (regardless of scope). This is particularly useful if you don't know what the scope is (for example, in my use-case i want to test that a specific `UndefVarError` is thrown from a module with a `gensym`'d name). Pre-v1.11 the syntax for this was ```julia @test_throws UndefVarError(:x) foo() ``` but that stopped working in v1.11 when `UndefVarError` got a second field (in fact in v1.11.1 this is an error when before it would pass) This PR restores that functionality. We might want to backport it to v1.11.x so that v1.11 isn't the only version that doesn't support this.
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.
Fix #54082
Arguably this was a breaking change (as a consequence of #51979). But regardless, it seems like useful functionality to have a public API for testing that an
UndefVarErrorwas thrown for the expected variable name (regardless of scope). This is particularly useful if you don't know what the scope is (for example, in my use-case i want to test that a specificUndefVarErroris thrown from a module with agensym'd name).Pre-v1.11 the syntax for this was
but that stopped working in v1.11 when
UndefVarErrorgot a second field (in fact in v1.11.1 this is an error when before it would pass)This PR restores that functionality.
We might want to backport it to v1.11.x so that v1.11 isn't the only version that doesn't support this.