Tracking issue for future-incompatibility lint `deprecated_cfg_attr_crate_type_name`

[bjorn3]

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-default
• Make forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default #99784 makes the deprecated_cfg_attr_crate_type_name lint deny-by-default
• PR Make deprecated_cfg_attr_crate_type_name a hard error #129670 makes the deprecated_cfg_attr_crate_type_name lint a hard error

[est31]

I've filed a PR to make this deny-by-default: #99784

[est31]

Since the grep.app seach conducted in the original PR there have been two new crates using it, despite the lint:

wasmer:

#![cfg_attr(feature = "js", crate_type = "cdylib")]
#![cfg_attr(feature = "js", crate_type = "rlib")]

azul:

#![cfg_attr(feature ="cdylib", crate_type = "cdylib")]
#![cfg_attr(feature ="staticlib", crate_type = "staticlib")]
#![cfg_attr(feature ="rlib", crate_type = "rlib")]

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 for crate_type within cfg_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 has crate-type set in Cargo.toml, and then include!()s the lib.rs?

[bjorn3]

Wouldn't cargo build --crate-type cdylib suffice in both cases?

[est31]

It should actually, good point. Maybe the wasm-pack equivalent of it for wasmer, 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]

Wouldn't cargo build --crate-type cdylib suffice in both cases?

This doesn't work for me. My understanding is that --crate-type is only a rustc flag, you can't use it with cargo build. I would really like it to work with cargo build though. Is this planned?

[bjorn3]

Right, --crate-type is a flag for cargo rustc, not cargo build. My bad. cargo rustc should work in most cases that cargo build does. The main limitation is that it requires a single target within a single package rather than allowing multiple packages and targets.

[ia0]

Oh that's very interesting, I didn't know that. I always assumed cargo rustc was just a wrapper around a single invocation of rustc 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 where cargo 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]

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]

Note that the docs still suggest this attribute

[bjorn3]

Using plain #![crate_name = "..."] and #![crate_type = "..."] is fine. Using them behind a #![cfg_attr(...)] triggers this lint.