Skip to content

Latest commit

 

History

History
262 lines (184 loc) · 10.7 KB

2021-05-11.md

File metadata and controls

262 lines (184 loc) · 10.7 KB
title tags
Triage meeting 2021-05-11
triage-meeting

T-lang meeting agenda

Attendance

  • Team members: nikomatsakis, Josh, cramertj, scottmcm
  • Others: simulacrum, Mara

Meeting roles

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

Scheduled meetings

  • Tomorrow: "Generators planning" lang-team#92
    • Need doc from Esteban!
  • May 19: "May updates" lang-team#93
    • Action item: Niko to ping groups =)
  • May 26: "Rust language "guiding principles"" lang-team#91

Action item review

Pending proposals

"MCP: Allowing the compiler to eagerly drop values" lang-team#86

Link: #86

  • No progress, Niko still planning to do a bit of a write-up. Probably won't happen for a week or two.

Nominated RFCs

No nominated RFCs this time.

P-high issues on rust-lang/rust

"fn() -> Out is a valid type for unsized types Out, and it implements FnOnce<(), Output = Out>" rust#82633

Link: rust-lang/rust#82633

  • Esteban, Felix, and Niko spent time digging into this.
  • We decided that we don't like Niko's branch and would prefer Esteban's general approach, but want to dig into what kind of problems arose.
  • More work is needed.

"Closures are unsound: 'static closures with non-'static return types." rust#84366

Link: rust-lang/rust#84366

  • Niko to review the PR again.

"Functions, closures, and HRTB-trait-objects can implement traits such that validity of associated types is never checked." rust#84533

Link: rust-lang/rust#84533

"HRTBs are unsound: HRTB on subtrait provides HTRB on supertrait with weaker implied bounds." rust#84591

Link: rust-lang/rust#84591

"A Pin unsoundness involving an impl DerefMut for Pin<&dyn LocalTrait>" rust#85099

Link: rust-lang/rust#85099

  • Another wacky Pin unsoundness; Niko doesn't understand well enough to summarize yet.
  • Related and similar to #68015.

Nominated PRs and issues on rust-lang/reference

No nominated items this time.

Nominated PRs and issues on rust-lang/rust

"Tracking issue for RFC 2345, "Allow panicking in constants"" rust#51999

Link: rust-lang/rust#51999

Unchecked action items:

  • 2021-04-27: ALL to review panic in consts stabilization rust-lang/rust#51999

  • 2021-04-27: Niko to move panic in consts stabilization to its own thread rust-lang/rust#51999

  • Stabilization report

  • Nobody has looked closely into it yet

  • Action item: scottmcm to read into it and propose FCP if it seems appropriate

"Add expr202x macro pattern" rust#84364

Link: rust-lang/rust#84364

This makes it possible to use inline_const (#76001) and let_chains (#53667) inside macros' expr patterns in a future edition by bifurcating the expr nonterminal in a similar way to pat2021 to remove some backwards compatibility exceptions that disallow const/let at the beginning of an expr match.

  • More detailed writeup
  • TL;DR: The full set of expressions have diverged somewhat
  • Proposal:
    • Move this to an issue linked from the two tracking issues
    • Desire a clear summary of grammar changes required
      • what does expr match now that it did not before
      • assess what impact of this change might be
      • (crater run might be desired)
    • Edition migration that would be required
    • Is there actual ambiguity required here? Can we get an example of something that changes behavior?
  • Action item:
    • Felix to write the above, link issue, and remove nomination

"Tracking issue for unsizing casts in const fns" rust#64992

Link: rust-lang/rust#64992

Example:

const fn test() {
    let _x = NonNull::<[i32; 0]>::dangling() as NonNull<[i32]>;
}
  • Already stable in const item bodies
  • Somebody to fcp merge -- on the PR #85078

"Allow unused variables with todo!" rust#79850

Link: rust-lang/rust#79850

  • Pending action item:
  • No discussion this week, will remove nomination.

"Implement new lint for detecting buggy pointer-to-int casts" rust#81789

Link: rust-lang/rust#81789

  • Proposal last week:
    • don't claim to fix the original problem but still land this warning
  • Question now:
    • How valuable is this lint on its own?
  • cramertj: If you are casting a pointer to a u32, you'r probably trying to do something. What case are we actually trying to fix?
  • Niko: it would be nice to have an actual bug
  • scottmcm: we're generally eliminating cases... u64, usize, isize...
  • josh: I've written a lot of low level bit manipulation code in Rust which required a lot of as casts. It's not hard for me to imagine accidentally stuffing a pointer instead of what I wanted. Ironically C would give me more cross-checks via compiler warnings here, since C generally warns about casting from a pointer to a "smaller than integer" size for the current platform.
  • Niko: I remember having a bug where I was casting a fat pointer to a usize and somehow getting it cast back with a junk vtable, it was one of the worst bugs I ever had to track down. I could see this catching a mistake in that vein.
  • Scott: Should we consider lints being aware of the current target? Fewer false warnings in exchange for "less portability".
  • Mark: that can be a real pain -- e.g., on rust ci whenever something is specific to one configuration, it's very confusing.
    • Niko: +1, I'd rather we have some evidence that this is really important
  • Felix: Consider a lint group?
    • Niko: I would like to have #![allow(nonportable_32_bit)]
  • Josh: could start at allow and allow opt-in
  • Scott: if there was an explicit method for casting, like to_bits and from_bits, wouldn't that be a better situation?
    • then we could disallow these as casts altogether
    • josh: e.g, a truncate method that only took integer to small integer...?
  • Mara: what about the fat pointer situation?
    • Josh: maybe disallow it on fat pointers, only permit it on thin pointers
    • Niko: yes you can say if you want the data pointer
  • Niko: I'm in favor of introducing better alternatives to as and deprecating its usage
  • Josh: I am doing a lot of 64-bit indexing, interconversion between usize and u64 is pretty annoying
    • it'd be nice to have a method that interconverts from usize to just u64 (or u32) depending on target - size must match for that one
    • scott: I'd rather we could just index by all the unsigned types
  • Action items:
    • Josh, Mara to start thread on T-libs to discuss those methods
      • cc PR author, t-lang
    • Summary on issue (Mark)
      • we would like to have methods to point people to, and a simpler lint

"add back support for inner attributes on non-block expressions?" rust#84879

Link: rust-lang/rust#84879

  • Turns out that some internal tool (rustfmt) relies on this, came up on internals
  • Related: rust-lang/rust#84414
struct S {
    #![doc = ""]
}

enum E {
    #![doc = ""]
}

union U {
    #![doc = ""]
}
  • Niko: Seems similar-ish to match patterns
  • Inner attributes: how useful?
    • Top-level on a module
    • Some tricks with attributes in macros
    • Tagging bodies of match arms or if expressions
      • match foo { 33 => { #![likely] ... } } -- still allowed after this PR
    • Resolving ambiguity (
      • #[likely] if foo { ...} else { } // how do you even tag the else
      • (#![foo] 3 + 2) -- disallowed by ths PR
      • What about if some_intrinsic::likely(foo) { ... } else { ... }
  • Does anyone have an active argument in favor of keeping inner attributes in these positions?
    • Mark: It did break 4 crates rust-lang/rust#83312 (comment)
    • Niko: if we add support in structs, I'd expect it to work in matches, they look very similar
  • Origin of the performance concern?
  • Josh: there was a procedural failure in that we failed to register a concern
    • so we have to choose between "make a decision really fast" and "discuss and decide at our leisure"
      • felix: might that not mean more crates appear?
        • Should we lint?
  • Josh: what about a warning period?
  • Summary:
    • Niko: Ask about implications of reverting for match

"Allow struct and enum to contain inner attrs" rust#84414

Link: rust-lang/rust#84414

  • Related to the above

"Stabilize "RangeFrom" patterns" rust#83918

Link: rust-lang/rust#83918

From previous meeting:

  • We requested this
  • Stabilization writeup
  • scottmcm proposed fcp merge
  • Action item for folks: check your boxes

"Uplift the invalid_atomic_ordering lint from clippy to rustc" rust#84039

Link: rust-lang/rust#84039

  • Josh FCP'd, so check your boxes

"Deny float matches" rust#84045

Link: rust-lang/rust#84045

Last meeting:

Niko: volunteers to write up a proposal and run it by const generics working group to double check his reasoning

"stabilize member constraints" rust#84701

Link: rust-lang/rust#84701

  • FCP