Niko to cancel, hasn't had time to prepare.
#[expect] attribute" lang-team#191fn { mod { (use) super::...; } } and its interaction with derive patterns" lang-team#193pnkfelix: Opsem discussion. I'm worried that "if miri can't detect it, it can't be UB" as a potential tenet, not convinced that's the right way to look at the problem, but also not prepared to make a doc. Should we consider an informal discussion tomorrow?
tmandry: I'd want to hear from Jacob.
pnkfelix: it's blocking this PR and I don't want it to sit in limbo.
nikomatsakis: it seems like we gotta get Ralf and Jacob in the room. Ralf was the one who suggested copy propagation. I don't know how to square undefined struct layout with miri having to detect everything.
scottmcm: The guideline of being able to detect things is a good thing, but I don't see how it can be a hard rule.
nikomatsakis: TAIT might be another option, maybe we can get all stakeholders together for that? Ping oli? Who else would we want? Josh. Let's circle back after we move a bit further.
None.
None.
None.
Check your boxes!
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @Amanieu
- @BurntSushi
- @dtolnay
- @joshtriplett
- @m-ou-se
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot merge
Active conversation on Zulip and amidst libs forums. Maybe not an obvious check.
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
change-syntax-to-drop-parenthesesresolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974maybe-make-this-part-of-next-editionresolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311- syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot merge
Concern was raised, under discussion on Zulip.
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
I do think we should permit
br"¥¥¥", but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.I'm going to go ahead and propose FCP for this. This does not preclude making further changes to how this information is presented.
@rfcbot merge
@rfcbot concern raw-byte-strings-with-unicode
Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:
- @Amanieu
- @BurntSushi
- @dtolnay
- @joshtriplett
- @m-ou-se
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
After working on the OOM handler for a while, I think that the best way to move forward is to just treat OOM as a normal panic (so that it calls the normal panic handler/hooks). This is what already happens on
#![no_std]since https://github.com/rust-lang/rust/pull/102318 was merged.I believe that we should do the same for the
stdcase. Specifically:
- The unstable
#[alloc_error_handler]is removed.alloc::alloc::handle_alloc_errornow always invokes the panic handler.- For backwards compatibility reasons, this is a non-unwinding panic. Unsafe code may not be written to correctly handling unwinding out of a memory allocation (this is in fact a frequent source of bugs in C++!). However this behavior can be overridden with
-Zoom=panicwhich changes the behavior to a normal unwinding panic.- Since there is no separate handling for OOM any more, the unstable OOM hook API in the standard library can also be removed.
@rfcbot fcp close
glandium from Mozilla raised a concern about needing access to the size of the failed allocation.
Amanieu investigating giving access via custom playload (though still ordinary panic handler).
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
Concerns:
- docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
- function-defining-uses (https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot fcp merge
This has been a long-time coming. Let's Do This!
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
Shall we stabilize the
extern "C-unwind"and other-unwindcalling conventions? This change will leaveextern "C"unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to makeextern "C"and similar not permit unwinding.@rfcbot merge
nikomatsakis resolved concern.
Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
- @cramertj
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
Concerns:
expectations-around-panics-in-inline-constresolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210- optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
post-monomorphization-errorsresolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779- should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
@rfcbot fcp merge
we had a meeting. still not really resolved.
scottmcm: is anybody making progress on actually changing what we check here? I don't understand. There was a zulip thread in https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Preserving.20monomorphizations.20despite.20const-prop/near/338685200, but it's not had any updates recently.
tmandry: #108730, run all analyses in check mode. Had some perf impact on the order of 5%.
scottmcm: wall-time says 8%, but just for check (full). debugs/opts (full), no impact. Makes sense, by the time you're emitting code, you're already doing this work.
nikomatsakis: it sounds like we want to write up a plan to report all errors and we are not ready to stabilize yet. Can we cancel this FCP since we are not ready to move forward and instead open an issue that says what we want to resolve specifically?
tmandry to author a comment on #108730 saying lang team considers a bug fix.
anonymous_lifetime_in_impl_trait" rust#107378Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
@rfcbot merge
We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.
We currently allow this, right?
fn foo(x: impl Fn(&u32))
Cases to consider:
impl Fn(&u32)impl PartialEq<&u32>impl Iterator<Item = &u32>impl Foo<'_>other things is
where T: Fn(&u32)where T: PartialEq<&u32>also we apparently (accidentally?) support this syntax with async functions
nikomatsakis: sometimes I wishthat impl Foo<'_> meant impl for<'a> Foo<'a>, but that wouldn't work with Iterator<Item = ...>
scottmcm: I see the logic that if you don't want to give it a name, you probably meant for it to work with all lifetimes
conclusion:
tmandry to author a comment asking for one
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- explicit-alternative (https://github.com/rust-lang/rust/issues/107645#issuecomment-1469979788)
- why-not-just-the-return-type (https://github.com/rust-lang/rust/issues/107645#issuecomment-1468796621)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot fcp merge
I propose that we accept https://github.com/rust-lang/rust/pull/107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.
Final behavior as I understand it
- A TAIT has a defining scope that corresponds to the enclosing module or item.
- A defining use for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
- Within the defining scope, an item is called constraining if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a
let(e.g.,let x: TAIT = 22_u32), a return (e.g.,return 22_u32in a function whose return type isTAIT), or in other ways.- Any constraining item within the defining scope that is not a defining use is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
- All defining uses must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
- WIthin the defining scope, TAITs must always be given generic arguments (e.g.,
fn foo<T>() -> TAIT<T>and notfn foo() -> TAIT<u32>). This ensures inference is tractable and well-defined.Current bugs and limitations (forwards compatible to change)
- Within the defining scope, attempts to check whether
TAITimplements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.- A function that has an argument which is an associated type referencing a TAIT (e.g.
<TAIT as SomeTrait>::SomeItem) ought to be considered a defining use. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.@rustbot labels -I-lang-nominated
type Foo = impl Trait;
fn some_function() -> Foo { }
fn some_function(f: Foo) { }
-> Foo as a legal defining use#[defines(Foo)] fn some_functionNiko proposed ATPIT as a concerete, but even there, there are some questions, e.g. is this ok
impl SomeTrait for Bar {
type Foo = impl Debug;
fn foo(&self) {
let f: Self::Foo = 0u32;
}
}
pnkfelix: oh dear god the acronyms, don't do this to us
tmandry: if we did do #[defines], would you want it also at the impl level?
nikomatsakis: depends if you think of an impl as a "mini-module", in which case I think it seems consistent, or as a small unit. I tend to think of it as the latter. In a module, I feel like there are often various bits of code put together, and so having #[defines] link to the associated type is nice-ish.
mod some_module {
type Foo = impl Debug;
#[defines(Foo)]
fn bar() -> Foo {
}
fn baz() {
}
}
tmandry: I think the inconsistency will be hard to explain, but I also think it's usually not needed in impls
pnkfelix: some impls get large, I could imagine it (the attribute) being useful to search for
scottmcm: can't you search for the name of the associated type… wait, what happens with this case?
impl Add for T {
type Output = impl Debug;
fn add(self, rhs: Self) -> u32 { … } // Defining use?
}
Is it a "mention" because it's used in the trait definition for that position? Or only if it's there lexically in the impl?
nikomatskais: currently, the check that impl matches trait is done without knowledge of hidden type, so that example does not build, you have to write Self::Output:
tmandry: would it help to list out the use cases …?
impl IntoIterator {
type Item;
type IntoIter = impl Iterator<Item = Self::Item>;
}
impl Service for Something {
type Future = impl Future<Output = ...>;
fn service(&mut self) -> Self::Future {
async move {
...
}
}
}
Question we need to answer:
- Are there any use cases that do not involve the opaque type appearing in the return type or in the type of a const/static?
- Arguments in favor of defines instead of just return position (answer is primarily if you want to scale to other positions?).
- What are all the patterns?
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @tmandry
Concerns:
- types-team-input (https://github.com/rust-lang/rust/pull/108782#issuecomment-1477170467)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
@rfcbot fcp merge
Discussed in a (minimally attended) lang-team triage meeting and we are in favor of moving forward with this.
blocked on a concern.
Link: https://github.com/rust-lang/rfcs/pull/3391
Link: https://github.com/rust-lang/rust/pull/104299
FnPtr trait that is implemented for all function pointers" rust#108080Link: https://github.com/rust-lang/rust/pull/108080
Link: https://github.com/rust-lang/rust/pull/109010
None.
Link: https://github.com/rust-lang/rfcs/pull/3295
remove nomination, scottmcm is to kick off a FCP
tmandry asks the dreaded question: "why now"
scottmcm: biggest reason honestly is "it's had all the conversation it's going to have, no new information, let's reach a decision". I'd use it occasionally, but I don't think anyone is wrong to say "you don't really need it".
tmandry: what about temporary lifetimes?
nikomatsakis: really interesting point. I wonder if people's expectations are different.
scottmcm: another point that was raised is auto-ref, RFC currently says no. But it's similar.
nikomatsakis: another question, what is the "killer use case", I think maybe try/match
scottmcm: for me, map-or-else, because that always make me sad, two closures in the wrong order and not understood by borrowck
nikomatsakis hates map-or-else with the passion of a thousand fiery suns
tmandry: if RFC were extended with answers to the below, I would be comfortable making a decision:
nikomatskis charges scottmcm to follow-up.
Link: https://github.com/rust-lang/rust/pull/108993
This PR modifies the unreachable code lint to operate from within typeck, based on inhabitedness of types discovered as the analysis goes. As a consequence, the lint fires in many extra places. Constructors are carved out on purpose, to avoid an "unreachable call" diagnostic on them, which is not very useful as they are inert.
nikomatsakis: we probably won't conclude this, but I definitely want a better understanding of what this PR actually does. hard to tell what unexpected interactions may result.
pnkfelix: skimming the output, I like the idea that it's showing we already had code that was unreachable, but now we give a better result, e.g., it's telling you "it had this type, which is uninhabited".
tmandry: do people know what uninhabited means?
pnkfelix: "which cannot be constructed"
scottmcm: sounds like visibility
pnkfelix: "which has no value"
scottmcm: as long as "uninhabited rust" hits the right thing in google? or verbose error?
pnkfelix: how about we retag it T-types? can we come to general approval?
nikomatsakis: I feel like wearing either hat I don't know what I'm approving. I know it's taking inhabitnedness into account but I don't know exactly how.
tmandry: No blocking concerns that come to mind, but I'd like someone to explain if there's anything we should be looking at carefully.
scottmcm: std-err diffs seem reasonable, but there are only two of them.
#[diagnostic] attribute namespace" rfcs#3368Link: https://github.com/rust-lang/rfcs/pull/3368
looks like last time we identified design meeting as a next step?
pnkfelix: do we want to identify a champion?
tmandry: seems like we are not on same page as a team, Josh gave advise towards versioning, I didn't like it
tmandry: I can file a meeting for a design meeting proposal but keep it light on the requirements
nikomatsakis: we can read rfc or a subset of it
Link: https://github.com/rust-lang/rfcs/pull/3325
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe