Rename "dylib" crate type to "rdylib" (keep old name but deprecate it), and maybe do the same for "staticlib" → "cstaticlib"

[RalfJung]

Proposal

The dylib and staticlib crate types are named very similarly, so it is easy to assume that they also behave in a similar way, with the only difference between dynamic vs static linking. However, this is far from true: staticlib creates a C-style static library that can be deployed as an artifact and linked without any further rustc involvement; dylib is basically a dynamic rlib, i.e., it still needs a bunch of Rust-specific processing until it becomes a regular C-style dynamic library (or static library, or binary). If I understood correctly, the main library crate types are arranged as follows:

	Static	Dynamic
Rust-style	rlib	dylib
C-style	staticlib	cdylib

Needless to say, this is quite confusing. See https://rust-lang.github.io/rfcs/1510-cdylib.html for some history of how we got here.

I think we should clean this up. Here are some steps we could take, which are probably increasingly controversial but we don't have to do all of them:

1. add rdylib as an alias for dylib, and update the docs to generally prefer rdylib over dylib
2. show a deprecation warning when using dylib
3. add cstaticlib as an alias for staticlib, and update the docs to generally prefer cstaticlib over staticlib
4. show a deprecation warning when using staticlib

With all of this done, the table would look like

	Static	Dynamic
Rust-style	rlib	rdylib
C-style	cstaticlib	cdylib

Much better :)

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them
here. You can put your own name here if you are planning to mentor the
work.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rfcbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rfcbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler