Skip to content

Latest commit

 

History

History
357 lines (249 loc) · 14.6 KB

2021-06-29.md

File metadata and controls

357 lines (249 loc) · 14.6 KB
Raw
title tags
Triage meeting 2021-06-29
triage-meeting

T-lang meeting agenda

  • Meeting date: 2021-06-29

Attendance

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

Meeting roles

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

Scheduled meetings

Action item review

Pending lang team project proposals

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

Link: #86

  • Pending action item: Niko to complete his notes

"negative impls integrated into coherence" lang-team#96

Link: #96

  • FCP has expired, needs to be converted and added to project board

"Trait Upcasting" lang-team#98

Link: #98

  • 7 days into FCP

"Discontinue meeting recordings" lang-team#100

Link: #100

  • 5 days into FCP
  • Reasoning
    • Recordings can be stifling or exclusionary
      • Having everything be public can be exhausting, have to watch your wording, particularly if making jokes
      • Occasionally people will dig up time codes to explain the reasoning
      • People don't want to lose control of their recordings
    • Other teams within Rust governance are not recording their meetings for the most part, with some exceptions
      • e.g., library team does not, compiler team does not (and some members of both have concerns)
    • Minutes with reasoning should suffice, and if not, we should do better
    • Difficult to discuss sensitive topics
      • Sometimes these topics arise independently
    • Uploading and maintaining records is a time investment
  • Questions raised in the thread
    • Design meetings
      • May be more valuable here-- for triage, it's clear that we ought to be capturing our reasoning and limited the amount of time we spend on any individual topic
      • Exception: if we do a talk where someone has prepared a "broadcast", we can decide for any given meeting to record
  • Alternatives
    • Private recording
    • Recordings available to the lang team
    • Setting aside time for private conversations at the end
  • What do we lose
    • Engagement, potentially, for folks who are not into blog posts
      • We could recover this in other ways, e.g. a podcast sort of thing
      • Could connect to existing podcasts for that

PRs on the lang-team repo

  • Action items noted for relevant PRs; nothing to discuss

"Initial draft of copy ergonomics design note" lang-team#62

Link: #62

  • still needs work to revise (waiting on Mark)

"Autoref/autoderef for operators" lang-team#63

Link: #63

  • Waiting on Scott

"Auto trait design note" lang-team#69

Link: #69

  • Waiting on Niko

"Add design notes for function-type Default implementation discussion" lang-team#71

Link: #71

  • Waiting on Niko

"Add draft of variadic notes" lang-team#76

Link: #76

  • Waiting on author to revise after comments by Taylor

Proposed FCPs

Check your boxes!

"Calling methods on generic parameters of const fns" rfcs#2632

Link: rust-lang/rfcs#2632

  • Pending action item: Niko to resolve

"RFC: Add target configuration" rfcs#2991

Link: rust-lang/rfcs#2991

Conclusion from last meeting:

  • Niko to drop concern about matching the entire target string (done)
  • Josh will leave his concern in place regarding shorthand until is added
  • Conclusion:
    • We expect the "combined string" to match the behavior of the "longhand" variables.
    • But when we introduce an alias we can decide the specific values of the "longhand" variables

This meeting:

  • Discussion about what to do in the case of aliases; settle this as part of the discussion introducing the alias.
    • pnkfelix: Would "pc" be mapped to unknown in all contexts? Or just in the case of that one target triple?
    • joshtriplett: The proposal (if accepted) would map the entire target triple, not just the component

"#[derive(Default)] on enums with a #[default] attribute" rfcs#3107

Link: rust-lang/rfcs#3107

Pending FCP to allow #[default] to select the variant when deriving Default:

#[derive(Default)]
enum Option<T> {
    #[default]
    None,
    Some(T),
}
  • Note that, in this case, #[default] is only allowed on variants with no data and it does not include a T: Clone bound for generics
    • Scott: There is an inconsistency with other derives, all of which would like to be able to exclude the T: Clone bound, why separate this case?
    • Mara: This one is specific to a particular variant, and the behavior would always be wrong
  • Combined lang/libs FCP

"RFC: let-else statements" rfcs#3137

Link: rust-lang/rfcs#3137

  • In FCP; had a concern (ambig grammar) that is now resolved
  • Had a lot of discussion and these things are covered under alternatives
  • Comments:
    • using postfix procedural macros could make it nice
      • let x = foo.unwrap_or_else! { ... } -- only works for Option or Result, but this is useful for all kinds of enums, and also more complex nested patterns
        • Niko would like this to work by allowing you to return from the closure, but that's another story
      • scottmcm comment on this: rust-lang/rfcs#3137 (comment)
        • With what I think is a nice examples of something that's not option/result
    • How typical is this, is match so bad, shouldn't we just use a macro? (Aaron1011's concern)
  • Scott, digging a rabbit hole:
    • One might misunderstand this syntax:
      • let x = None else { 3 }; // x == 3. ?? in C#, ?: in Kotlin
      • You could imagine that else is like None.unwrap_or(3)
        • "Yes"
        • Josh: there has been conversation about this sort of thing in the past
      • Some brainstorming about how this syntax will "feel"
        • Also whether one can make a set of orthogonal features that all play nice with each other
  • Meeting consensus:
    • Allow FCP to continue
  • General desire for clippy lints to help people migrate

"Tracking issue for RFC 2523, #[cfg(version(..))]" rust#64796

Link: rust-lang/rust#64796

  • Still waiting on Josh's concern
  • Nothing to discuss right now

Active FCPs

"Stabilize "RangeFrom" patterns in 1.55" rust#83918

Link: rust-lang/rust#83918

  • In FCP for partial stabilization
  • Excludes patterns from slices:
    • we've said in the past we would be ok to stabilize, but if PR author wants to hold back, seems ok

"negative impls integrated into coherence" lang-team#96

Link: #96

  • Existing action item: Niko to "merge" negative impl coherence #96

"Trait Upcasting" lang-team#98

Link: #98

  • Seconded, 3 days out from fcp period finishing. No discussion needed just now.

"Discontinue meeting recordings" lang-team#100

Link: #100

  • Already discussed, see above

Nominated RFCs, PRs and issues

"Add expr202x macro pattern" rust#84364

Link: rust-lang/rust#84364

  • No change, still waiting on pnkfelix to sharpen request I believe --nikomatsakis

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

Link: rust-lang/rust#84414

  • Consensus from last meeting:
    • We shouldn't leave this open
    • Some people have mild preferences one way, some the other
    • Don't have a full quorum for the team here, wait a bit
  • nikomatsakis was curious to get a "straw poll"
  • nikomatsakis: Would like to allow macros in more places; this example would be even clearer like this, imo, and it would add more capabilities:
#[derive(Something)]
struct Foo {
    expand_members!()
}
  • scottmcm: because it's all in the macro anyway, it could do arbitrary tokens too?
enum Foo { .. from header .. }
  • Consensus:
    • Lacks a strong champion
    • Several people are confused (others not)
    • Prefer to explore allowing macros in that position, or other solutions
  • Josh to open action item

"implement Default for all arrays" rust#84838

Link: rust-lang/rust#84838

  • Consensus from last meeting:
    • fcp merge, Niko to write-up (didn't happen yet)
  • Concern about maintenance from a libs perspective:
    • This is very complex and hacky
    • Would we really want to maintain it long term?
  • Concern: if this is opened for Default, won't we be getting PRs for all the other cases?
    • Answer: quite possibly!
  • Josh: to separate out, from a lang team perspective, we don't object in particular to this hack
    • But the libs team in its role as implementor is free to say this is too hacky to maintain.
    • Niko: I'm convinced by that, it was a close call
  • We'd be happy to review a proposal that puts more into the lang/compiler to make this more maintainable from a library perspective.
  • New action item to fcp close:
    • nikomatsakis can do it

"Check for union field accesses in THIR unsafeck" rust#85263

Link: rust-lang/rust#85263

  • Next step:
    • Someone to review and prepare summary-- nikomatsakis is assigned but hasn't had time

"Fix how allow/warn/deny/forbid warnings is handled" rust#85298

Link: rust-lang/rust#85298

OP:

This pull request attempts to fix #41941, fix #70819 (the command line part, which is why the issue was reopened), and fix #75668. The current implementation of warnings (as in -D warnings or #[allow(warnings)]) is "lazy" in that warnings is not considered by the linter until it is about to emit a warning, in which case it checks whether an allow/deny/forbid of warnings is in scope and up-/downgrades the warning accordingly.

The problem with this approach is that one can never get an (e.g.) #![allow(warnings)] out of scope again except by shadowing it with another #[warn/deny/forbid(warnings)]; ideally, though, one would also want more fine-grained control, such as

#![allow(warnings)]

fn main() {
    #[warn(unused)]
    let a = 5;
}

which compiles without warnings and errors on current nightly but causes a warning with my changes (as one would expect, I would argue).

...

I've also worked on the command line arguments: Calling rustc with -F warnings -A unused works without errors or warnings on current nightly; with my changes, I get

warning: allow(unused) incompatible with previous forbid
  |
  = note: `#[warn(forbidden_lint_groups)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #81670 <https://github.com/rust-lang/rust/issues/81670>
  = note: `forbid` lint level was set on command line

Mark:

I don't think this patch can be accepted as-is because it breaks the common (though sort of "incorrect" from first principles in some sense) pattern of specifying #![warn(...)] or -W... on some lints, perhaps additional, perhaps replacing allow at 'higher' levels, and then using -Dwarnings to change all of them to errors, independent of why they're being emitted. To some extent, I guess this desire is basically a "inverse cap-lints", but not quite rust-lang/compiler-team#434.

I suspect changes here are going to want to go through an RFC or at least some sort of broader consideration (nominating for @rust-lang/lang), because it seems like the design space here is somewhat broad and there is likely some amount of breakage to consider.

  • Niko's proposal:
    • Make this into an active project, if there is a liaison

"Stabilize bindings_after_at" rust#85305

Link: rust-lang/rust#85305

  • Stabilization report
  • TL;DR:
    • We removed this back in the old AST borrowck days as a 'quick hack' to get to 1.0
    • The MIR borrow checker can handle it no problem
  • nikomatsakis went ahead and did a FCP merge

"Stabilize const_fn_transmute, const_fn_union" rust#85769

Link: rust-lang/rust#85769

Stabilization report:

RFC 3106 permits undefined behavior in const evaluation, with the summary being the following:

Define UB during const evaluation to lead to an unspecified result or hard error for the affected CTFE query, but not otherwise infect the compilation process.

This pull request stabilizes the const_fn_transmute and const_fn_union feature gates. Both transmute and union are presently stable in const and static statements, but not in const fn. This PR is the first to invoke the aforementioned RFC to my knowledge. These features are relied upon in the test suite, though strictly speaking this is somewhat unnecessary (as behavior when UB is present is by definition not defined). Some cases throw a compile-time error while others will succeed and have undefined behavior.

"Associated functions that contain extern indicator or have #[rustc_std_internal_symbol] are reachable" rust#86492

Link: rust-lang/rust#86492

struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}
  • This code doesn't have foo exported
  • Should it?
  • petrochenkov thought perhaps it should be an error
  • No evidence of whether this is used in the wild or not