You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know there has already been a lot of discussion on this, so my apologies for bringing it up again, but rust 2024 will change the original context this decision may have been made in.
Previously I raised #342 but then I found a workaround to disable anyhow backtrace capturing via:
if std::env::var("RUST_LIB_BACKTRACE").is_err(){
std::env::set_var("RUST_LIB_BACKTRACE","0");}
This resolved my issue and the issue was closed.
However, with rust 2024, set_var will be marked unsafe.
Many high level codebases have a blanket ban on unsafe, so even if set_var can be soundly called at the start of the application before any threads are created, there is no way to create a sound wrapper API for that as it could still be called after that point.
So this approach is not usable in codebases with a blanket ban on unsafe.
Does this alter the original assumptions around the decision to "not expose a way for the application to configure whether stacktraces are captured"?
If this changes nothing go ahead and close the issue.
The text was updated successfully, but these errors were encountered:
I know there has already been a lot of discussion on this, so my apologies for bringing it up again, but rust 2024 will change the original context this decision may have been made in.
Previously I raised #342 but then I found a workaround to disable anyhow backtrace capturing via:
This resolved my issue and the issue was closed.
However, with rust 2024, set_var will be marked unsafe.
Many high level codebases have a blanket ban on unsafe, so even if
set_var
can be soundly called at the start of the application before any threads are created, there is no way to create a sound wrapper API for that as it could still be called after that point.So this approach is not usable in codebases with a blanket ban on unsafe.
Does this alter the original assumptions around the decision to "not expose a way for the application to configure whether stacktraces are captured"?
If this changes nothing go ahead and close the issue.
The text was updated successfully, but these errors were encountered: