-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
No load error on at macroexpand #37857
Conversation
Also worth noting that it's my understanding that errors can be changed for minor versions |
Bump? |
1 similar comment
Bump? |
Bump?? |
I agree. Rebase this and we can merge it. |
I agree with removing However, note that this will break package tests spuriously because packages commonly test their macros with code like @test_throws LoadError macroexpand(some_module, :(some_ex)) In my earlier effort to remove |
@c42f oh I didn't realize there was previous work on this. Do you think it's worth it to try to do a deprecation? Any comments on whether the previous implementation was better/worse? (I barely knew enough C to do this PR). |
A few thoughts:
For this PR, I think it's very worth taking the relevant code from the first commit of #31882 (see 3ee9d8f). Especially the changes to the Base tests and to the |
Ok, I've included the deprecation and rebased as #38379 |
There's three reasons I think this would be a good idea:
Semantic: code that is macroexpanded is not loaded, at least, it's certainly not evaluated.
Not particularly useful: load errors contain a line number and module, but that's not particularly helpful for macroexpand, which is usually used interactively
Convenience: not having to unwrap loaderrors to test macros is more convenient. I think a strong case for this can be made just by looking at the tests I've changed that no longer need to do this.