Skip to content

Latest commit

 

History

History
199 lines (152 loc) · 9.15 KB

2021-02-16.md

File metadata and controls

199 lines (152 loc) · 9.15 KB

T-lang meeting agenda

Attendance

  • Team members: nikomatsakis, joshtriplett, scottmcm, cramertj, pnkfelix
  • Others: simulacrum, mara, connor horman

Meeting roles

  • Action item scribe: Mark
  • Note-taker: nikomatsakis

Action item review

Ad-hoc project updates

  • Declarative macro repetition counts draft RFC available -- Niko
    • Action item: Niko to suggest posting on the RFC repository
    • Think the impl work is already done (draft)
  • Inline assembly -- Josh
    • not quite ready for stabilization, but almost
    • rust-lang/rust#72016 (comment)
      • this comment has the "must haves" and "nice to haves" before it's time for stabilization
  • Idiom lints -- Ryan, Niko, and Scott
    • Preparing a document with the following info about each lint
      • Tracking issue
      • Code example that triggers the lint
      • Code example that fixes it
      • Migration supported
      • Current state
      • Rationale in a nutshell
      • Concerns folks have raised
      • Proposed resolution
    • Confusion about the term:
      • FCW (as Niko intends it) is specific to soundness or bugs, and is not something we should tie to an edition
      • But people use the term FCW more broadly, e.g. for deprecation
      • What's a better name, broading

Pending proposals

"MCP: Deref Patterns" lang-team#77

Link: #77

  • Charter is pending
  • Last time we discussed pursuing a variant that excludes DerefPure
  • How do we feel about special-casing Box and/or std pointer types?
    • Note that borrow checker already special cases box
    • Also box already has an (unstable) pattern
    • Some precedent for special casing Rc, Arc:
      • CoerceUnsized, self: Rc<T>
      • other examples: Vec<T>
    • Alernatives:
      • Limit to Box -- this is basically the box pattern, though less good (because box has deref-move)
      • Some form of perma-unstable (until rfc'd) DerefPure trait or attribute or something used by std library types
        • has notable precedence
        • Other crates in the ecosystem have good reason to want this stabilized, but at the same time, there's value in having this for std types even if we can't have it for all types right away.
    • Question:
      • What about types that don't implement DerefPure?
        • They would be require an _ pattern since they cannot be known to be exhaustive.
        • This would introduce 'random code running during pattern matching'.
    • Proposal:
      • Include:
        • Deref-based pattern matching for appropriate things in the standard library
          • Job of group is not necessarily to find complete set of appropriate types, just to propose a reasonable starter set
      • Exclude (for now):
        • Stability path for DerefPure or attribute
        • DerefMove
        • Types that aren't pure
    • Other concerns:
      • Figuring out how this interacts with binding modes
        • e.g. match Rc::new(Some(5)) { box Some(x) => ... }?
    • Action item: nikomatsakis to write up the proposal

Nominated RFCs

"add const-ub RFC" rfcs#3016

Link: rust-lang/rfcs#3016

  • Why is this nominated? Revisit it next week.
  • Action item: pnkfelix to request a summary of why this is nominated on thread. =)

"try_trait_v2: A new design for the ? desugaring" rfcs#3058

Link: rust-lang/rfcs#3058

  • Action item: nikomatsakis to read it
  • Action item: pnkfelix to read it
  • Action item: cramertj to read it
  • scottmcm will likely update the names based on libs feedback from Wednesday's meeting (2021-02-17).

"Change visibility scoping rules for macro_rules macros" rfcs#3067

Link: rust-lang/rfcs#3067

  • Considered "probably ready"
  • Summary:
    • Add pub (including pub(self) etc) into all editions, applied to macro-rules
      • this makes them behave like regular items
    • Change the default behavior in edition N such that macro_rules! with no pub is a private item (like a regular item) equivalent to pub(self) macro_rules!
      • Requires migration
  • Open question:
    • What is edition N?
    • How well does the migration work?
    • Do we have/need a workaround for the "recursive macro" pattern?
      • Niko's opinion is this doesn't necessarily have to be automatic
  • Mark: Would be happy if we had a pattern that works
    • could even be some attribute to opt back in to the old behavior
  • Action item: Niko to post summary of the above and encourage folks to come up with a good answer

P-high issues on rust-lang/rust

repr(C) is unsound on MSVC targets" rust#81996

Link: rust-lang/rust#81996

  • Summary of what's going on:
    • C compilers on Windows inconsistent rules for structs/unions/enums.
      • e.g., msvc vs gnu, msvc vs clang
      • don't agree on all the details
      • josh: I believe gcc, clang can be made to agree with msvc using an attribute ("msvc struct")
    • Whose fault is this?
    • If the target triple is "msvc", shouldn't we just match msvc and the bug is then using gnu/clang ...? -Niko
  • Is this compiler or lang?
  • Josh: Lang needs to state what we intend the behavior of repr(C) to be. * Is repr(C) a defined layout that "applies everywhere"? * Or is it defined to be "compatible with the C compiler for the target"?
    • Josh believes the latter, but reference suggests the former
    • Scott -- there are stable stdlib APIs that describe repr(C) as being "repr(stable)"
    • There is also the behavior defined by the C standard and then the behavior for things that go beyond the C standard (e.g., zero sized types)
      • I think the problem here is that the issue is for things where the C standard does not describe the behaviour. For "normal" (no ZSTs, no packed types, etc) structs the distinction doesn't come up.
  • Second issue: enum sizes
    • How much space we allocate for an enum that is declared repr(C) could vary by platform (C-like enum).
    • Some compilers error or overflow, or issue warnings.
  • If we say "defined to match the default C ABI for the platform"...
    • For each target, a link to that default C ABI or perhaps the "reference compiler" we're trying to match
      • Reasonable question: who decides which one..?
    • Do we need a clang target?
  • Action item: Josh to write up a comment stating that:
    • repr(C) is intended to match the default C ABI
    • we'd like to see documentation stating the ABI for each target triple
  • Implication:
    • This is a bug (we're not matching the default)
    • And there is a feature request for a new repr to stray from the default
      • e.g., some kind of "naive" or "stable" repr that just lays out fields in order/size/alignment? that would be a good project proposal, we can discuss the best way to address the use cases.

Nominated PRs and issues on rust-lang/rust

"[Edition vNext] Consider deprecating weird nesting of items" rust#65516

Link: rust-lang/rust#65516

  • Expectation is that this won't happen for this edition, too many details to figure out
  • But we could add potentially a warning at any point, would want to decide how to manage patterns that people do use which are useful
  • Suggestion:
    • Someone can propose a specific lint that proposes various heuristics, and we can discuss

"Stabilize unsafe_op_in_unsafe_fn lint" rust#79208

Link: rust-lang/rust#79208

  • Now in FCP. No action item.

"Unsafe checking skips pointer dereferences in unused places" rust#80059

Link: rust-lang/rust#80059

  • No action item, just un-nominate.

"Allow qualified paths in struct construction (both expressions and patterns)" rust#80080

Link: rust-lang/rust#80080

  • Fixes: Parsable associated enum constructor #79658
  • Summary here
  • Action item: scottmcm to fcp merge

"Allow specifying alignment for functions" rust#81234

Link: rust-lang/rust#81234

  • Action item: Josh to fcp merge and check boxes for felix, scott, nikomatsakis

"Update BARE_TRAIT_OBJECTS lint to deny in 2021 edition" rust#81244

Link: rust-lang/rust#81244

"Invalid field is never read: lint warning" rust#81658

Link: rust-lang/rust#81658

"Deny WHERE_CLAUSE_OBJECT_SAFETY in Rust 2021" rust#81992

Link: rust-lang/rust#81992