Plans for development of key crates supporting standard library and/or compiler.

[crlf0710]

Hello, personally i feel there's less than necessary planning going on for development and maintenance of key crates supporting the standard library and/or compilers.

Let me take a specific example: in RFC2457's tracking issue, 55467, it is very clear from the RFC text that the work is blocked on the existence of a crate implementing Unicode TR39 funcionalities. Only when such a crate come into shape will the lint implementation work move on. However, whoever has the time needed to implement these lints is very unlikely to implement that crate as preparation work. Even if they did, that crate will be a crate supporting rustc, so rust-lang team might want to take some moderation on the maintenance of the crate.

Under a condition like this, i fear that the work might be blocked indefinitely. I think there could be some planning beforehand, to make sure work like this will finally get accomplished.

[XAMPPRocky]

I think this would a good candidate for a Project Group, it has a very clear scope and goal. I'm not sure which team would need to be responsible for though.

[Manishearth]

I don't think work on the RFC is blocked solely on TR39 stuff. There's a bunch of compiler work that needs to be done first (namely: NFC-capable resolution) before we add the lints. The lints themselves can be added piecemeal, and the relevant section of TR39 is not hard to do.

[Manishearth]

Added the note about NFC to the tracking issue. The hard lint to implement here is confusables_detection, and that is hard because of the resolver work necessary, not because of the difficulty of implementing confusables checks. The relevant TR39 bits for the other lints are relatively easy to implement.

[BatmanAoD]

I don't think work on the RFC is blocked solely on TR39 stuff.

I think the consideration here is whether lang-work is blocked on ecosystem-work; that's important to track, I think, whether or not the ecosystem-work is the only blocker.

[crlf0710]

I think the consideration here is whether lang-work is blocked on ecosystem-work; that's important to track, I think, whether or not the ecosystem-work is the only blocker.

Exactly, and there're other examples like GAT blocked on chalk(too compiler specific), windows-xp usable rwlocks blocked on parking_lot, and so on. I think they're all worth tracking.

[Manishearth]

Actually, chalk is a good example, because that crate is the responsibility of the compiler team. It's not an ecosystem thing. And when someone wants to implement the specific non ASCII idents lint, it will be their responsibility to write this module (which they can break off into a crate if they wish).

I don't see this distinction of lang-work and ecosystem-work to be useful. Sometimes when working on the compiler you need to write nontrivial chunks of rust, some of which can be broken off into a crate. What exactly can we achieve by tracking this differently? It's work, it's work that needs to be done, it's work that someone could step up and do. I don't think teams are unaware that this work needs to happen. What makes this special amongst all the other kinds of compiler work blocking other features?

[Manishearth]

Whenever a team takes a nontrivial ecosystem dependency they commit to helping maintain it. This is true for hashbrown and unicode-xid and will be true for parking_lot if we make the switch.

[crlf0710]

Whenever a team takes a nontrivial ecosystem dependency they commit to helping maintain it.

@Manishearth Yep, and this issue is about when such a dependency is needed but doesn't exist yet, there should be some planning that "pre-order" it, instead of waiting for it appearing randomly...

[Manishearth]

I still don't see how that's any different from waiting around for other compiler work to happen randomly.

Like, the UAX 39 stuff is minor compared to the rest of the stuff in that tracking issue. It's not the case that folks are waiting for that crate to appear randomly in isolation, it's that entire bundle of work that's being waited for, presumably because it's not a compiler team priority. There's nothing remarkable about the portion of that work that can be done outside the compiler. This work is already tracked. It's a matter of the relevant teams and contributors not prioritizing it.

[crlf0710]

Sometimes when working on the compiler you need to write nontrivial chunks of rust, some of which can be broken off into a crate.

While chalk may be this way, since it's compiler oriented, I can't imagine or expect awesome crates like parking_lot come into reality in developing the rustc compiler itself. I don't think ecosystem should be build up like that. While this may happen at times, we cannot just wait for these happening.

Team members are busy, and will be kept busy in the foreseeable future. By splitting large missions into smaller missions and making progress step by step, things will become more actionable.

[Manishearth]

Team members are busy, and will be kept busy in the foreseeable future. By splitting large missions into smaller missions and making progress step by step, things will become more actionable.

Yes, but this is true regardless of whether that work needs to be done within the compiler or not.

I can't imagine or expect awesome crates like parking_lot come into reality in developing the rustc compiler itself.

But that crate already exists! The issue is whether or not it should be adopted by the stdlib, which doesn't involve ecosystem work.

Again, I don't see efforts in this direction solving any problems. The problems you're seeing are larger prioritization issues, which won't be magically solved by adding more process.

[XAMPPRocky]

I'm going to to close this, as I think the answer to this question now is to file a MCP to the lang and/or compiler team.