(Meeting attendees, feel free to add items here!)
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:
- @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!
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
tmandry: Took an initial look, want to go over everything again to see if there's anything that jumps out.
Link: https://github.com/rust-lang/rfcs/pull/3346
Link: https://github.com/rust-lang/rust/issues/63063
Link: https://github.com/rust-lang/rust/pull/104087
josh: Lots of back and forth over what the RFC precisely means. Not necessarily a blocker.
None.
format_args invocations to uses captures" rust#106505Link: https://github.com/rust-lang/rust/pull/106505
Should format_args! invocations that were generated by a proc-macro be able to use implicit argument captures?
tmandry: My expectation is yes if the span comes from code that can name the variable.
josh: Sounds like that requirement didn't exist before, and now I'm not sure we can break backward compat.
josh: Two pieces of evidence for things that would break: indoc and …
tmandry: Is this a feature for them or accidentally relying on it?
josh: Doesn't sound accidental.
mark: Seems like this PR is checking whether a person actually wrote a literal in source, which seems like the wrong direction. Macros should be able to concoct their own source literals
tmandry: Agreed (as long as the span is correct)
mark: RFC 2795 restricted to source literals because it might be too confusing, but if your macro expands to a format args string it seems like it should just work.
josh: Don't necessarily want to build an expectation that other macros will work based on concat!() working.
mark: But if you have a proc macro and it attaches the correct span it should work.
tmandry: Fine with summarizing the point about what it seems like the ideal behavior would be and why it's feasible, and asking for clarity here.
mark: Maybe worth reverting PR since it breaks actual crates, instead of fixing rare ICEs. Top priority is fixing nightly. (tmandry: Will do.)
y86: Seems like this PR (to fix the ICE) is between the RFC and what was there before.
https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
Link: https://github.com/rust-lang/rfcs/pull/3240
josh: Idea is to allow changing signature of a method in, or avoid introducing a method until, an edition.
tyler: How would this help with preventing conflicts with existing methods in extension crates?
josh: We'll defer the breakage to an edition and batch them there. Not necessarily the tool we have to use every time – I think we should look at whether something would have widespread breakage and decided to use it then.
josh: We had a hack for []::into_iter(), this is a more general solution for something like that.
mark: Someone mentioned tagging T-compiler, though I'm not sure that's necessary. Perhaps we should ask petrochenkov as the resolution expert.
josh: Also we should do the work to cc lang advisors on any RFC that involves t-lang (when FCP is initiated).
mark: Easiest way to do that is in triagebot. Something in label-based automation. Hard part is doing it across the org automatically.
mark: Will take a look.
felix: Question about meaning of "crate matches the new edition" wording.
josh: I think that should mean "matches that edition or newer". If you think it could be more clear, please comment or leave a suggestion.
josh: Two cases are <, and >=.
Link: https://github.com/rust-lang/rust/issues/106617
felix: Asking what the desired semantics are.
josh: I would expect that it should always be evaluated
felix: Do we want this only if it's monomorphic? / Are we stuck in a world where we have to handle monomorphic functions specially?
mark: In const items you can't use generics. In const blocks you can, so we never eagerly evaluate them.
josh: Is this similar to the concern raised on the inline const stabilization? You can use generics in them, and they can have monomorphization-time errors.
tyler: The distinction between const items and const expressions makes sense to me. Makes this seem like a non-issue.
y86: If you want eager evaluation / compile time error you should use a const item for that.
fn run<T>() {
const { assert!(std::mem::size_of::<T>() > 0) };
}
mark: I would expect that to fail at compile time if you call run::<()>();. If you use it we're going to evaluate and throw a hard error.
josh: Would we guarantee we use it if it isn't generic?
y86: Sounds like that would be inconsistent, but not documented.
tyler: My expectation would be that control flow needs to reach the point (either at run time or compile time, during const eval of some const item) to get a panic / compiler error.
y86: but that does not seem to be the case currently: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=29c44ff12da623b5dcc0bbc247529ad3
tyler: Feels wrong to me.
y86: This is due to the desugaring of the const block, which is to make it into an associated constant.
josh: Torn between whether that seems like an implementation-dependent view, and whether there is any other feasible implementation.
mark: If we wanted to do significantly better we'd need to do symbolic evaluation
tyler: We could change a use of the expression to a panic in MIR or something
mark: Diverges from what we do today, e.g. with static_assert, where you really want failure at compile time.
tyler: I could be convinced but my initial feeling is that const expressions seem fundamentally different in this way; don't involve always evaluating.
mark: You could imagine cases where you want to rely on compile time failure.
tyler: Question of what use cases there are for using const expressions for that. They can do more things like name generics, are there cases where they want to do that and rely on compile time failure?
mark: Could possibly change across an edition.
felix: I think we kind of have to make a decision since we don't want people relying on it for UB detection.
y86: People do have the option to panic at runtime.
mark: Feels like using const for "please evaluate eagerly at compile time for performance" is not the use case for this.
tyler: I would expect them to be used for that.
josh: Let's please follow up on the issue async; file a concern to pause stabilization if you feel like we should do something substantially differently.
Link: https://github.com/rust-lang/rfcs/pull/3355
Link: https://github.com/rust-lang/rust/pull/103735
Link: https://github.com/rust-lang/rust/pull/106180
instruction_set inlining restrictions" reference#1307
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe