-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[WIP] SILGen: Don't inject "willThrow" hooks before rethrow propagation branches. #13585
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
Conversation
@swift-ci Please test |
@adrian-prantl @jasonmolenda Do you recall whether it was intentional that we emitted |
Build failed |
I'm afraid I don't know anything about this. Was the commit history helpful at all? |
Build failed |
…nches. The hook is intended to be used by debuggers to catch the point a `throw` happened in user source. It's unnecessary and undesirable to hook in places where an already-thrown error is just being implicitly propagated.
9207930
to
c3a2d98
Compare
@swift-ci Please test |
Build failed |
Build failed |
Yes, I think this is reasonable. You could make an argument that we should call willThrow before starting the propagation of an error received from ObjC, just so that such throws do always get trapped. However, that would still sweep up a fair amount of propagation-rethrows and expose the details of exactly how we performed a call. I think the "it's only triggered by Swift throw statements" line is something that users will understand. |
ObjC-to-Swift propagation has its own code paths, so we could conceivably still emit the hook when propagating in that situation. |
I discussed this a bit with @jimingham on swift-lldb-dev. We should keep the |
@jckarter Do you think this would make for a good starter bug in IRGen? |
Yeah, that's a good idea! |
Filed https://bugs.swift.org/browse/SR-11803. Please let me know if I'm missing any details in there. Going to close this out. |
The hook is intended to be used by debuggers to catch the point a
throw
happened in user source. It's unnecessary and undesirable to hook in places where an already-thrown error is just being implicitly propagated.