Remove #[crate_id] #15319
Merged
Remove #[crate_id] #15319
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Yay! This will enable cargo to properly handle isolating forks of packages on github from their original package. It will also clean up all of the |
|
🤘 |
|
Legit-looking travis failure |
|
Updated with a fix for the travis error. |
|
@alexcrichton Is this ready to be reviewed? |
|
Yes |
This commit removes all support in the compiler for the #[crate_id] attribute and all of its derivative infrastructure. A list of the functionality removed is: * The #[crate_id] attribute no longer exists * There is no longer the concept of a version of a crate * Version numbers are no longer appended to symbol names * The --crate-id command line option has been removed To migrate forward, rename #[crate_id] to #[crate_name] and only the name of the crate itself should be mentioned. The version/path of the old crate id should be removed. For a transitionary state, the #[crate_id] attribute is still accepted if the #[crate_name] is not present, but it is warned about if it is the only identifier present. RFC: 0035-remove-crate-id [breaking-change]
This metadata is used to drive the hash of all symbols in a crate. The flag can be specified a multiple number of times RFC: 0035-remove-crate-id
This commit modifies crate loading to purely work off a `crate_name` and nothing else. This commit also changes the patterns recognized from `lib<foo>-*` to `lib<foo>*` to accomodate the future renamings of output files. RFC: 0035-remove-crate-id
The compiler will no longer insert a hash or version into a filename by default.
Instead, all output is simply based off the crate name being compiled. For
example, a crate name of `foo` would produce the following outputs:
* bin => foo
* rlib => libfoo.rlib
* dylib => libfoo.{so,dylib} or foo.dll
* staticlib => libfoo.a
The old behavior has been moved behind a new codegen flag,
`-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and
a crate name of `foo`, the following outputs would be generated:
* bin => foo (same old behavior)
* rlib => libfoobar.rlib
* dylib => libfoobar.{so,dylib} or foobar.dll
* staticlib => libfoobar.a
The makefiles have been altered to pass a hash by default to invocations of
`rustc` so all installed rust libraries will have a hash in their filename. This
is done because the standard libraries are intended to be installed into
privileged directories such as /usr/local. Additionally, it involves very few
build system changes!
RFC: 0035-remove-crate-id
[breaking-change]
This comit implements a new flag, --extern, which is used to specify where a crate is located. The purpose of this flag is to bypass the normal crate loading/matching of the compiler to point it directly at the right file. This flag takes the form `--extern foo=bar` where `foo` is the name of a crate and `bar` is the location at which to find the crate. Multiple `--extern` directives are allowed with the same crate name to specify the rlib/dylib pair for a crate. It is invalid to specify more than one rlib or more than one dylib, and it's required that the crates are valid rust crates. I have also added some extensive documentation to metadata::loader about how crate loading should work. RFC: 0035-remove-crate-id
This involved removing some tests whose functionality was removed such as many of the crateresolve tests
In a cargo-driven world the primary location for the name of a crate will be in its manifest, not in the source file itself. The purpose of this flag is to reduce required duplication for new cargo projects. This is a breaking change because the existing --crate-name flag actually printed the crate name. This flag was renamed to --print-crate-name, and to maintain consistence, the --crate-file-name flag was renamed to --print-file-name. To maintain backwards compatibility, the --crate-file-name flag is still recognized, but it is deprecated. [breaking-change]
bors
added a commit
that referenced
this pull request
Jul 5, 2014
This is an implementation of [RFC 35](https://github.com/rust-lang/rfcs/blob/master/active/0035-remove-crate-id.md). The summary for this PR is the same as that of the RFC, with one addendum: * Removes the `#[crate_id]` attribute and knowledge of versions from rustc. * Added a `#[crate_name]` attribute similar to the old `#[crate_id]` attribute * Output filenames no longer have versions or hashes * Symbols no longer have versions (they still have hashes) * A new flag, `--extern`, is used to override searching for external crates * A new flag, `-C metadata=foo`, used when hashing symbols * [added] An old flag, `--crate-name`, was re purposed to specify the crate name from the command line. I tried to maintain backwards compatibility wherever possible (with warnings being printed). If I missed anywhere, however, please let me know! [breaking-change] Closes #14468 Closes #14469 Closes #14470 Closes #14471
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Oct 8, 2014
this is true as of rust-lang#15319
Centril
added a commit
to Centril/rust
that referenced
this pull request
Sep 15, 2019
…entril Warn on no_start, crate_id attribute use These attributes are now deprecated; they don't have any use anymore. `no_start` stopped being applicable in 3ee916e as part of rust-lang#18967. Ideally we would've removed it pre-1.0, but since that didn't happen let's at least mark it deprecated. `crate_id` was renamed to `crate_name` in 50ee1ec as part of rust-lang#15319. Ideally we would've followed that up with a removal of crate_id itself as well, but that didn't happen; this PR finally marks it as deprecated at least. Fixes rust-lang#43142 and resolves rust-lang#43144.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 24, 2023
…r-items, r=HKalbasi Report `incorrect-ident-case` for inner items Fixes rust-lang#15319 Although we have been collecting the diagnostics for inner items within function bodies, we were discarding them and never reported to the users. This PR makes sure that they are all reported and additionally collects the diagnostics for inner items within const bodies, static bodies, and enum variant bodies.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an implementation of RFC 35.
The summary for this PR is the same as that of the RFC, with one addendum:
#[crate_id]attribute and knowledge of versions from rustc.#[crate_name]attribute similar to the old#[crate_id]attribute--extern, is used to override searching for external crates-C metadata=foo, used when hashing symbols--crate-name, was re purposed to specify the crate name from the command line.I tried to maintain backwards compatibility wherever possible (with warnings being printed). If I missed anywhere, however, please let me know!
[breaking-change]
Closes #14468
Closes #14469
Closes #14470
Closes #14471