Skip to content

2021-04-20.md

Latest commit

 

History

History
287 lines (206 loc) · 11.4 KB

2021-04-20.md

File metadata and controls

287 lines (206 loc) · 11.4 KB

T-lang meeting agenda

Attendance

  • Team members: Niko, Josh, Scott, Taylor, Felix
  • Others: simulacrum

Meeting roles

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

Scheduled meetings

Action item review

Two items from backlog bonanza:

  • 2021-03-17: Taylor to close RFC 2375 rust-lang/rfcs#2375
    • cramertj: Is close what we actually wanted?
      • It seems like the RFC could be updated with edits from the thread.
    • Libs wants this
      • Question though: would we want to lint on trait imports that are only used to access inherent methods?
        • Warn by default: Keeps you compatible with the newest version
        • Allow: Helps you retain compatibility with older versions of Rust
    • The remaining problems seem small, the RFC seems "close enough", needs some work
    • Consensus:
      • We would like to see edits to the RFC made
      • Leave a comment outlining the remaining answers we want addressed
        • Specifically resolving the ambiguity when new methods are added to the trait in favor of "true inherent" methods written in the impl
      • Request person who opened RFC to follow up or see if anybody else wants to pick up the torch; revisit next week.
  • 2021-03-17: Taylor to discuss with Scott and potentially propose fcp merge RFC 2316 rust-lang/rfcs#2316
    • Discussed in Zulip
    • Question is how this interacts with const, as it seems analogous
      • cramertj: currently I think const is limited to the impl, but I would be surprised not to see that qualifier used on methods
      • pnkfelix: not obvious that these are analogous to me (niko: nor I)

scott: I feel like it would be useful to be able to do the following in an analogous way

trait Foo {
    fn bar();
}

impl Foo for MyType {
    const fn bar() { } // allowed to specify *more*
}
  • Do we block this rfc on discussing that?
    • Reason to do so: it would create an inconsistency
  • (scott) Any concern I'd have about it is in ordering, I think -- I'd like to have impl const Default first, to avoid a whole bunch of churn that we don't want, from people doing impl Default for Foo { const fn default() -> Self { ... } } and then needing to change to impl const Default for Foo { ... } shortly thereafter.

  • const also has complexity because we want to be able to write impls that are conditionally const, and have const bounds

    • RFC 2632 (Calling methods on generic parameters of const fns) addresses this

  • Taylor to FCP merge the unsafe RFC

  • Followups later to handle const and discuss interaction with RFC 2632

Pending proposals

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

Link: #86

  • [2021-04-06]: Niko to make sure we have a lang team design note on eagerly drop #86

"MCP: Change path attribute behavior of modules." lang-team#89

Link: #89

  • Pitch: Handle explicit module paths more intuitively
  • Leveraging editions (not 2021)
  • General agreement that the current state is confusing
    • Ability to use #[path] within an inline module
  • Currently: path is based on "where this would be if it were a file"
  • Proposed: path is based on the file system
  • An alternative: Could have an option on the attribute, or introduce a new attribute that is always relative to the file system
  • Consensus that we should do something here?
    • Not really, many of us want more evidence that people are getting confused.
    • path is relatively rare.
    • The risk is relatively low: the path has to exist, so the chance you get this wrong in a way that sort of works...
      • ...and the error message tells you specifically where it was looking for the file.
      • ...and maybe if there are multiple files that potentially match under a different interpretation then that would be a good lint, suggesting that the file be renamed.
  • Another approach:
    • Look at the cases where folks are using path and find a way to make that easier.
    • One common case is conditional compilation; maybe we could target that pattern more specifically.
  • Meeting consensus:
    • Not inclined to make this change without:
      • more evidence that people are feeling confused
      • evidence that there are patterns where you must use path without other alternatives

Nominated RFCs

"add const-ub RFC" rfcs#3016

Link: rust-lang/rfcs#3016

  • In FCP, not much more to say
    • side note: we might want to tweak this threshold for our team
    • In general, I think requiring a supermajority, not just a majority, would be good ~ scott
    • Filed rust-lang/rfcbot-rs#293

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

  • PR is up for review

Nominated PRs and issues on rust-lang/reference

"Document raw pointer <-> usize casts." reference#970

Link: rust-lang/reference#970

Nominated PRs and issues on rust-lang/rust

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

Link: rust-lang/rust#51999

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

Link: rust-lang/rust#81789

  • Discussed on 2021-03-30 in depth
  • Our consensus seemed to be lost, but we didn't have much follow-up on the issue
  • [2021-03-30]: Taylor to write up a summary of the ptr cast discussion
  • Pending crater run as well, which may inform the discussion

"Update BARE_TRAIT_OBJECT and ELLIPSIS_INCLUSIVE_RANGE_PATTERNS to errors in Rust 2021" rust#83213

Link: rust-lang/rust#83213

  • Blocked on impl issues, no discussion required, removing nomination

"parser: Remove support for inner attributes on non-block expressions" rust#83312

Link: rust-lang/rust#83312

  • FCP Report by petrochenkov:
    • "I propose removing support for inner attributes on tuple, parentheses, array, struct and match expressions from the language."
    • "Such attributes are not used in practice and pose challenges to token collection performed during parsing for various macros to work correctly"
    • "The RFC, however says "Inner attributes can be placed at the top of blocks (and other structure incorporating a block) and apply to that block, which doesn't apply to any cases removed in this PR."
  • Niko did an fcp merge
fn attrs() {
    (#![print_target_and_args(fifth)] 1, 2) + 5;
    ((#![print_target_and_args(fifth)] 1), 2) + 5;

    [#![print_target_and_args(sixth)] 1 , 2];
    [#![print_target_and_args(seventh)] true ; 5];


    match 0 {
        #![print_target_and_args(eighth)]
        _ => {}
    }

    MyStruct { #![print_target_and_args(ninth)] field: true };
}
  • Reasons to keep inline attributes on blocks:
if foo {
    #![likely]
} else {

}

match foo {
    22 => {
        #![likely]
    }
    
    44 => {
    
    }
}

"Stabilize extended_key_value_attributes" rust#83366

Link: rust-lang/rust#83366

  • Stabilize #[foo = bar!(...)]
    • This is already possible via macro_rules! (!), due to expr interpolation
    • Subsumes some other features, such as out of line documentation
  • Note expansion order:
  • Pending FCP
#[macro_attr1]
#[doc = mac!()] // "inert"
#[macro_attr2]
#[derive(MacroDerive1, MacroDerive2)]
struct S;

#[macro_attr1]
fn foo() {
    mac!();
}

// this works on stable for whatever reason
// and is commonly used "in std and elsewhere" (--simulacrum):
macro_rules! foo {
    ($x:expr) => {
        #[macro_attr1]
        #[doc = $x] // "inert"
        #[macro_attr2]
        #[derive(MacroDerive1, MacroDerive2)]
        struct S;
    }
}
foo!(mac!());

bar!();

  • Question petrochenkov asked:

  • What complications arise from accepting arbitrary expressions that do not arise from this?

#[foo = mac!(arbitrary_expr_here)]
  • What complications arise from that, anyway?
  • Only thing that the rustdoc team actually needs is include_str and friends
  • What about stabilization -- is this arbitrary token trees?
    • For example, can you put try { 4 } in here on stable?
    • When does macro fragment parsing occur, presumably "after", at the time of macro invocation?
  • Niko Felix to register concern about semantics of expressions here and summarize other questions

"Stabilize :pat_param but leave :pat2021 gated" rust#83386

Link: rust-lang/rust#83386

  • In FCP, no discussion required

"Revert "Rollup merge of #82296 - spastorino:pubrules, r=nikomatsakis"" rust#83713

Link: rust-lang/rust#83713

  • Niko would like to see this revert happen
    • Current code doesn't work across crates and not worth the effort to fix it without an active design effort
  • We can always re-land it if/when this effort restarts

"exploration: ignoring arrays in method dispatch" rust#84133

Link: rust-lang/rust#84133

  • PR #84147 is already in FCP
  • No discussion needed, but cc pnkfelix

Items not reached in triage meeting:

"#[repr(align(8))] is not accepted for arrays" rust#83595

Link: rust-lang/rust#83595

"Stabilize "RangeFrom" patterns" rust#83918

Link: rust-lang/rust#83918