---
title: Triage meeting 2023-07-18
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2023-07-18
## Attendance
* Team members:
* Others:
## Meeting roles
* Action item scribe:
* Note-taker:
## Scheduled meetings
- No pending proposals this time.
Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7.
## Announcements or custom items
### Niko's schedule
I'll be available July 25, July 26, and Aug 1 and 2, but then away until Aug 19.
### Josh's schedule
Traveling in late Sep and in Asian time zone. Hoping to attend meetings. Time slot doesn't make it easy. In general, we don't have good support for participation from Asia time zones.
### Driving RPITIT to stabilization
We had some discussion about details of RPITIT stabilization.
Needs longer discussion. [Draft document available.](https://hackmd.io/zgairrYRSACgTeZHP1x0Zg)
Repurpose July 26 design meeting slot for this.
Josh: biggest thing I would want to see is how (or if) we're handling Send/Sync propagation, how that will work, and what exactly is being stabilized.
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
None.
## PRs on the lang-team repo
### "Expand variadic generics design notes" lang-team#212
**Link:** https://github.com/rust-lang/lang-team/pull/212
Tyler reviewed, thought it was fine, left a few comments.
### "Frequently requested changes: `return expr if condition`" lang-team#213
**Link:** https://github.com/rust-lang/lang-team/pull/213
nikomatsakis: Not sure I'd never ever want this, but it's so below my priority list it's hard to think about. I'll check my box for now.
## Issue on the lang-team repo
### Experiment: Generic const items #214
https://github.com/rust-lang/lang-team/issues/214
No major objections raised, let's do it!
## RFCs waiting to be merged
None.
## `S-waiting-on-team`
### "Tracking issue for dyn upcasting coercion" rust#65991
**Link:** https://github.com/rust-lang/rust/issues/65991
Filed issue out to https://github.com/rust-lang/rust/issues/113840
Niko to post a comment saying:
Thanks for this, please post data, we'll revisit next week and move forward if we don't see data that makes us want to stop.
### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961
**Link:** https://github.com/rust-lang/rust/pull/110961
unnominated
### "Support interpolated block for `try` and `async`" rust#112953
**Link:** https://github.com/rust-lang/rust/pull/112953
scottmcm: nomination is from before FCP was kicked off; I unnominated
## Proposed FCPs
**Check your boxes!**
### "unsafe attributes" rfcs#3325
- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved 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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911218):
> @rfcbot merge
### "RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349
- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
> * waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
>
> 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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889):
> 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
### "Tracking issue for the `thiscall` calling convention" rust#42202
- **Link:** https://github.com/rust-lang/rust/issues/42202
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/42202#issuecomment-1616187726):
> Team member @petrochenkov has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Aaron1011
> * [x] @cjgillot
> * [x] @compiler-errors
> * [x] @davidtwco
> * [x] @eddyb
> * [x] @estebank
> * [ ] @jackh726
> * [ ] @lcnr
> * [x] @matthewjasper
> * [x] @michaelwoerister
> * [ ] @nagisa
> * [x] @oli-obk
> * [x] @petrochenkov
> * [ ] @pnkfelix
> * [ ] @wesleywiser
>
> 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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/42202#issuecomment-1616187723):
> @rfcbot fcp merge
> Stabilization report: https://github.com/rust-lang/rust/issues/42202#issuecomment-1565207948
### "Stabilise inline_const" rust#104087
- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved 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-errors~~ resolved 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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge
### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378
- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> 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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287177):
> 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.
### "TAIT defining scope options" rust#107645
- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> 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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.
### "make `noop_method_call` warn by default" rust#111916
- **Link:** https://github.com/rust-lang/rust/pull/111916
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111916#issuecomment-1599418260):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/111916#issuecomment-1599418200):
> @rfcbot fcp merge
>
> From the random things I checked in the crater run, this looks like it'll be a great warning to have on-by-default.
### "add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053
- **Link:** https://github.com/rust-lang/rust/pull/113053
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/113053#issuecomment-1613366741):
> Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [ ] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
> * [x] @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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/113053#issuecomment-1613366705):
> @rfcbot fcp merge
>
> Here's what I [wrote in zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Document.20.28lack.20of.29.20floating.20point.20conformance.20on.20x86-32/near/370819815) about why T-lang should merge this:
>
> > my current take is: Its better for the docs to be updated to reflect reality, especially if its to point out a place where we are not conforming to an assumed specification. We can always change the docs later if we improve our conformance in some manner.
> >
> > At this point I'm not sure if we should force all such doc improvements to go through lang-team FCP, but its also safer to just do the FCP (and then let the team debate later if we want to follow less strict policy)
### "Mention style for new syntax in tracking issue template" rust#113586
- **Link:** https://github.com/rust-lang/rust/pull/113586
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/113586#issuecomment-1631443504):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/113586#issuecomment-1631443474):
> @rfcbot merge
### "Frequently requested changes: `return expr if condition`" lang-team#213
- **Link:** https://github.com/rust-lang/lang-team/pull/213
- [**Tracking Comment**](https://github.com/rust-lang/lang-team/pull/213#issuecomment-1622546183):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @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](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/lang-team/pull/213#issuecomment-1622501576):
> @rfcbot merge
## Active FCPs
### "Uplift `clippy::option_env_unwrap` lint" rust#111738
**Link:** https://github.com/rust-lang/rust/pull/111738
### "Support interpolated block for `try` and `async`" rust#112953
**Link:** https://github.com/rust-lang/rust/pull/112953
## P-critical issues
None.
## Nominated RFCs, PRs and issues discussed this meeting
### "nightly/beta regression: fnptrs with types containing `()` is warned to be not FFI-safe, while it is before" rust#113436
**Link:** https://github.com/rust-lang/rust/issues/113436
What is the desired behavior? If we decide to make the fn warn, that'd have a major impact and would require FCP. Given that this was not FCP'd, it should be reverted on beta. If someone wants to propose it, they can do so in a PR.
ScottMcm: not every lint change needs an FCP
JoshTriplett: Agreed, not every one does, but this one makes a semantic change
tmandry: I agree that if your premise is true, Josh, then I agree with your conclusion
nikomatsakis: not every lint change needs an FCP but those that have high impact or make a semantic change do, and this seems to qualify on both dimensions
pnkfelix: careful with a blind revert, the PR fixed an ICE
joshtriplett: sounds like davidtwco had a proper fix but had second thoughts
scottmcm: intuitions on whether unit types should be linted or not?
joshtriplett: I would propose we shouldn't be evaluating it on the fly at this meeting. That said, I do believe that the code in this issue should not warn. But I don't know that I'd say the same thing for arbitrary ZSTs.
scottmcm: what I was going for was if everyone felt it should warn, we'd accept it, but that's not the state of the room, so I agree with previous proposal to do it intentionally.
nikomatsakis: +1 and I am not confident it should warn
Meeting consensus:
* an FCP is required to make this decision
* we do not know whether to make it or not yet :)
### "Does T-lang have opinion on floating-point guarantees?" lang-team#210
**Link:** https://github.com/rust-lang/lang-team/issues/210
Previous time we discussed it, the answer was "yes, we do, many!" We will unnominated.
### "Allow cfg-attributes in where clauses" rfcs#3399
**Link:** https://github.com/rust-lang/rfcs/pull/3399
Josh: temperature of the room on this idea?
*Discussion timeboxed to 2min*
Lokathor: +1
Tmandry: hmm
scottmcm: If Josh thinks it's good, he should FCP it.
joshtriplett: It seems fine to me at first glance.
tmandry: probably fine, given that we support them in angle brackets (who knew?)
scottmcm: I always wonder how to tell how far they apply but we can make a rule that's fine.
TC: hard to think of bad places to allow them
nikomatsakis: seems like a no brainer to me
tmandry: +1 to this pattern of raising RFCs for short discussion!
joshtriplett: one of the reasons I think it's so critical is that it is painful if somebody starts a bot merge when people would want to close under current system, but we'll have changes there.
### "Report monomorphization time errors in dead code, too" rust#112879
**Link:** https://github.com/rust-lang/rust/pull/112879
*5 min timebox*
> _Nominating_ for lang team discussion. See the changed test (or the example in the main post of this PR) for an example of code that compiles in release mode, but not in debug mode. This PR changes that to also error in release mode, at the cost of performing more work in both release and debug mode, as hypothetically debug mode can also make dead code disappear.
>
> Performance in incremental tests regresses up to 25% in extreme cases. Full builds regress up to 4% (except for the `projection-caching` test, which also regresses by 25%, but that's an artificial stress test).
>
> Note that all of the regressions are for cases where we *don't* have an issue, but we also don't know this ahead of time. It's unlikely we can do much better here, as we are already avoiding duplicate work and ensuring that we still don't generate LLVM IR for dead code, even if LLVM could raise an error there in debug mode, but not release mode (a [previous performance run](https://github.com/rust-lang/rust/pull/112879#issuecomment-1600664132) that did that was much worse).
scottmcm: wall-time results, the check regr is 2%, opt regr is 4.5%, makes no sense
nikomatsakis: this is a 2-way door, right? we can take these errors away again?
scottmcm: depends if people rely on it for soundness
lokathor: people definitely have static asserts and other soundness checks
joshtriplett: will cause more errors on existing code, does this impact live crates?
tmandry: crater run is good practice
nikomatsakis: pretty sure I'm in favor, but I'm forgetting full context. For example, this is only for monomorphized things? When exactly can I be sure to see an error?
TC: I think I've had static asserts...?
tmandry: not changing that, this is purely about eliminating dead code based on optimization options
nikomatsakis: more like `if false`, so the code still has to be "live" in some crude sense
joshtriplett: yes
Lokathor: I think the consensus is for a crater run?
tmandry: I lean towards we want this
pnkfelix: can we find a way to express the old behavior in some fashion?
scottmcm: `const if`
joshtriplett: I personally agree that even at the perf hit we want this by default to catch more errors, but I am prepared to say we want to *guarantee this in all circumstances*. One thing to say "we will make best effort to catch more errors"; another thing to say "we guarantee to catch all errors in dead code".
scottmcm: We made a promise we will evaluate all non-generic const items even if they are not used. We FCP'd that. I think we should do a similar FCP to make that a guarantee, but not do it as part of this PR.
nikomatsakis: that fits with my specific proposal of I would rather vote for something complete than for a diff.
scottmcm: I was really scared about the instruction results but walltime results don't seem so bad.
nikomatsakis: I'm inclined to land the PR and then have somebody do a proper write-up in an issue where we FCP the whole thing. Crater run first is a good idea too.
joshtriplett: cc the perf team too, see if they have clever ideas for mitigation/optimization?
### "Uplift `clippy::option_env_unwrap` lint" rust#111738
**Link:** https://github.com/rust-lang/rust/pull/111738
Unnominate.
### "Clearly specify the `instruction_set` effects" reference#1307
**Link:** https://github.com/rust-lang/reference/pull/1307
CHECK YOUR !@#!$! BOXES
### "Shorten drop scope of temporaries in conditions" rust#111725
**Link:** https://github.com/rust-lang/rust/pull/111725
Big change to when destructors run.
tmandry: over an edition?
nikomatsakis: maybe, we're working on some proposals around this, the motivation feels a bit unsure to me.
joshtriplett: agree with close for current edition but that we might consider it over a future edition.
### "Document soundness of Integer -> Pointer -> Integer conversions in `const` contexts." rust#113510
**Link:** https://github.com/rust-lang/rust/pull/113510
Please have a look! A small, one sentence change.
### "make `noop_method_call` warn by default" rust#111916
**Link:** https://github.com/rust-lang/rust/pull/111916
Complains if you call `.clone` on a reference
nikomatsakis: I've seen bugs related to this. +1.
Examples from crater:
```rust=
[INFO] [stdout] error: call to `.borrow()` on a reference in this situation does nothing
[INFO] [stdout] --> src/main.rs:267:27
[INFO] [stdout] |
[INFO] [stdout] 267 | let col = self.borrow().get_col(col_idx);
[INFO] [stdout] | ^^^^^^^^^ unnecessary method call
[INFO] [stdout] |
[INFO] [stdout] = note: the type `Board` does not implement `Borrow`, so calling `borrow` on `&Board` copies the reference, which does not do anything and can be removed
[INFO] [stdout] = note: `#[deny(noop_method_call)]` on by default
[INFO] [stdout] error: call to `.clone()` on a reference in this situation does nothing
[INFO] [stdout] --> src/client/mod.rs:336:53
[INFO] [stdout] |
[INFO] [stdout] 336 | let (_, _, client0) = mock_client(client0_id.clone(), 1);
[INFO] [stdout] | ^^^^^^^^ unnecessary method call
[INFO] [stdout] |
[INFO] [stdout] = note: the type `str` does not implement `Clone`, so calling `clone` on `&str` copies the reference, which does not do anything and can be removed
[INFO] [stdout] = note: `#[deny(noop_method_call)]` on by default
```
### "Tracking issue for the `thiscall` calling convention" rust#42202
**Link:** https://github.com/rust-lang/rust/issues/42202
Previously we made this lang decisions. But compiler FCP has started.
joshtriplett: I agree this is in our scope, though compiler should also sign off.
nikomatsakis: yes, I'm in favor.
joshtriplett: can we use `rfcbot poll`?
## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Explicit Tail Calls" rfcs#3407
**Link:** https://github.com/rust-lang/rfcs/pull/3407
### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503
**Link:** https://github.com/rust-lang/rust/issues/54503
### "dyn Trait comparison should not include the vtable pointer" rust#106447
**Link:** https://github.com/rust-lang/rust/issues/106447
### "Make pointer_structural_match normal and warn" rust#110166
**Link:** https://github.com/rust-lang/rust/pull/110166
### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961
**Link:** https://github.com/rust-lang/rust/pull/110961
### "feat: `riscv-interrupt-{m,s}` calling conventions" rust#111891
**Link:** https://github.com/rust-lang/rust/pull/111891
### "let-else does not support `else if`" rust#111910
**Link:** https://github.com/rust-lang/rust/issues/111910
### "RPITIT is allowed to name any in-scope lifetime parameter, unlike inherent RPIT methods" rust#112194
**Link:** https://github.com/rust-lang/rust/issues/112194
### "Support interpolated block for `try` and `async`" rust#112953
**Link:** https://github.com/rust-lang/rust/pull/112953
### "add notes about non-compliant FP behavior on 32bit x86 targets" rust#113053
**Link:** https://github.com/rust-lang/rust/pull/113053
### "Support overriding `warnings` level for a specific lint via command line" rust#113307
**Link:** https://github.com/rust-lang/rust/pull/113307
### "Rename and allow `cast_ref_to_mut` lint" rust#113422
**Link:** https://github.com/rust-lang/rust/pull/113422
### "Mention style for new syntax in tracking issue template" rust#113586
**Link:** https://github.com/rust-lang/rust/pull/113586
Sign in with Wallet
Connect another wallet