Skip to content

Latest commit

 

History

History
191 lines (158 loc) · 11.8 KB

2020-01-16.md

File metadata and controls

191 lines (158 loc) · 11.8 KB

T-Lang Meeting: Current meeting

Migrating back from the hackmd

Watch the recording

Action items

Upcoming design meetings

  • Feb 3 — Specialization infomercial (presented by Niko)
  • Feb 10 — Ralf + UnsafeCell bugs (#55005, #68206)
  • Feb 17 — (Niko is unavailable)
  • Feb 24 — ffi-unwind working group (we’d like to start some pre-discussion)

One thing not covered here that I want to do:

  • Plan out meetings for all hands
    • I want to do this more rapidly anyway, let’s discuss async in #t-lang a bit perhaps

Shepherded item updates

inline assembly (Amanieu, Josh)

  • lots happening here, expect 1st RFC show up soon
    • RFC to create project group in FCP
    • deprecate existing ASM, move to LLVM ASM (RFC 2843) opened
    • Initial inline assembly RFC (RFC 2850) opened

safe transmute (Ryan, Josh)

  • no updates.

const evaluation (ecstatic-morse)

ffi-unwind (BatmanAod)

  • held a big meeting and tried to go back over everything, notes here
  • narrowed mostly down to 2 options
  • BatmanAod to post an explainer giving general background (which we all likely know)
  • Plan is to convert those unruly notes above into something more understandable and post it
    • hope to have some async conversation before
  • Only date when Amanieu, acfolzer, Niko, + Kyle were available was Feb 24, so scheduled design meeting for then

"dyn Trait" stuff (nikomatsakis)

grammar (qmx)

  • no update

**never_type** (**!**) stabilization (nikomatsakis)

  • llogic and I had a pair programming session and started mocking up the lint
  • feeling reasonably confident we’ll have a nice solution

Shepherding proposals

None this week

Triage

P-high issues

Nominated PRs

  • permit negative impls for non-auto traits #68004
  • Selectively disable sanitizer instrumentation #68164
    • We have had unstable support for sanitizer for some time, tracking issue #39699, implemented in #38699
    • No RFC or other formal procedure
    • This PR adds a (feature-gated, natch) attribute #[no_sanitize] that can be used to exclude a function from sanitizer
    • Question for the moment:
      • Should we encourage an RFC? What procedure do we want here, if any?
    • Resolved (Felix to comment):
      • We do not want this to generate errors, would prefer that it silently disables inline and perhaps issues a lint
      • Would like to see documenting in the unstable guide
      • Bikeshed: #[sanitize(never)] instead?
      • Not requiring an RFC at this time but it might be worth thinking about one that
  • Correct inference of primitive operand type behind binary operation #68129
    • Currently our type-checker has some specialized logic for a + b and other such operands:
      • We first create a trait obligation to prove A: Add<B, Output = R>
      • But we also hard-code some expectations — in particular, if the input types are both known to be builtin types, then we can require that A = B = R
        • this basically hard-codes the patterns of the impls
        • in ways that the trait solver doesn’t presently figure out on its own
        • needed for stuff like let x: usize = 2 + 4, since it forces 2 and 4 to be usize instead of letting them fallback to i32 as we would otherwise do
      • This PR extends those expectations to also work for arguments of types like &{integral} and not just {integral}
        • let x: usize = &22 + &44
        • What happens if you write let x: usize = 22 + &44?
        • What happens if you write let x: &usize = 22 + 44?
        • let a = 22; let x: usize = a + 44;
      • Resolved: (Niko)
        • FCP to merge
        • Extend with this test (a) and also add tests for other binary operator categories and cases where the expected type is not provided
  • Stabilize #[repr(transparent)] on enums in Rust 1.42.0 #68122
    • Check your boxes?

Nominated issues

  • Mutex and RwLock are unsound in presence of discriminant elision #68206
    • Also discussed in zulip
    • &Option<Mutex<bool>>
    • Not a problem for e.g. Option<Cell<&T>>
      • (but both above cases end up boiling down to something like Option<UnsafeCell<T>>, and whether niches within T are allowed to be exposed to the Option’s discrimant.)
    • In some sense, UnsafeCell imparting “only” shared-mutability (and hence orthogonal to niches) is clean and orthogonal but not in a deep way, and it creates other problems in the formal semantics (as Ralf noted)
    • Maybe we want some sort of “generic” way to make things opaque to niches?
      • #[repr(no_niche)]?
      • union has this effect (single-variant), but it imposes other limitations
    • niko: at surface, problems here resemble ones with &UnsafeCell<T> and dereferenceability. It seems like the key has to do with threading, though it’s worth noting that RefCell (which is not send or sync) also has to be careful in the same way: let x = opt_refcell.borrow_mut(); let x: &mut = x; rayon::fork(|| use(x), || inspect(refcell));
    • Key Ralf comment (link?) indicates that UnsafeCell propagating niches makes things really complicated, and it’s hard to identify what the “one thing” that UnsafeCell does would be
    • We called it #[repr(transparent)], does that have implications for niches, is this backtracking on that promise?
      • (Zulip discussion has some links)
      • Option<Cell<bool>> is considered FFI safe but it would now change size
        • and it would also no longer be considered FFI safe
      • Still, this is a soundness fix.
    • Resolved: (Niko)
      • We are going to make UnsafeCell inhibit niches.
  • Pattern errors are too imprecise and should be removed in favor of MIR borrowck #45600
    • Should we allow e.g.? struct Foo(String, String); fn x(f: Foo) { match f { Foo(a, ref b) => {} } }
    • Resolved: (Centril to comment)
      • Yes! We should! We need to make more tests.
        • It should remain an error to move fields out of a type that has Drop logic.
      • Centril will make PR, r? @matthewjasper
  • Pin is unsound due to transitive effects of CoerceUnsized #68015
    • split off from the other Pin issue
  • Pin` is unsound due to rogue Deref/DerefMut implementations #66544
    • see above
  • Arc::drop has a (potentially) dangling shared ref #55005
    • meeting planned for Feb 10
  • floating point to integer casts can cause undefined behaviour #10184
    • last time we talked, we concluded that it made sense to
      • adopt saturated semantics as the default
      • maybe offer a -Z flag to opt out for a time
      • there has been plenty of discussion in the meantime
      • how do we go forward here?
        • a summary might be an amazing contribution --niko
    • Centril will leave comment asking for a summary of:
      • recommended option from the POV of the summary maker and why :)
      • what options have been evaluated and what were the results
      • what options exist that have not been evaluated and what are the pros/cons
      • Not done yet.

Nominated RFCs

rfcbot pending list

rfcbot pending list