Skip to content

Latest commit

 

History

History
251 lines (182 loc) · 10.4 KB

2021-04-27.md

File metadata and controls

251 lines (182 loc) · 10.4 KB
Raw
title tags
Triage meeting 2021-04-27
triage-meeting

T-lang meeting agenda

Attendance

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

Meeting roles

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

Scheduled meetings

Action item review

Pending proposals

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

Link: #86

  • no progress, Niko still hopes to summarize

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

Link: #89

  • FCP to close, no significant discussion afterwards.
  • One comment, pointing out there might be reasons to use paths around platform independence (which we did touch on in meeting itself)

Nominated RFCs

"add const-ub RFC" rfcs#3016

Link: rust-lang/rfcs#3016

  • looks like it can be merged
  • who has permissions to merge?
  • simulacrum: need to approve, then anyone from this team should have merge-capability
  • pnkfelix takes action item to merge

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

  • There is a PR and I (niko?) prepared an alternative fix

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

Link: rust-lang/rust#84366

  • Has a pending PR, under review

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

  • Stablization Report
    • I would prefer this to be accompanied by a stabilization PR, or at least in its own issue, shall we move it? -Niko
  • lang team members should take action items to review this

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

Link: rust-lang/rust#81789

  • cramertj summarized old conversation
  • no responses yet
  • nothing to do here at this time
  • lang team members should take action items to review cramertj's comment
  • general impression: no consensus among team about going forward; little confidence in PR as written, but generally positive about doing something to try to improve things here

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

Link: rust-lang/rust#83312

  • In FCP now
  • Aaron1011 left a comment
  • (comment just says compiler has addressed some of the problems, but there is still value in removing them)
  • cramertj: is this actually a breaking change, when you consider when these might fall under a cfg'ed section of code? (Or more generally, a part of the code that is dropped e.g. via macro expansion)
macro_rules! foo {
    ($foo:expr) => { }
}

fn main() {
    foo!((#![foo] 22));
}
  • notably, the above (with a (#![foo] 22) being passed into a macro that takes a $foo:expr) compiles today on stable and we are pretty sure it will stop compiling after this change.
  • simulacrum: For what its worth, rustfmt "eats" the inner attribute in that context. (So it won't even be preserved via rustfmt's transformation.)

4 unique legitimate regressions:

  • match port { #![allow(clippy::cast_ptr_alignment)] ... }
  • match self.color { //! The `format!()` [macro] lets us create a `String` with a pattern, ... }
  • match *self { #![allow(unknown_lints,match_same_arms)] ... }
  • match mdid { #![allow(clippy::unreadable_literal)] }
fn main() {
    let color = 4;
    match color {
        //! The `format!()` [macro] lets us create a `String` with a pattern, ...
        _ => (),
    }
}
  • simulacrum: if this helps compiler performance on 99% of the code, and it doesn't have a meaningful interpretation today
  • nikomatsakis/cramertj: it has a meaningful interpretation to me...
  • simulacrum: well in any case, it seems like it might be worth it?
  • nikomatsakis: Is the motivation here performance? I had thought maybe it was something else, i.e. that it wasn't correctly implemented today?
  • nikomatsakis: I'm going to leave a concern noting that I am not clear on motivation
  • scottmcm: how bad would it be to accept these but ignore them and emit a diagnostic saying that they have no meaning?
  • various: why not just support them then?

Example: this works (lint is suppressed)

fn main() {
    let x = Some(22);
    match x {
        #![allow(unused_variables)]
        Some(y) => { }
        None => { }
    }
}

"Stabilize extended_key_value_attributes" rust#83366

Link: rust-lang/rust#83366

  • question about arbitrary expressions. PR stabilizes lexing arbitrary expressions in that position.
  • nikomatsakis: why is that a concern for lang team? perhaps hygiene?
  • nikomatsakis: generally feel like it should be okay to allow arbitrary expressions
  • cramertj: should we worry that these macro invocations look like things that are expanded eagerly?
  • cramertj: but doc = ... and path = ... "just work" via compiler-magic.
  • nikomatsakis: right, they are not macros. (Though maybe they could become macros in the future.)
  • cramertj: just concerned that someone might think they can use some macros here and think that they will be expanded eagerly.
  • cramertj; Having this feature and not having eager expansion just feels funny to me.
  • nikomatsakis: (do procedural macros accept that form?)
  • cramertj: (yes. I think. E.g. parsing equals of attributes attached to fields)
  • nikomatsakis: but what about the macro invocation itself?
  • cramertj: oh I don't think those would work in a procedural macro (today).
#[derive(StructOpt)]
struct Foo {
    #[data = include_str!(...)]
    field: u32
}
  • but this example would work because string is only needed at runtime
    • what would not work is if the string is needed at compile time
  • scottmcm: does this allow, say, #[foo = +(3)] since that could tokenize fine but isn't an expression?
    • Should it be tt* or actually expr?
    • niko's "theory": arbitrary tokens will lex, but not parse, but let's discuss it in thread
  • nikomatsakis: seems like it parses the expression
  • mara: the StructOpt example above does not actually work today

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

Link: rust-lang/rust#83386

  • settled on "pat_param" as a name, but still deciding about whether to provide "pat2021"

  • mara: point of keyword literals is to enable people to write expected keywords without waiting for an edition, not about adding it after the edition is available.

  • joshtriplett: providing a pat2021 is motivated by wanting to allow future editions to make further changes to what pat means, and since we do not know what those changes are today, the only thing we can call it is pat2021

  • mara: that sounds like an argument for not having pat2021 at all

  • joshtriplett: it is an argument if you want to write references to pat2021 in 2015 or 2018 edition code.

  • nikomatsakis: felix has often argued for always having a way to specify what you want, even if you rarely use it

  • scottmcm: does it suffice to say "we give you a way, but only in the latest edition"?

  • (debate followed)

  • mara: Note that $($_:pat_param)|+ works in all editions

  • Agreed:

    • pat_param -- pat without |
    • pat -- pat without | <=2018, pat with | 2021+

  • Question:

    • do we have pat2021 that is 'pat with |' in all editions

  • Reason to do so:

    • It is nice if older editions can access newer semantics, albeit with a more confusing way

  • Reasons not to do so:

    • (a) they can acccess the newer semantics by doing $($p:pat)|+ (or by upgrading to the newer edition)
      • But: this is significant more complex and they may well make a subtle mistake
        • But: macros do this today
      • But: why not adopt newer edition? probably because want support for old compiler
    • (b) newer editions have no use for this because it's just the same as pat
    • (c) if we add a new variant of pat, we can give it a meaningful name like pat_param at that time
    • (d) cruft, YAGNI
      • It would be a shame if we ended up with a big list of pat2021, pat2027, ...

  • Precedent:

    • we tend to give years for 'old names that are deprecated but retained for backwards compat'

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

Link: rust-lang/rust#83595

  • putting #[repr(align)] on a field was accepted but did nothing
  • now rejected
  • scott thinks we agreed to this breakage before, so does mark
  • action item: scott to leave comment

breakage discussion: rust-lang/rust#80920 (comment)

"Stabilize "RangeFrom" patterns" rust#83918

Link: rust-lang/rust#83918

"Deny float matches" rust#84045

Link: rust-lang/rust#84045

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

Link: rust-lang/rust#84133

"Add expr202x macro pattern" rust#84364

Link: rust-lang/rust#84364

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

Link: rust-lang/rust#84414