Make deprecated_cfg_attr_crate_type_name a hard error

[est31]

Turns the forward compatibility lint added by #83744 into a hard error, so now, while the #![crate_name] and #![crate_type] attributes are still allowed in raw form, they are now forbidden to be nested inside a #![cfg_attr()] attribute.

The following will now be an error:

#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]

This code will continue working and is not deprecated:

#![crate_name = "foobar"]
#![crate_type = "lib"]

The reasoning for this is explained in #83744: it allows us to not have to cfg-expand in order to determine the crate's type and name.

As of filing the PR, exactly two years have passed since #99784 has been merged, which has turned the lint's default warning level into an error, so there has been ample time to move off the now-forbidden syntax.

cc #91632 - tracking issue for the lint

[rustbot]

r? @cjgillot

rustbot has assigned @cjgillot.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[bors]

☔ The latest upstream changes (presumably #129665) made this pull request unmergeable. Please resolve the merge conflicts.

[traviscross]

@rfcbot fcp merge

We discussed this is the meeting today and were feeling positively toward it.

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

@rfcbot reviewed

This seems like a good simplification, but we should notify crate authors that may be affected with at least a ping. I'd like to know if there is truly no way to support their use case.

[joshtriplett]

Documenting some supporting rationale:

1. We're assuming that --crate-type will be sufficient to migrate to.

2. We expect that if the warned-about (and later errored-about) thing being allowed was an issue for anyone, the affected crates would have raised this upstream.

[nikomatsakis]

Based on a google code search, I want to give a headsup to

• wasmerio/wasmer -- cc @syrusakbary and @Hywan (top two contributors) -- allows the lint here

[bjorn3]

The usage in wasmer seems to be entirely ineffective:

$ cargo +stable build --no-default-features --features "wasmer/js wasmer/std" -p wasmer --target wasm32-unknown-unknown
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
$ ls target/wasm32-unknown-unknown/debug
build  deps  examples  incremental  libwasmer.d  libwasmer.rlib
$ ls target/wasm32-unknown-unknown/debug/deps | grep wasmer
libwasmer-aac61f984f72830e.rlib
libwasmer-aac61f984f72830e.rmeta
libwasmer_types-e9cfd7530a67cd97.rlib
libwasmer_types-e9cfd7530a67cd97.rmeta
wasmer-aac61f984f72830e.d
wasmer_types-e9cfd7530a67cd97.d

No .wasm file is produced that would be expected from a cdylib.

On the other hand even if I remove #![cfg_attr(feature = "js", crate_type = "cdylib")], cargo +stable rustc --no-default-features --features "wasmer/js wasmer/std" -p wasmer --target wasm32-unknown-unknown --crate-type cdylib produces a wasmer.wasm file. The usage of cargo rustc + --crate-type cdylib instead of cargo build is what causes the crate type to be changed to cdylib.

[RalfJung]

So this has not gone through a "report in deps" stage. Fine for me, but I just wanted to call it out for awareness.

[est31]

I think with the low usage it has in the ecosystem, the step can be skipped.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[Urgau]

LGTM. Thanks for pushing this forward.

r? @Urgau
@bors r+

[bors]

📌 Commit 00ed47b has been approved by Urgau

It is now in the queue for this repository.

[bors]

⌛ Testing commit 00ed47b with merge 8422e27...

[bors]

☀️ Test successful - checks-actions
Approved by: Urgau
Pushing 8422e27 to master...

[rust-timer]

Finished benchmarking commit (8422e27): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.4%, secondary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.3%	[2.3%, 6.4%]	2
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-1.5%	[-1.5%, -1.5%]	1
Improvements ✅ (secondary)	-1.2%	[-1.8%, -0.9%]	3
All ❌✅ (primary)	2.4%	[-1.5%, 6.4%]	3

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 773.691s -> 774.004s (0.04%)
Artifact size: 329.52 MiB -> 329.48 MiB (-0.01%)