Tracking issue for future-incompatibility lint deprecated_cfg_attr_crate_type_name

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

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…

@bjorn3

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?

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

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.

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?

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.

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.

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?

Note that the docs still suggest this attribute

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

@bjorn3

Is there a recommended way for feature-controlled crate-type, e.g. with a build.rs? A crate with optional cdylib type would also need to have a feature-gated panic handler and possibly other things, so it would still have to have a cdylib feature in Cargo.toml. So one would have to run this -- a probable source of bugs?

RUSTFLAGS='--crate-type cdylib' cargo build --features cdylib

P.S. Good point @bjorn3, thx.

cargo rustc accepts --crate-type to override the crate type. A build script can't change the crate type and #![crate_type] doesn't work as youbl did intend with cargo anyway. Rustc requires that --crate-type and #![crate_type] match up if both are specified afaik and cargo always passes --crate-type.

Auto merge of rust-lang#129670 - est31:cfg_attr_crate_type_name_error…

Closing as #129670 has been merged. It's on the path to being a hard error in the 1.83.0 release of Rust.

@bjorn3

I've tried to work on the followup refactor to #129670 to remove mutable state from Session but found that it's already been done in #114622. With that PR, what is written in the explanation section of this issue is obsolete: there is no mutable state in Session any more. I'm wondering now about further justifications for the change, not from a "should we halt this now" point of view, but from a "how to explain it" view.

directory for the incr comp session dir

In #83744 @bjorn3 writes:

[I]f we want to add incremental compilation to macro expansion or even parsing, we need the StableCrateId to be created together with the Session or even earlier as incremental compilation determines the incremental compilation session dir based on the StableCrateId.

general ordering concerns

With this change it's easier to determine the crate name earlier in the compilation, which might be useful for structuring the state. All one needs is to peek into the provided source file, with no other state needed. Obtaining the crate name and crate type are very dependency-free operations now.

I think it would now be possible to revert #114622 in a way that doesn't re-introduce the global mutable state in TyCtxt. This would also allow

rust/compiler/rustc_incremental/src/persist/fs.rs

Lines 611 to 612 in 06d261d

    
           let crate_name = find_crate_name(sess, &[]); 
        
           let crate_types = collect_crate_types(sess, &[]);

to avoid recomputing the crate name and type. And the same for

rust/compiler/rustc_interface/src/util.rs

Lines 466 to 470 in 06d261d

    
           let crate_name = sess 
        
               .opts 
        
               .crate_name 
        
               .clone() 
        
               .or_else(|| rustc_attr::find_crate_name(attrs).map(|n| n.to_string()));

(this function doesn't handle #![crate_type] correctly at all right now.) And

rust/compiler/rustc_driver_impl/src/lib.rs

Lines 752 to 753 in 06d261d

    
           let t_outputs = rustc_interface::util::build_output_filenames(attrs, sess); 
        
           let id = rustc_session::output::find_crate_name(sess, attrs);

and

rust/compiler/rustc_driver_impl/src/lib.rs

Line 766 in 06d261d

let id = rustc_session::output::find_crate_name(sess, attrs);

can also avoid recomputing the crate name.

This would also allow

rust/compiler/rustc_incremental/src/persist/fs.rs

Lines 611 to 612 in 06d261d

let crate_name = find_crate_name(sess, &[]);

let crate_types = collect_crate_types(sess, &[]);

to avoid recomputing the crate name and type.

Incidentally my open PR #127581 does away with recomputing the crate name inside fs.rs.

@bjorn3

@bjorn3 @fmease thank you!

feat(rln-wasm): bring back wasm support for zerokit

community/lcov2cobertura: remove deprecated lints to fix build

Navigation Menu

Repository navigation

Tracking issue for future-incompatibility lint `deprecated_cfg_attr_crate_type_name` #91632

What is this lint about

Explanation

How to fix this warning/error

Current status

19 remaining items

directory for the incr comp session dir

general ordering concerns

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	let crate_name = find_crate_name(sess, &[]);
	let crate_types = collect_crate_types(sess, &[]);

	let crate_name = sess
	.opts
	.crate_name
	.clone()
	.or_else(\|\| rustc_attr::find_crate_name(attrs).map(\|n\| n.to_string()));

	let t_outputs = rustc_interface::util::build_output_filenames(attrs, sess);
	let id = rustc_session::output::find_crate_name(sess, attrs);

Tracking issue for future-incompatibility lint deprecated_cfg_attr_crate_type_name #91632

Description

What is this lint about

Explanation

How to fix this warning/error

Current status

Activity

est31 commented on Jul 26, 2022

est31 commented on Mar 21, 2023

bjorn3 commented on Mar 21, 2023

est31 commented on Mar 21, 2023

ia0 commented on Jun 14, 2023

bjorn3 commented on Jun 14, 2023

ia0 commented on Jun 15, 2023

est31 commented on Aug 5, 2023

nyurik commented on Sep 5, 2023

bjorn3 commented on Sep 5, 2023

nyurik commented on Sep 5, 2023

bjorn3 commented on Sep 5, 2023

19 remaining items

est31 commented on Oct 8, 2024

est31 commented on Oct 17, 2024

directory for the incr comp session dir

general ordering concerns

bjorn3 commented on Oct 17, 2024

fmease commented on Oct 17, 2024

est31 commented on Oct 17, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for future-incompatibility lint `deprecated_cfg_attr_crate_type_name` #91632