-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Description
What is this lint about
The deprecated_cfg_attr_crate_type_name
lint detects uses of the #![cfg_attr(..., crate_type = "...")]
and #![cfg_attr(..., crate_name = "...")]
attributes to conditionally specify the crate type and name in the source code. For example:
#![cfg_attr(debug_assertions, crate_type = "lib")]
Explanation
The #![crate_type]
and #![crate_name]
attributes require a hack in the compiler to be able to change the used crate type and crate name after macros have been expanded. Neither attribute works in combination with Cargo as it explicitly passes --crate-type
and --crate-name
on the commandline. These values must match the value used in the source code to prevent an error.
How to fix this warning/error
To fix the warning use --crate-type
on the commandline when running rustc instead of #![cfg_attr(..., crate_type = "...")]
and --crate-name
instead of #![cfg_attr(..., crate_name = "...")]
.
We are interested to hear about any/all use cases for conditional #![crate_type]
and #![crate_name]
attributes.
Current status
- Deprecate crate_type and crate_name nested inside #![cfg_attr] #83744 introduces the
deprecated_cfg_attr_crate_type_name
lint as warn-by-defaultMake forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default #99784 makes thedeprecated_cfg_attr_crate_type_name
lint deny-by-defaultPR Make deprecated_cfg_attr_crate_type_name a hard error #129670 makes thedeprecated_cfg_attr_crate_type_name
lint a hard errorTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Activity
est31 commentedon Jul 26, 2022
I've filed a PR to make this deny-by-default: #99784
Rollup merge of rust-lang#99784 - est31:deny_cfg_attr_crate_type_name…
Rollup merge of rust-lang#99784 - est31:deny_cfg_attr_crate_type_name…
est31 commentedon Mar 21, 2023
Since the grep.app seach conducted in the original PR there have been two new crates using it, despite the lint:
wasmer:
azul:
Both uses were added in 2021, after #83744 was opened and before it was merged. Also both only modify
crate_type
. As @bjorn3 has asked above about use cases forcrate_type
withincfg_attr()
, it might be interesting to think about alternatives one can suggest to the maintainers of these libraries.Maybe one could extend cargo to support
cargo:rustc-crate-type
in build.rs scripts? Alternatively, one could maybe suggest adding a crate that hascrate-type
set in Cargo.toml, and theninclude!()
s thelib.rs
?bjorn3 commentedon Mar 21, 2023
Wouldn't
cargo build --crate-type cdylib
suffice in both cases?est31 commentedon Mar 21, 2023
It should actually, good point. Maybe the
wasm-pack
equivalent of it forwasmer
, but yes. Also as you've wrote earlier,#![crate_type = "..."]
is totally ignored if--crate-type
is present (only then though, if it's not present it's not ignored, but it seems that cargo always sets it?? not 100% sure). Ideally one would interact with downstream though before proposing a PR to remove.ia0 commentedon Jun 14, 2023
This doesn't work for me. My understanding is that
--crate-type
is only arustc
flag, you can't use it withcargo build
. I would really like it to work withcargo build
though. Is this planned?bjorn3 commentedon Jun 14, 2023
Right,
--crate-type
is a flag forcargo rustc
, notcargo build
. My bad.cargo rustc
should work in most cases thatcargo build
does. The main limitation is that it requires a single target within a single package rather than allowing multiple packages and targets.ia0 commentedon Jun 15, 2023
Oh that's very interesting, I didn't know that. I always assumed
cargo rustc
was just a wrapper around a single invocation ofrustc
requiring you to compile dependencies separately and pass them on the command line. That's good to know, that should solve my issue. I think there's almost no cases wherecargo build
is useful to me then since I always use a single package (I never use workspaces) and always compile for a single target.est31 commentedon Aug 5, 2023
Nice, seems the azul usage has been removed in the meantime: fschutt/azul@6096a1b#diff-2486c782348527d5e8a121166f399ed1449c5960b8079859b573cbc5f8b184c2L3
Now only the usage in wasmer is remaining. It has been reduced to a single attr:
https://github.com/wasmerio/wasmer/blob/ccbe870770604ecb61f2d8e0fa298504381f6784/lib/api/src/lib.rs#L29
I wonder whether it would be possible to enable
cdylib
on the api crate unconditionally?nyurik commentedon Sep 5, 2023
Note that the docs still suggest this attribute
bjorn3 commentedon Sep 5, 2023
Using plain
#![crate_name = "..."]
and#![crate_type = "..."]
is fine. Using them behind a#![cfg_attr(...)]
triggers this lint.44 remaining items