2019-09-26.md

T-Lang Meeting: 2019.09.26

• Recording available

Shepherded items

• RFC 2753 — unwind/ffi interaction
  • added as main topic
• #57893 — Coherence can be bypassed by an indirect impl for a trait object @Nicholas M
  • update: blitzerr is working on it, latest update is “making progress”
• #63599 — Stabilize RFC 2451, re-rebalance coherence @Nicholas M
  • waiting on a PR to land
  • plan to make a spreadsheet to view the existing tests and look for gaps
• #44109 — Tracking issue for RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute @Mazdak F
  • update: in FCP
  • one question that arose: interaction with #[repr(C)] and non-exhaustive attribute
    • observation: non-exhaustive attribute is a sign you will add more fields, changing the size of the struct, so passing it by-value to a C function is asking for trouble
  • Should #[non_exhaustive] #[repr(C)] struct Foo; lint wrt. improper_ctypes outside but not inside the current crate?
    • We seemed fine with this.
    • i.e., int triggers on an extern "``C``" fn defined outside of the current crate that references Foo
    • (When passed “by value”)

Triage

• Review last week’s action items
• S-blocked-on-team issues
• Beta nominations
• P-high issues
  • #57893 — Coherence can be bypassed by an indirect impl for a trait object
    • No updates from last week.
• Nominated PRs
  • #64694 — [WIP] Fully integrate derive helpers into name resolution
    • Want RFC? Interactions with other things possibly?
  • #64675 — Deprecate #![plugin] & #[plugin_registrar] with removal deadline: 1.44.0
    • Emit a “firmly worded warning” — perhaps a lint.
    • Not obviously “lang”, at present it’s an unstable rustc hack basically.
    • Actively work to remove this dependency? No, far out of our scope, would take careful design.
    • Recommendation: add a warning, but track through compiler team
  • #64035 — Stabilize proc macros generating macro_rules items
    • Comment request
    • “As a result, the feature is de-facto stable and is actively relied upon by the ecosystem, at least through the proc_macro_hack crate.”
  • #62262 — Extend #[must_use] to nested structures
    • boats to comment, but a lot of these cases are not bugs — e.g., core futures combinators
    • we already did add support for tuples
    • people can no longer put a Result in their struct as part of its internal operations; current setting is that people must mark the type #[must_use] if they want it to propagate
      • this is a “breaking change” in spirit, if not in fact, because the right thing to do has changed — it’s sufficiently disruptive that it probably merits an RFC
        • analogous to dyn, if changing conventions sufficiently, requires RFC
      • maybe we want it for generics or something? is there some more limited form that would have fewer false positives?
        • Specifically, if the type concretely has a must-use type, then the correct answer might just be that the person should have put the attribute on it if they wanted the behaviour. So maybe this would make sense if the internal must_use type came from a generic, for example.
      • visibility is also relevant (e.g., pub fields are different from private fields)
        • Once something is POD-like, it makes more sense for it to behave like tuples do, which recently got the propegate-must-use behaviour
• Nominated issues
  • #64633 — How to handle reservation impls in rustdoc / error messages
    • proposal is to show the impl and leave some comments
  • #63197 — Incorrect undefined behaviour on static references created from pointers?
    • blocked on Ralf and/or niko organizing the meeting
  • #53639 — Consider deprecation of UB-happy static mut
    • blocked on Ralf
  • #44109 — Tracking issue for RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute
• Nominated RFCs
  • WIP: "C panic" ABI specifier
  • Calling methods on generic parameters of const fns
  • Make the turbofish syntax redundant
• Unassigned RFCs

Main topic: RFC 2753

extern “C unwind” notes

• Target case
  • unwinding over FFI integration
• Example use cases
  • Rust panics, traverses native frames w/o destructors, panic caught in a Rust frame
• Main design question at hand
  • extern “C unwind”
    • using “the native” unwinding mechanism, as defined by the target specification
      • DWARF on linux, SEH on msvc
  • extern “C panic”
    • using “the Rust” unwinding mechanism, which may or may not be equal to the target specification
    • any use case for this apart from “it’s easiest”?
      • only one is Rust loading other Rust code, but that’s really

• What exactly are we guaranteeing at this point?

• Possible future situations worth considering
  • What if a new unwinding mechanism should arise, where C++ compilers have not yet transitioned, or offer optional support, but we want to adopt it
    • We could change our default target uses, if we think we can get away with it
      • Equivalent to e.g. adopting newer instruction sets
    • Issue a new target that supports this mechanism and people can opt in
      • “rust unwind == native unwind” remains true all the time
      • “rust unwind == native unwind” not true, in which case on older target we require shims
• Interactions not addressed in RFC 2753
  • If native code raises an exception, and it traverses Rust stack frames, do destructors run?
  • If native code raises an exception, and it traverses Rust stack frames, do destructors run?
  • If native code raises an exception, does catch_panic intercept it?
  • If Rust code raises a panic, and it traverses native frames, what happens?
    • If there are destructors, do they run?
• Key question perhaps
  • Are the points above “undefined behavior” or “implementation defined”?
    • Today, it is definitely UB because of the nounwind attribute and attempts to insert the abort shim
    • Not clear what the real difference is. Perhaps it is that rustc would have to define (and potentially stabilize) that behavior.
    • Perhaps the difference is that we are avoiding LLVM UB — we won’t miscompile the code.
    • Analogy: Rust ABI
  • Idea:
    • spell out the kind of changes that we anticipate and which could happen
• Key desiderata and/or concerns
  • We shouldn’t constrain our future behavior, for example to adapt to changes in C and C++.
    • e.g., the proposal to alter our behavior to match new C++ proposals
• Concern:
  • Drop order between structs and enums
    • Difference: Behavior of exceptions that cross stack frames is pretty inconsistent across platforms
    • But we can expect that people will start to want better behavior
    • And it’s true that our freedom has been restricted by stabilizing the behavior
    • How would someone define on this?
• Proposal: WG, try to actually settle some of this behavior
  • define “scope” of the effort, perhaps in terms of use cases?
    • example: not stabilizing the Rust ABI, nor proposing to alter Rust’s panic mechanism
    • but yes thinking about what it would mean if it did change
  • get input from folks from UCG
• Consensus of meeting:
  • RFC should clarify questions that it intentionally does not answer and leaves for future work
  • Centralize rationale, clarify what “impl defined behavior” means, etc, complete “TODO” items
  • Spin out a WG with BatmanAOD and/or acfoltzer as “lang team shepherd” / Niko as liason
  • We are comfortable landing a syntactic change that doesn’t (yet) enable stable code that has fully defined behavior, as long as we have a plan to finish up the remaining pieces rather than leaving to “accidentally stable” behavior
    • extern “C unwind” — would we stabilize this behavior even before all pieces are in place?
      • centril: would like to see centralized rationale etc written out
      • adam/acfolzer: have laid out thoughts on thread, will try to move to RFC