2019-11-14.md

2019.11.14

Video recording available

Shepherded items

• const evaluation (ecstatic-morse)
  • no updates this week
• RFC 2753 — unwind/ffi interaction — kyle/adam
  • current status: trying to get measurements of the impact of the FFI
• “dyn trait” stuff (Niko) — Coherence can be bypassed by an indirect impl for a trait object
  • did a crater run but have only partially analyzed the impact
• grammar working group — qmx
  • no updates this week
• ! type and fallback — centril
  • rust-lang/rust#65355

Triage

• Review last week’s action items
• S-blocked-on-team issues
• Beta nominations
• P-high issues

  • [x] improper_ctypes fires for &mut T, &T, *const T and *mut T (when T: Sized)

    • background:
      • changed improper ctypes lint so that it would fire more frequently
      • so that functions with extern "``C``" type (defined in Rust) would be checked too
        • in addition to imported foreign items (extern "``C``" { fn foo(); })
      • this uncovered a lot of false positives (unnecessary warnings)
        • specifically: if you have &Foo where Foo: Sized, that is well-defined (i.e., it will be a C pointer) but the lint complains about it
        • this was always the case but we are now analyzing more sources
        • so how should we proceed?
      • current status: PR reverted temporarily
    • insightful comment by rkruppe, the lint serves two purposes
      • some cases are “out and out UB”
      • other cases are more “avoiding footguns” — you can do this, but caution is required
        • e.g., passing a &Foo to a non-C struct Foo is ok, as long as you are careful not to deref on the C side or rely on the layout of the struct
      • another difference, we are now talking about data coming in to Rust code (vs before, only data going out to foreign code)
        • in this case, receiving an &Foo makes sense, since you will use it from within Rust
      • so maybe it wants to take into account the sort of item in which the type appears? (or maybe not)
      • who will write comment: pnkfelix
  • Coherence can be bypassed by an indirect impl for a trait object
    • (See above)
• Nominated PR
  • [WIP] Make a table of trait object type_ids and vtable pointers available to programs
    • uses linker to collect information about trait object vtables and try to expose for serialization / deserialization
    • there is some work to draft an RFC here
      • I've gone ahead and created a place to collaborate on an RFC: https://github.com/alecmocatta/trait-object-deserialization. I invite anyone with an interest or any insight to feel free to contribute to it! I'll input to it myself over the coming weeks.
    • Tier 1 & Platform independence?
    • Linker hacks / mechanism?
  • Fixes soundness bug 18510 by aborting on unwind from safe extern "C" functions only
    • Close as postponed — Niko to write comment
  • Stabilize attribute macros on inline modules
    • pnkfelix to update on the current status
    • rust-lang/rust#64197
    • our sense is that we probably want the semantics to be “lazy loading” of out of line modules
      • would need some API to do this, but don’t need that API now
      • but where is this design happening, in any case?
        • how would we make this decision?
    • also: mod foo { mod bar; } is fairly weird in any case
      • path handling is quite confusing in any case
    • effectively the rule for users would be “procedural macros cannot be applied to out-of-line modules (or things that contain out-of-line modules)”
    • Documentation: “Note that an out-of-line module, mod foo;, appears to any macro as just that item; the macro does not run over the contents of the module.”
    • feels like we want some kind of “shepherded group” here, feels weird to not know where we are going (e.g. with pnkfelix, alexreg, et. al)
    • Felix to FCP merge
• Nominated issues
  • Rust shouldn't warn about snake case in patterns
    • warn just at point of definition?
    • or warn also on the local variable?
    • how much do we care about enforcing the name convention vs annoying user?
    • what is chance you would do this at a local level and not crate?
      • reasonable to turn it on at point where you have e.g. auto generated or names that match elsewhere
      • or interop with other crates
    • Josh to write a summary (don’t lint for field puns specifically)
  • Arc::drop has a (potentially) dangling shared ref
    • (not discussed this week)
• Nominated RFCs
  • Calling methods on generic parameters of const fns
  • [ ]
• rfcbot pending list
  • merge: RFC: Generalized Type Ascription (rust-lang/rfcs#2522)
    • aturon nikomatsakis withoutboats
  • merge: Uplift lints from clippy to rustc (rust-lang/rust#53224)
    • aturon joshtriplett michaelwoerister nagisa scottmcm varkor withoutboats
  • merge: RFC: Elide array size (rust-lang/rfcs#2545)
    • Centril aturon cramertj nikomatsakis pnkfelix scottmcm withoutboats
  • merge: Tracking issue for RFC 2046, label-break-value (rust-lang/rust#48594)
    • aturon joshtriplett nikomatsakis nrc scottmcm withoutboats
  • merge: Make the turbofish syntax redundant (rust-lang/rfcs#2544)
    • aturon scottmcm withoutboats
  • merge: Stabilize Ident::new_raw (rust-lang/rust#59002)
    • Centril aturon scottmcm withoutboats
  • merge: Default behavior of unwinding in FFI functions (rust-lang/rust#58794)
    • aturon joshtriplett scottmcm withoutboats
  • merge: target_feature 1.1 (rust-lang/rfcs#2396)
    • Centril scottmcm withoutboats
  • merge: Calling methods on generic parameters of const fns (rust-lang/rfcs#2632)
    • Centril aturon scottmcm withoutboats
  • merge: Tracking issue for #![feature(maybe_uninit_ref)] (rust-lang/rust#63568)
    • Centril Kimundi cramertj dtolnay joshtriplett pnkfelix scottmcm withoutboats
      • blocked on working out some minor issues; should be resolved soon.
• Unassigned RFCs

Main topic

• how to organize ourselves
  • concern:
    • keeping “the funnel” tight through which RFCs pass so that the compiler team has fewer things to work on (and can e.g. finish the on-going things, ICEs, soundness holes, etc.)
  • concern:
    • open PRs on the RFC repo do not reflect the actual priorities we are trying to set
  • concern:
    • no good channel for “lower priority” discussion to occur at some pace
      • e.g. how does RFC #2580 potentially make progress?
  • concern:
    • some people we want in this meeting (cough Ralf cough) have limited schedules and need advanced notice
  • concern:
    • going over shepherded items in detail often not possible here
  • strawperson proposal:
    • establish a second design meeting, a la compiler team
    • schedule meetings on high priority topics most of the team
    • but have a “wildcard” meeting at a regular frequency
      • rotate who leads the meeting, perhaps, let them pick the topic?
    • to address concern of time:
      • 60 minutes of detailed discussion, meeting A
      • 30 minute triage meeting, meeting B
      • pre-triage before to populate lists
  • minutes from discussion
    • don’t have them back to back
    • can we find a time that works? (see the doodle)
    • to deal with the problem of open RFCs not matching our priority
      • maybe we can migrate open RFCs to issue repo
      • need a process to periodically review, get a liason assigned