Tracking issue for renaming crates inside compiler directory

[Dylan-DPC-zz]

This issue tracks the progress of renaming compiler crates from rustc_xyz to xyz. Each crate will be renamed in a separate PR or in combination with other smaller unrelated crates to avoid conflicts and cause an avalanche of conflicts (such as #74862)

List of compiler/ crates:

• rustc_apfloat -> apfloat
• rustc (this will remain the same and will be renamed if needed at a later stage)
• rustc_arena -> arena
• rustc_ast -> ast
• rustc_ast_lowering -> ast_lowering
• rustc_ast_passes -> ast_passes
• rustc_ast_pretty -> ast_pretty
• rustc_attr -> attr
• rustc_builtin_macros -> builtin_macros
• rustc_codegen_llvm -> codegen_llvm
• rustc_codegen_ssa -> codegen_ssa
• rustc_data_structures -> data_structures
• rustc_driver -> driver
• rustc_error_codes -> error_codes
• rustc_errors -> errors
• rustc_expand -> expand
• rustc_feature -> feature
• rustc_fs_util -> fs_util
• rustc_graphviz -> graphviz
• rustc_hir -> hir
• rustc_hir_pretty -> hir_pretty
• rustc_incremental -> incremental
• rustc_index -> index
• rustc_infer -> infer
• rustc_interface -> interface
• rustc_lexer -> lexer
• rustc_lint -> lint
• rustc_macros -> macros
• rustc_metadata -> metadata
• rustc_middle -> middle
• rustc_mir -> mir
• rustc_mir_build -> mir_build
• rustc_parse -> parse
• rustc_parse_format -> parse_format
• rustc_passes -> passes
• rustc_plugin_impl -> plugin_impl
• rustc_privacy -> privacy
• rustc_query_system -> query_system
• rustc_resolve -> resolve
• rustc_save_analysis -> save_analysis
• rustc_serialize -> serialize
• rustc_session -> session
• rustc_span -> span
• rustc_symbol_mangling -> symbol_mangling
• rustc_target -> target
• rustc_trait_selection -> trait_selection
• rustc_traits -> traits
• rustc_ty -> ty
• rustc_typeck -> typeck

References:

MCP
Zulip discussion

Notes

This will be a long-term effort that will make the structure look inconsistent (some crates will have the prefix while the others won't) till all the crates are renamed
An alternative idea suggested was to rename the paths without renaming the name of the crate (thus keeping the imports same as earlier) but it was concluded that

It would be weird for the crate and directory to have different names; that kind of goes against the objective of making things a bit more idiomatic

If anyone wants to work on this as well, please get in touch first (on zulip if possible) to avoid conflict-hell

PRs:

[jyn514]

I'm still not sure it makes sense to rename the crates one at a time ... it would be very inconsistent during the transition.

[ehuss]

I'm a bit confused, where was it decided that the rustc_ prefix should be removed? I personally find it helpful, as it very clearly indicates which parts are crates from the compiler "proper", and which are from external crates. Also, a lot of these names seem like they could introduce ambiguity.

[jyn514]

@ehuss there's some discussion in https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Move.20the.20compiler.20to.20a.20new.20.60compiler.2F.60.20di.E2.80.A6.20compiler-team.23336, but I don't think it went through MCP. Maybe it should?

[ehuss]

I saw that discussion. The only comments from the compiler team were:

oli: we could start with just renaming the directories but keeping the crate names
pnkfelix: ...discussing tests
petrochenkov: Many of the crate names are too generic for that, IMO. ... I like it as is, personally.

[mark-i-m]

You might want to cc the original threads to make sure people see this.

I pass my cloak to you @Dylan-DPC. May the force be with you!

[petrochenkov]

@ehuss

I'm a bit confused, where was it decided that the rustc_ prefix should be removed?

No, it wasn't decided.

[petrochenkov]

My arguments for keeping the status quo (besides avoiding the churn) is what ehuss said in #76425 (comment) basically.

[Dylan-DPC-zz]

I'll leave this issue open (and blocked) till we have a clearer decision

[spastorino]

Should we label as S-waiting-on-team? or if not maybe we should nominate so this is discussed on next compiler meeting.

[Dylan-DPC-zz]

yeahh i'm okay with that

[pnkfelix]

we've subsequently discussed this in a couple different T-compiler meetings. @nikomatsakis and @pnkfelix have decided that we're not going to do this. At least, not now