owned this note   changed 3 years ago  
Published Linked with GitHub

T-lang meeting agenda

  • Meeting date: 2021-12-14

Attendance

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

Meeting roles

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

Scheduled meetings

Announcements or custom items

Action item review

Pending lang team project proposals

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

Link: https://github.com/rust-lang/lang-team/issues/96

"Deprecate target_vendor " lang-team#102

Link: https://github.com/rust-lang/lang-team/issues/102

"Async fundamentals initiative" lang-team#116

Link: https://github.com/rust-lang/lang-team/issues/116

"Attribute for trusted external static declarations" lang-team#118

Link: https://github.com/rust-lang/lang-team/issues/118

"Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121

Link: https://github.com/rust-lang/lang-team/issues/121

"Support platforms with size_t != uintptr_t" lang-team#125

Link: https://github.com/rust-lang/lang-team/issues/125

"Positional Associated Types" lang-team#126

Link: https://github.com/rust-lang/lang-team/issues/126

"Heap allocations in constants" lang-team#129

Link: https://github.com/rust-lang/lang-team/issues/129

PRs on the lang-team repo

None.

RFCs waiting to be merged

None.

Proposed FCPs

Check your boxes!

"Tracking issue for RFC 2115: In-band lifetime bindings" rust#44524

Link: https://github.com/rust-lang/rust/issues/44524

"Change location of where clause on GATs" rust#90076

Link: https://github.com/rust-lang/rust/pull/90076

Active FCPs

"Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586

Link: https://github.com/rust-lang/rust/pull/90586

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

Link: https://github.com/rust-lang/lang-team/issues/96

"Positional Associated Types" lang-team#126

Link: https://github.com/rust-lang/lang-team/issues/126

  • Needs a tracking issue, too.

P-critical issues

None.

Discussed RFCs, PRs, and issues

"Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586

Link: https://github.com/rust-lang/rust/pull/90586

In FCP, doesn't need to be nominated. Nomination removed.

"Make specifying repr optional for fieldless enums" rust#88203

Link: https://github.com/rust-lang/rust/pull/88203

  • One of that "group" of things we've been looking at.
  • jswrenn was going to "say something" here but pnkfelix didn't finish following up yet.
  • Removing nomination as the next immediate step is the action item.

"Allow using $:literal containing integer to index into a tuple" rust#91166

Link: https://github.com/rust-lang/rust/pull/91166

  • Discussed previously, petrochenkov and dtolnay are in discussion.
  • nikomatsakis: I agree with the goal as described in the PR header
  • joshtriplett: should we post a statement that we agree with the goal but would like dtolnay/petrochenkov to figure out the best strategy
  • scottmcm: feels like the kind of thing where "if petrochenkov/dtolnay agree, I would agree"
  • pnkfelix: they don't yet, right?
  • joshtriplett: no, they both understand how it works, and are disagreeing about the best next step
  • pnkfelix: what about the behavior of 0.0?
  • nikomatsakis: x.(0) is another edge case that petrochenkov raised
    • joshtriplett: I don't think he was suggesting it should work,
  • scottmcm: I'd like to discuss the float thing. I'm not sure what my "mental expectation" is here…
  • nikomatsakis: that gives an error, and dtolnay
  • scottmcm: but why is that an error, and how is it different from 0?
  • nikomatsakis: but 3 levels is definitely an error, right?
macro_rules! m {
    ($thing:ident . $float:literal) => {
        $thing . $float
    };
}

fn main() {
    let x = ((('x',),),);
    let _ = m!(x.0.0.0);
}
  • nikomatsakis: I think that my 'mental model' for how x.0.0 works is that 0.0 is a bunch of small bits that are built up into a f32
  • joshtriplett: I don't think that is how it works today
  • nikomatsakis: yeah, and I think we can't fix that easily (because proc macros can see the difference etc)
  • nikomatsakis: there is no backwards compatiblity question here, right? specifically, it will always take the same arm, it's just a question of whether the match arm gets an error once it compiles.
  • joshtriplett: potentially a surprising gap then, but not back compat.
  • scottmcm: I think I would not expect floats to work, but by that same logic I don't expect ints to work
  • nikomatsakis: what happens with tt… this works
macro_rules! m {
    ($thing:ident . $float:tt) => {
        $thing . $float
    };
}

fn main() {
    let x = ((('x',),),);
    let _ = m!(x.0.0);
}

pnkfelix $(tt).+: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c3331fa3b172f545d3b54e043078f80c

  • nikomatsakis: it fails because of the synthetic parens we introduce to manage to avoid $a = a + b having weird behavior here..
macro_rules! m {
    ($a:expr) => {
        $a * 3
    };
}
  • nikomatsakis: I think I agree with scott that either you can see a literal as equivalent to its underlying token or you can't; so the 0.0 example should work
  • simulacrum: I could see it being somewhat different. A 0 is kind of viewable more as an "identifier" than a float to me. I feel like accepting 0 as a token allows you to do whatever you want, but accepting it as a literal you have to use it as a literal.
  • nikomatsakis: I'm not sure if dtolnay is fixing the problem the right way
  • cramertj: it seems like they're not trying to match a literal, that's the wrong way to do that thing
  • pnkfelix: as in, what should the category be for the projection argument?
  • cramertj: right, they're literally not matching a literal here, they're matching a "post expression selector" or something –- you could imagine something that supports indexing operations, for example. I assume they didn't intend to support that here, but it seems like they're trying to do a specific custom thing that isn't what literal is for.
  • scottmcm: certainly I wouldn't expect 0.0e0 to work
  • joshtriplett: Or tuplename."string literal"
  • nikomatsakis: it may be that they're trying to have different arms for "tuple field" vs "other field", and hence they're not using tt
    • the main reason I can see to not use tt is if you really want tuple fields here
  • cramertj: even so, it seems like literal is not what you want, it's a hack to get that behavior
  • nikomatsakis: I feel like the right fix is new forms of fragment specifics for different kinds of field names
    • e.g. named field, numbered field, method call, etc
  • code snippet: https://github.com/dtolnay/anyhow/blob/1.0.51/src/ensure.rs#L306-L312
  • pnkfelix: we should go back to dtolnay and see what the use case is
  • joshtriplett: who will summarize into the issue?
  • scottmcm bravely steps up
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →

"remove pref_align_of intrinsic" rust#90877

Link: https://github.com/rust-lang/rust/pull/90877

  • Lokathor: I recall the result of last meeting was "leave this on nightly, why the urgency"
    • can we comment on this and un-nominate?
    • it has a use case (c2rust)
  • nikomatsakis: I'd be ok with that, I'd be opposed to removing it unless there's a good alternative to that use case
  • joshtriplett: if someone argues it can't be stable, that'd be another good argument to remove, but not obvious why we couldn't stabilize it
  • Action Item: joshtriplett to summarize and de-nominate

"Unreachable code is not borrow-checked" rust#91377

Link: https://github.com/rust-lang/rust/issues/91377

  • nikomatsakis: I think this is working as designed, for better or worse, it was hard to decide precisely what set of errors you were going to get in code like that and we decided to just run with it.

"Mark defaulted PartialEq/PartialOrd methods as const" rust#91439

Link: https://github.com/rust-lang/rust/pull/91439

  • Adds a (perma unstable) #[default_method_body_is_const] attribute
  • We believe the behavior of this is
    • whole trait impl can be marked const (or not)
    • this attribute means "if the whole impl is marked const, this default won't break it"
    • i.e., you get to assume current trait impl is const, and you check that fn is const under that assumption
  • cramertj: alternative would be track which methods get called and know that it is const if those functions are const
  • lokathor: I believe individual const fns off of the trait would be a potential future extension
  • cramertj: right, but that's probably soemthing we want, right?
  • joshtriplett: all this issue is asking us is
    • are we prepared to commit to the idea that if you impl Eq and you eq method is const…
  • cramertj: …but that's not actually the condition, it's actually whether the impl is const
  • nikomatsakis: I also don't think there's any commitment; if we stabilized const impls, then we would be committed, but we haven't yet
  • joshtriplett: second paragraph:
    • "if we stabilized any const traits that used this feature, we're commiting to having this mechanism or some other mechanism that makes this feature possible"
    • "in the meantime, until we stabilize a const trait, we're not committing to anything"
  • nikomatsakis: I'd like to know how we're recording these kinds of implications, I know there's a repo
  • joshtriplett: do we need an FCP or just
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
  • nikomatsakis: I think a
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
    suffices, this feels like a "check in" from active initiative that doesn't require full consensus
  • joshtriplett: then perhaps we should ask the question of where the assumption is recorded that we need to evaluate this before stabilizing const trait impls
  • nikomatsakis: let's say we're good with it as long as the assumptions are recorded somewhere for future evaluation
  • simulacrum: I want to write a comment!
  • joshtriplett: No me! I'm already writing it!
  • nikomatsakis: :brain-exploding: 🤯 ETOOMANYVOLUNTEERS?! what just happened?!

"New declarative macros, functions and fields not being recognized" rust#91249

Link: https://github.com/rust-lang/rust/issues/91249

  • nikomatsakis: Seems like this is saying "we need an RFC for hygiene, it is clear that strictly saying 'all names are local to the macro' is going to be confusing when you have non-lexical lookup like this one".
  • joshtriplett: I feel like we should tag this as the tracking issue
  • nikomatsakis: I feel like this is obvious– how is type-based dispatch going to work. Also how are things non-hygienic.
  • joshtriplett: well, you might want to have methods that are "hidden" outside the macro, right?
  • scottmcm: isn't that a fn?
  • nikomatsakis: not necessarily, but I feel like if I were going to enumerate a list of things, I would defintiely have put "type-based dispatch" on the list of things to consider.
  • scottmcm: I think that because I can call (or implement) a trait method without having imported its name specifically, it doesn't feel like a hygiene issue to me.
  • joshtriplett: we need to link this from macros 2.0 tracking issue and either close it or leave it open, but de-nominate it.
  • https://github.com/rust-lang/rust/issues/46342 is basically the same bug, just different context
  • see also https://github.com/rust-lang/rfcs/pull/2498

Nominated RFCs, PRs and issues

Select a repo