Skip to content

Latest commit

 

History

History
125 lines (84 loc) · 5.16 KB

October-2ndHalf.md

File metadata and controls

125 lines (84 loc) · 5.16 KB

catch_unwind and foreign exceptions

Zulip

(TODO: add this to "resolved concerns")

gnzlbg: "we kind of need to be able to do this"; link to Rust bug about ForceUnwind

acfoltzer & Amanieu: should never catch foreign exceptions

acfoltzer: "major red flags...constrain Rust panic mechanism"

JoshT: not "the original problem the working group set out to solve"

Conclusion: leave undefined (not TBD) for now; also, gnzlbg's issue was addressed by a PR by Amanieu (see below)

Unspecified behavior compile error

Zulip

Code that does not compile is by definition not exhibiting "unspecified behavior."

However, code may have unspecified on some platforms but fail to compile on others (though it may compile in the future).

Amanieu PR for foreign exceptions

Amanieu wrote a PR to ensure that foreign exceptions can propagate through Rust frames:

  • Drop code will be executed as the exception unwinds through the stack, as with a Rust panic.
  • catch_unwind will not catch the exception, instead the exception will silently continue unwinding past it.

"native" vs "foreign"

Zulip

Kyle S: only use "native" to refer to exception mechanism; use "foreign" when referring to non-Rust frames

letting extern "C" unwind

Zulip

Shared HackMD write-up

Amanieu provided a detailed analysis of the behavior of cross-language unwinding in various circumstances.

We believe that there is no undefined behavior at the LLVM level even without -fexceptions, though we need to confirm w/ LLVM owners that it is not automatically UB to unwind through C code compiled without -fexceptions

Concern about pthread_exit

Centril objects:

  • possible breaking changes
  • de-facto constraint on panic implementation
  • all implementation-defined behavior is, in practice, "defined for the whole language" since we only have one implementation
  • Need relevant LLVM guarantees to be stated in LangRef

Josh T: unwind by default sounds reasonable

Kyle: Let's proceed w/ extern "C unwind"; nothing prevents us from landing extern "C unwind" and then later making extern "C" behave the same way, unless we make the abort-on-unwind behavior "well defined" (and therefore stable forever, at least until the next edition)

Noexcept-like feature

Zulip

gnzlbg: attribute is a bigger lang change than new ABI would be

Amanieu: not sure noexcept would be as useful in Rust as in C++

Kyle: I think noexcept probably falls under project group scope, but it is not a high priority and doesn't block other work

Participant status updates

Is this section useful?

  • acfoltzer: really busy through mid-November
  • Alex Crichton: not caught up on threads but open to being pinged for questions
  • Niko: active in conversations, etc but not entirely caught up on channels
  • Amanieu: didn't know about project group before, but participating now

Kyle propsoed action items

Zulip

"more or less in parallel"

  • RFC for announcing project group (no lang changes proposed)
  • continue to design extern "C unwind"
  • stabilize the abort-on-unwind-through-extern "C" logic
  • possibly, design some explicit opt-in syntax for the abort-on-unwind feature

Misc