Skip to content

Tracking issue for renaming crates inside compiler directory #76425

Closed
@Dylan-DPC-zz

Description

@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:

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCS-waiting-on-teamStatus: Awaiting decision from the relevant subteam (see the T-<team> label).T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions