Fix 3235

[kyay10]

fixes #3235. See that issue for more information

[nomisRev]

@kyay10 RaiseCancellationException is still referenced in the e.raisedOrRethrow. It's safe there because it's not inlined, and thus called from our module? 🤔

[kyay10]

Exactly. It's fine there, just not when inlined. In fact, the reason this wasn't caught earlier is because fold doesn't catch RaiseCancellationException, it catches CancellationException. traced is the only inline method that deals with RaiseCancellationException directly, and I think simply no one has really tried out traced outside of this repo, hence why no one ran into this before.

[serras]

This makes sense to me. One question, though, @kyay10: why this change and not making RaiseCancellationException @PublishedApi internal?

[kyay10]

@serras I just figured making it part of the API wasn't really needed. Making RaiseCancellationException published would work in the same way. Note, btw, that fold also simply catches CancellationException and relies on raisedOrRethrow to determine whether the exception belongs to the current raise, so this change matches fold more closely

[serras]

@kyay10 thanks for the info! I agree that it makes sense to mirror fold.