Skip to content

Latest commit

 

History

History
257 lines (170 loc) · 10.8 KB

2019-12-19.md

File metadata and controls

257 lines (170 loc) · 10.8 KB

Lang Team Triage Meeting Minutes

Watch recording

Action items

  • propose case-by-case uplift for clippy lints (scottmcm) & cancel FCP

  • niko to post summary comment on turbofish RFC and postpone

  • niko to comment on Expr walking structural match (reopened) #67088

  • niko to pursue scheduling design meeting around Pin and trying to gather up constraints -- found only one slot that may work, pinged folks

  • niko to comment on RFC 2632 about "ok to experiment on nightly"

Design meeting topics

Urgent-ish

  • ffi-unwind and the "C" ABI (proposed)

  • dyn Trait + coherence interaction #57893

  • stacked borrows overview + &self in AtomicUsize + maybe the embedded interactions (proposed)

  • Pin and rogue DerefMut impls #66544 (proposed)

Speculative

  • roadmap + next edition (proposed)

    • see also this list which only Niko filled out :)

  • unsafe code and &raw in next edition (proposed)

Shepherded item updates

inline assembly (Amanieu, Josh)

  • no update

safe transmute (Ryan, Josh)

const evaluation (ecstatic-morse)

  • &mut ref types and borrows are on nightly but no RFC -- need one?
    • Let's have an RFC.
  • We should think more about our story for recursion limits?
    • could lift the standard recursion limit for now
    • but what about loop { .. }
      • currently: we have a step counter that overflows at some point (counts terminators)
      • tied to an unstable attribute right now
  • Erroneous constants & what counts as dead code? (see discussion below).

ffi-unwind (BatmanAod)

  • no update -- planning to have the dedicated meeting still

"dyn Trait" stuff (nikomatsakis)

grammar (qmx)

  • no update

never_type (!) stabilization (nikomatsakis)

  • no update

Shepherding proposals

None this week

Triage

P-high issues

let _: ! = panic!(); // obviously ok, but errors at runtime
const FOO2: u8 = panic!();
fn main() {
    let _ = FOO2; // gets an error today
    ...
}
const FOO: ! = panic!();
fn main() {
    let _ = FOO; // was not getting errors
                 // had miscompilations for uninhabited types
    ...
}
fn main() {
    panic!();
    BAD_CONSTANT; // <-- no error (dead according to NLL)
}

Conclusion:

  • uses of constants that are unreachable (according to NLL) would not trigger errors, even if the constant encounters an error during evaluation

    • because backwards compatibility (and because using one notion of reachability is nice...)

  • in particular, NLL's notion of reachability is not dependent on optimizations nor particular values (e.g., X is reachable in if false { X }) and contains various "false edges" in match building and so forth

  • Pin is unsound due to rogue Deref/DerefMut implementations rust-lang/rust#66544

    • Proposal: schedule a meeting to discuss in detail
      • Niko will reach out to Ralf & Boats.
      • Ideally they attend the meeting.

  • Coherence can be bypassed by an indirect impl for a trait object

    • (see above)

Nominated PRs

  • Expr walking structural match (reopened) #67088

  • mem::zeroed/uninit: panic on types that do not permit zero-initialization #66059

    • Not complete implementation yet, OK in dynamic semantics?

    • Crater triage?

    • Ralf responded to recent comments:

      • This is a minimal step

      • Overall goal is that we panic on all illegal uses of mem::uninitialized and mem::zeroed that we can detect

      • The question is how fast we can land this without breaking everything

      • Centril thinks it would be good to have the full plan as "prose" and FCP that one so we don't have to re-FCP every step.

    • Connected to the safe-transmute

      • since anything that can be initialized from arbitrary bits surely permits zero
      • long term if we had a "trait" that indicated something could be zero-initialized, perhaps with opt-in (e.g., deriving), we could leverage it for safe-transmute etc
        • i.e., compiler could ensure that implementing the trait is valid
        • This is related to the compiler figuring out whether traits regarding safe-transmute are valid

    • Proposal: this is alright in dynamic semantics for now, we'd like to see this happen via static semantics and the type system eventually too, please coordinate that with project-safe-transmute

    • Considerations:

      • would we leave room to remove panics in the future, if we relax the validity invariants for zeroing
      • would be good to decide the "mission" of "panic if zero'd"
        • taking inspiration of MaybeUninit and mem::uninitialized
      • and have some up-to-date place to look for what types do what and where
        • "we think this should panic, it doesn't yet"
        • etc

  • Add a raw "address of" operator #64588

Nominated issues

Nominated RFCs

rfcbot pending list

Future meeting proposals

  • dereference with ralfjung / compiler’s llvm-wg / ucg wg?