Skip to content

Latest commit

 

History

History
187 lines (122 loc) · 7.91 KB

2021-02-09.md

File metadata and controls

187 lines (122 loc) · 7.91 KB

T-lang meeting agenda

Attendance

  • Team members: nikomatsakis, pnkfelix, scottmcm, cramertj
  • Others: simulacrum, m-ou-se

Meeting roles

  • Action item scribe: simulacrum
  • Minutes scribe: scottmcm

Action item review

Pending proposals

"MCP: Deref Patterns" lang-team#77

Link: #77

  • Have a proposed charter
  • Josh and I talked about this last time
    • the trickiest bit is that doing it right will require something like DerefPure
  • Other considerations:
    • Syntax deref foo?
    • This likely does not fit into any of the listed priorities, though it may be considered "Targeted ergonomic wins and extensions".
  • Notes:
    • want this, would be useful
    • definitely tricky: Deref currently runs user code, which make exhaustiveness hard (if not impossible) without extra constraints
    • codegen correctness may also be a can of worms: can we trust that something being a Some last time means we can just look at the internals later?
    • worry: having unsafe DerefWhateverMarker opens many doors; this isn't the only place that wants something like that.
    • DerefPure would conflict with a String as DerefMut that needs to allocate if we have the "free conversion to String from string literal".
  • Conclusion?
    • Would be nice to have a summary of the state of DerefMove/DerefPure/etc?
    • Explore versions without exhaustiveness? Or only irrefutable pattern support? Does having a version with Pure cause a hazard in the future?
    • Explore versions where exhaustiveness requires limitations, such as grouping all clauses that rely on Deref together.

Nominated RFCs

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

Link: rust-lang/rfcs#3058

  • Updated based on Scott's gist
  • Folks should re-read, anything else to say?
  • Looks like it was never unnominated after the previous meeting; I've removed the tag. But please do read -- indications so far are that it's much easier to follow now. Libs is also taking a look. ~scottmcm

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

Link: rust-lang/rfcs#3067

"Mark 2203 as mostly superceeded by 2920" rfcs#3073

Link: rust-lang/rfcs#3073

  • Niko merged
  • Nominated because I couldn't find a specific & official lang decision about this being the plan, so wanted to make sure people saw it in case there were objections. (But of course it's not a commitment, so can be changed later if needed, so I don't think an FCP is needed.)

P-high issues on rust-lang/rust

No P-high issues this time.

Nominated PRs and issues on rust-lang/rust

"Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e Foo(Bar(x) | Baz(x))"" rust#54883

Link: rust-lang/rust#54883

  • Can we unnominate this?
  • Yes, see stabilization issue further down.

"Lint for unused borrows as part of UNUSED_MUST_USE" rust#76894

Link: rust-lang/rust#76894

  • Waiting on answers to questions.
  • (Also needs something to get past the rustbot block.)

"Stabilize unsafe_op_in_unsafe_fn lint" rust#79208

Link: rust-lang/rust#79208

  • stabilization report was added to the OP
  • pFCP started; check your boxes

"Stabilize or_patterns (RFC 2535, 2530, 2175)" rust#79278

Link: rust-lang/rust#79278

  • Pending FCP
  • Question Scott raised about precedence of or patterns:
    • let Ok(v) | Err(v): T = ...
  • Parens are required in function headers
  • Arguably let Ok(v) | Err(v) = expr would be ok
    • but let (Ok(v) | Err(v)) = expr is ok too
    • Niko and Taylor (and Mark) feel that the precedence is visually ambiguous
    • Josh is willing to go along with this temporarily, but would like to see the requirement for parentheses removed in the case of a let without a type. (No objections to permanently requiring parentheses when there's a : T)
  • Conclusion:
    • Parens required in function header, lets, and closures --
      • any place that we have an irrefutable binding with optional type :)
  • Action item:
    • Scott to write comment

""!" is the only type that is unsafe to raw-ptr-deref into a "_" pattern" rust#79735

Link: rust-lang/rust#79735

  • Niko: Does someone want to talk point on preparing a proposal here regarding let _ = *foo is actually UB or not?
  • Conclusion:
    • We want unsafe to be required (rust#80059) and it is considered UB for now until we decide it should really be UB (punting on this).
  • Niko to record conclusion, assuming unsafe block will be needed.

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

Link: rust-lang/rust#80059

  • Niko: Going to work with LeSeulArtichaut on this
  • No lang action item now.

"don't gratuitously error on tests returning Result with lifetime" rust#80934

Link: rust-lang/rust#80934

  • Old rule was "No generic tests"; proposed rule is "No generic parameters except lifetimes".
  • Seems lacking in motivation.
  • Background:

"Allow specifying alignment for functions" rust#81234

Link: rust-lang/rust#81234

  • Permit #[repr(align=32)] on functions, which translates to LLVM
  • No feature gate in current PR
  • Consensus: sounds good as unstable; Josh to say "go for it" officially for unstable.

"Support forwarding caller location through trait object method call" rust#81360

Link: rust-lang/rust#81360

  • Extend #[track_caller] to virtual dispatch for dyn Trait values
  • This works by changing the ABI, but couldn't do that for virtual dispatch.
  • Is this inherited by all impls? Sounds like yes. Should it then be required on the impl to match?
  • Do we need a writeup? Should it go in unstable and have a report before stabilizing? Should it have an RFC update to the track_caller RFC?
  • Taylor to ask for a writeup.

"Allow casting mut array ref to mut ptr" rust#81479

Link: rust-lang/rust#81479

Nominating for T-lang, this allows the cast &mut [T; N] as *mut T copying the already existing one cast &[T;N] as *const T.

  • Niko to say "go for it"

Edition nominations

Edition spreadsheet

  • Out of scope for the 2021 edition because too complicated
    • Consider deprecating weird nesting of items
    • Tail expression is interesting, but the rule would be tricky.
    • pub type Foo = Bar
  • k#foo
    • Not itself backwards compatible
    • Use case:
      • Allows us to release keywords and stabilize before the new edition comes about
      • When you migrate, the edition migration will remove the k#throw edition
    • Adding k#foo would require an edition change to macros by making them lex k#foo as a single token
      • But as a cargo fix it should just be adding spaces inside the macro invocation, which shouldnt' be too horrible.
    • Let's continue on Zulip.
    • (what scott sain in the meeting he'd already written there)

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

Link: rust-lang/rust#81244

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

Link: rust-lang/rust#65516