# Backlog Bonanza 2022-03-16

[GitHub query](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AC-tracking-issue+label%3AT-lang)

## What are we DOING?

* Take things that have been unstable for a while and "disposition them".
* Goal: Everything that is nightly only has one or more of the following labels, indicating the blocker(s) to stabilizing it:
* S-tracking-ready-to-stabilize: Needs a stabilization PR (good to go :train:)
* S-tracking-needs-to-bake: Needs time to bake (set a date? other criteria?)
* S-tracking-impl-incomplete: Not code complete or blocking bugs
* S-tracking-unimplemented: Implementation not begun
* S-tracking-design-concerns: Blocking design concerns
* This might be "doesn't quite seem to deliver value we hoped for" or "something doesn't feel right"
* S-tracking-perma-unstable
* Internal implementation detail of rustc, stdlib
* S-tracking-needs-summary

Attendance: Josh, Niko, Felix
Other: Mark, David

## Tracking issue for RFC 2045: improving #\[target_feature\] #44839

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

pnkfelix: In last Backlog Bonanza, we had said that it looks like this is a combo of a checklist of target-specific items as well as enhancements to the target_feature mechanism itself and associated issues.

joshtriplett: we should split this. Close the bit that is tracking target-specific features. The other one, making target feature better, is "needs owner".

pnkfelix: gnzblg was owner, but they haven't been active lately.

joshtriplett: I think there are a lot of folks who care about this item, the question is more whether there's someone willing to own and drive it. I don't think in this meeting we should be trying to do the "split etc" thing, we should cover more items, but we should assign it to someone, or tag it and post the comment.

pnkfelix: I can do that but I don't want to own further investigation.

joshtriplett: What do folks think about "needs owner"?

simulacrum: I'm not a fan of the idea, seems not distinct enough from "design concerns" etc, depending on what the owner is for. Needs owner implies that it ... the way we resolve *all* things is by having an owner for them.

pnkfelix: I agree that "needs owner" is maybe not a separate state, but the question is whether we need some different metadata to say "there was an implicit owner but now there really isn't".

simulacrum: I think it would be useful if our tracking issue template had a field like "last summarized on XXX by YYY" and that way there's an implicit "if there's been no summary for 6 months, prob that person is not actively looking"

joshtriplett: I've got half-a-comment written, can somebody take up the split

https://github.com/rust-lang/rust/issues/44839#issuecomment-1069376099

nikomatsakis: I think it's worth making it clear that there IS no owner. Just seeing that there hasn't been activity doesn't say much on its own.

simulacrum: label might not be the best way, but I agree

nikomatsakis: in particular, with initiatives, owners will sometimes disappear, we should have a way to recruit a new one

## Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust #44930

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

joshtriplett: Recently followed up on this. We made a decision in a previous rust-lang meeting about whether which targets had to be supported for us to ship this. Ultimately this will be a never-ending thing of "every target has to support it". So the question is "which subset of targets is needed to ship as stable". In a previous rust-lang meeting we agreed we can ship it on a subset of targets, but didn't define the subset, though it at least must include Tier 1. Rough consensus seemed to be did not require Tier 2.

pnkfelix: When it doesn't work, do you get a compilation error?

joshtriplett: There are targets for which it is not implemented at all, in which case, you would get a compilation error. But it could also be implemented but have bugs. In that scenario, I think we fix it like any other bug. Don't think there are known bugs on Tier 1 architectures, at least.

pnkfelix: yes

joshtriplett: I think current status is that we've made a decision that it is sufficiently complete; the author said they wanted to add a couple more tests to this and then they're ready to ship. What would that quality as for "S"?

nikomatsakis: "ready to stabilize", I think

pnkfelix: not needs bake?

joshtriplett: It's more that there are some corner cases they want to ensure are tested; it's not that it needs to bake more per se.

nikomatsakis: Seems to me like fcp'ing with a concern.

simulacrum: It sounds like the corcern around future compatibility with types needing different layout depending on ABI (or something); it sounds like that wasn't well understood in the comment thread.

joshtriplett: I do recall us having a conversation about it. I think the primary concern we needed to settle, and we did settle, was whether we could add support for other calling conventions in the future. I think the answer and conclusion was "yes, it would be".

simulacrum: Sounds like that would come up in the stabilization report in any case. We can call it ready to stabilize.

pnkfelix: Currently it only works on `extern "C"`, right?

joshtriplett: Yes.

*some back and forth about what "default" means*

## Lint for undesirable, implicit copies #45683

link: https://github.com/rust-lang/rust/issues/45683

joshtriplett: pnkfelix commented a year ago that would highlight moves larger than a configured limit.

nikomatsakis: I don't think that is all of it, there is also `Cell`, or to designate types like iterators that "could be copy" in the sense of memcpy, but where you might want an explicit clone.

joshtriplett: Fair to say "needs summary"? Or should we split?

scottmcm: I think splitting is good, the "big memcpy" thing seems separable from the Cell:Copy thing.

joshtriplett: is large-assignments enabled by default?

pnkfelix: I suspect it is not

joshtriplett: should we? and with what threshold?

scottmcm: I think we should obviously do that for "particuarly large ones" like 1KB

joshtriplett: so: "yes we should and there's some threshold we should pick"

pnkfelix: a cache line

nikomatsakis: egads

nikomatsakis: we should split, and this is probably empirical, at least in part?

joshtriplett: can we modify the lint to emit the size as part of message, turn it on, do a crater run, and then we can analyze that to see the right threshold?

* https://lang-team.rust-lang.org/design_notes/copy_ergonomics.html

nikomatsakis: I think we could almost close this, it's more of a problem statement, we don't have a design, maybe `S-tracking-needs-design`, but we don't have that.

pnkfelix: design-concerns includes that.

nikomatsakis: I can write a comment suggesting what we want done here.

joshtriplett: I just followed link to #83518 "large assignments lint", shall we add appropriate label?

nikomatsakis: I feel like we need someone to go gather the data and suggest a threshold.

scottmcm: how would we want this configurable? I'm not sure what "level" it applies to, it looks like there's an unstable crate limit attribute.

joshtriplett: the box isn't actually checked for "implement the RFC", it's not completely clear what the state of the lint is.

nikomatsakis: It's kind of in the "exploration" stage of the initiative, right? No RFC

pnkfelix: there was an FCP

nikomatsakis: ok, but still, in terms of "make this a user-facing feature", not much work has been done

scottmcm: technically it's warn by default already, but there's no threshold

joshtriplett: effectively makes it allow by default

## (RFC 1210) specialization: restrictions around lifetime dispatch #45982

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

nikomatsakis: I would call this `S-tracking-design-concerns`

joshtriplett: This is a tracking issue for a subset of specialization

nikomatsakis: Honestly I think the issue is adding no value and I would close it

nikomatsakis to close and write summary

## Tracking issue for RFC #2145: Type privacy and private-in-public lints #48054

simulacrum: I think I saw petrochenkov comment that they wanted some changes. Obviously I'll never find that comment now.

joshtriplett: Going to tag this as "design concerns" then.

simulacrum: I think "needs summary"

nikomatsakis: I still dislike the rules this RFC is trying to remove :)

scottmcm: We FCP'd something removing one of these rules, right?

nikomatsakis: yes.

## Tracking issue for RFC #1909: Unsized Rvalues #48055

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

joshtriplett: basically alloca?

nikomatsakis: in some cases, at least. I realized recently that this whole thing is basically incompatible with async -- they would need to call malloc. I'm not sure about wasm. I have concerns about portability and orthogonality.

scottmcm: I got the impression that different parts have very different complications. Like function arguments are somewhat easier than the other ones?

nikomatsakis: going from "caller to callee" works well, going back up the stack not so much, storing in let is tricky

joshtriplett: I care about seeing this happen but I have some design concerns

nikomatsakis: I remember that the RFC included some text about a guaranteed optimization path, or at least it was discussed, I'm not sure if that got documented/implemented or if we might want a (opt-in?) lint to help you enforce it.

pnkfelix: Was that something from the issue thread?

nikomatsakis: I thought it was in the RFC but maybe just something arielb1 and I talked about.

nikomatsakis: I think "needs summary" is a good label.

joshtriplett: do we need to note anything besides labeling it?

## Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses #48214

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

joshtriplett: what syntax is here?

nikomatsakis: no syntax, but you can add bounds like `where String: Copy` and the compiler believes you, rather than giving you an error; probably it should warn though

nikomatsakis: I expect this to fall out from other work that we are doing, matthewjasper's "there's an impl but it's kind of hairy"

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7c4c60898d3aebebf54a4900ab18636b

// compiles today:
#![feature(trivial_bounds)]

fn foo() where String: Copy {
    let x = "foo".to_string();
    let y = x;
    let z = x; // Added this line since otherwise it works without the `where`
}

fn main() { }

matthewjasper [example](https://github.com/rust-lang/rust/issues/48214#issuecomment-396038764) of something "surprising" in the current implementation:

#![feature(trivial_bounds)]

struct A;
trait X<T> {
    fn test(&self, t: T) {}
}

impl X<i32> for A {}

fn foo(a: A) where A: X<i64> {
    a.test(1i64); // expected i32, found i64
}

nikomatsakis: I would this "impl incomplete" but we don't know the exact set of bugs, it might be "needs summary" for that reason

## Tracking issue for stable SIMD in Rust #48556

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

joshtriplett: might be one of those "we've shipped it for a few architectures but not all of them" -- but it may also just be "done"?

joshtriplett: there's *portable* SIMD, which has its own tracking issues, but this appears to just be SIMD...?

nikomatsakis: In 2020, Amanieu:

> I'm going to reopen this issue. SIMD was only stabilized on x86/x86_64, not on other architectures.

joshtriplett: I think this is explicitly about the "simd intrinsics", and I think we've already done that.

nikomatsakis: any remaining intrinsics ought to have their own tracking issue