Skip to content

Latest commit

 

History

History
220 lines (163 loc) · 10.2 KB

2021-04-06.md

File metadata and controls

220 lines (163 loc) · 10.2 KB
title tags
Triage meeting 2021-04-06
triage-meeting

T-lang meeting agenda

Attendance

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

Meeting roles

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

Scheduled meetings

Planning meeting tomorrow!

  • Open issues for possible design meetings
    • there are a few open already
  • Status updates for open projects etc

Action item review

Pending proposals

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

Link: #86

  • Still waiting for summary, no action needed
  • Inclined to close for now, take action item to make sure summary happens

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

Link: #89

  • Change behavior of #[path] when you are inside a module m and m was declared with a #[path] attribute
  • This would have to be tied to an edition, for compatibility reasons
  • Too late for Rust 2021 -- deadline for decisions has passed, and it's not very urgent
  • There are also a few options to consider, so don't want to rush into it
  • Summary:
    • when using #[path] to specify a relative path for a module...
    • ...this result is affected by whether the current module is a mod.rs (or lib.rs) pattern...
    • versus a foo.rs file.
    • This MCP tries to tweak those rules.
  • Scott: General idea of matching the foo.rs and lib.rs/mod.rs pattern seems reasonable
    • ...but so does having path work only like normal filesystem stuff, so who knows
  • Defer detailed discussion for now till a future meeting or async.
  • Question for today: push on 2021 Edition?
    • Felix: I fear the pattern that of not taking things for Rust 2021 but then not thinking about it again until just before next edition ships
    • Josh: Agree! I think we should still talk this over very soon, but not target Rust 2021.
  • Meeting consensus
    • Do not target Rust 2021
    • But do continue discussing as a possible item for a future edition (and do not wait until right up until the deadline)

Nominated RFCs

"RFC: Supertrait item shadowing" rfcs#2845

Link: rust-lang/rfcs#2845

  • Unable to define a subtrait that inherits from a supertrait where both define the same method and to deal with it unambiguously
  • Scott nominated: 1 check box away from FCP, what do we think?
  • Niko's comment
  • Conclusion:
    • Niko and Felix to take action itms to review
    • May need a change to the RFC to reflect the request for an ambiguity error when invoked from inside the trait

"add const-ub RFC" rfcs#3016

Link: rust-lang/rfcs#3016

  • Been discussed in numerous previous meetings
  • Ralf rewrote the RFC along the lines we suggested in previous meeting:
    • Concluded that, at least for now, we do not want to mandate UB detection but to leave it as implementation guidance
  • Niko proposed fresh FCP
  • Action items for folks to read and check their boxes

"Raw Keywords" rfcs#3098

Link: rust-lang/rfcs#3098

  • Currently in FCP
  • There have been some concerns raised on the thread
  • We may want to pause the FCP. Some reasons:
    • this would allow someone to do an implementation PR and do a crater run to decide if we can use k# in every edition
    • to give due time for consideration from some recent comments (e.g., 1 and 2)
  • Major concern raised is basically
    • "would we wind up taking long enough to process the non-keyword part of any change that the keyword can just take the next edition"
    • but also "user experience is substantially worse"
  • Eric raised the question of opting in with feature to using the new keyword
    • The argument against features we made before is that we don't want the combinatorial explosion of "dialects of Rust"
      • e.g., this project uses feature A but not feature B
  • Felix feels the wording is misleading about the word ident
  • Meeting consensus
    • Cancel the FCP
    • Note in the OP the following next steps:
      • Prioritize 3101 to secure the necessary edition space
      • Want the results of a crater run to deterine whether k#foo can be used across all editions

"RFC: Reserved prefixes in the 2021 edition" rfcs#3101

Link: rust-lang/rfcs#3101

  • Reserves token space without defining semantics for anything in that token space
  • Effect of current RFC is to forbid the following from being tokenized (in all cases, with no whitespace):
    • Reserves ident#ident
    • Reserves ident"..."
    • ident'...'
    • ident#[0-9]+
  • It's weird right now that a"xyz" is three tokens but b"xyz" is one token, which this RFC would resolve.
  • Some debate about the right time to issue an error:
    • Tokenization time?
    • Pass on through and make it usable in a macro?
      • If we allow passing on to macros, you can implement prototypes of new syntax
      • But you can implement macros that use this space in ways that could conflict with our reservation!
      • Also, if you are going to prototype, you might as well just use the actual keyword, not k#foo, right?
  • RFC had proposed that we "don't worry" about breaking things that conflict, but it's better if we don't have to make that judgement call
  • Cross edition compatibility:
    • Rust 2021 code can use older macros with whitespace; macro-rules macros cannot observe this
    • Only concern might be a procedural macro that was comparing spans to tell if two tokens were truly adjacent
  • Tokenization error is forwards compatible with all future options
    • Also compatible with tokenizing differently from a single token, should we want that, or being handled in special ways
  • Concerns with FCP merge?
    • Mark: General concern with speed, but no concrete concerns
    • Scott: major impact would be if people are using this in macros already (e.g., f"foo")
  • Josh to start an FCP
  • Edition decision:
    • Can do in Rust 2021
    • If no impact, Rust 2018 and 2015 as well

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

  • Previous consensus:
    • Want to prohibit function types that return unsized types
  • estebank has opened PR #83915 to do that
    • some discussion about whether it's sufficient, as the PR doesn't cover impl Trait
  • now up for compiler team review

Nominated PRs and issues on rust-lang/reference

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

Link: rust-lang/reference#970

  • Discussion centers around what language to use regarding provenance, and whether it is preserved
  • Long Zulip thread without a concise summary
  • The reference PR itself doesn't summarize advantages or disadvantages, simply states that provenance is lost
  • Niko: This is wading into stacked borrows territory, why would we want to say this specific thing?
  • Seems clear we won't be able to reach a conclusion in this meeting
  • Need a good summary of tradeoffs etc, perhaps a design meeting
    • Need Ralf in that design meeting
  • Better topic might be "let's plan the things to address and in what order" than to decide on this specific PR
    • Question is: is this question something we can do incrementally or only as part of a larger effort?
  • Action item:
    • Niko to summarize that we want to have the above discussion first and that we would prefer not to make this decision in a PR on the reference but rather an RFC etc

Nominated PRs and issues on rust-lang/rust

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

Link: rust-lang/rust#81789

"Use const generics for stdarch intrinsics" rust#83167

Link: rust-lang/rust#83167

  • Decision that needs making: do we want to require const generics for the intrinsics
  • No updates, seems like we are unsure what the right next steps would be
  • Have passed on that we would like feedback from actual users
  • No further consideration required at this time, un-nominate
  • Note that we are up against the Rust 2021 deadline, but then again we have to keep it for Rust 2018; nobody is too worried about having to delay until next edition.
  • Historical note:
    • How did this get stabilize without langs being invoked?
      • Was overlooked as a procedural "misstep", essentially.
  • Ordinarily lang doesn't give a lot of scrutiny to rustc attributes, but in this case it becomes part of the public interface
  • Proposed rule:
    • rustc_ should not be used for things that affect the public API
  • Action item: Mark to leave a summary comment and un-nominate (for lang)

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

Link: rust-lang/rust#83213

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

Link: rust-lang/rust#83312

"Stabilize extended_key_value_attributes" rust#83366

Link: rust-lang/rust#83366

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

Link: rust-lang/rust#83386

  • Niko wants people to look at this. But we did not discuss in meeting.

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

Link: rust-lang/rust#83595

  • This is actually about putting the attribute on a field, which AFAIK has never actually done anything.
  • I think this is by design? IIRC we talked about this one in some meeting when the PR went it to check it...

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

Link: rust-lang/rust#83713