Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document the difference between 'crate-type = ["proc-macro"]' and 'proc-macro = true' #5310

Closed
ExpHP opened this issue Apr 6, 2018 · 5 comments · Fixed by #6256

Comments

@ExpHP
Copy link
Contributor

commented Apr 6, 2018

...whatever it is.

All I can really see is that crate-type = ["proc-macro"] makes rustdoc die with proc-macro crate not dylib when used in a path dependency.


(er... now that I think about it, I wonder if that's a bug in rustdoc)
(...or even a bug in cargo)
(...or rustc even! On stable, it produces the same error, but as an ICE!)

@ExpHP

This comment has been minimized.

Copy link
Contributor Author

commented Apr 7, 2018

soo.... just in case the aforementioned error is a bug in... whatever it is that is buggy, here's a repro:

git clone https://github.com/ExpHP/unbox-macro -b minimize-cargo-5310
cd unbox-macro
cargo doc
@ExpHP

This comment has been minimized.

Copy link
Contributor Author

commented Jul 22, 2018

crate-type = ["proc-macro"] seen in the wild:

https://github.com/goffrie/plex/blob/d59296b7663d8ed3d9ebbc7266c859903663ca69/Cargo.toml

Everything appears to work fine on the crate author's end, but cargo test fails with a mysterious error in downstream crates. I'm beginning to feel this is less of a documentation bug, and more of an actual bug.

ExpHP added a commit to exphp-forks/plex that referenced this issue Jul 22, 2018
@ehuss

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2018

Does anyone have ideas on how we can make this friction go away?

One way this comes up is when you don't set anything in Cargo.toml, you get this error message:

error: the #[proc_macro] attribute is only usable with crates of the proc-macro crate type

which might lead one to set the crate-type and lead to these mysterious problems.

One thought I had is to just automatically set proc-macro if the crate-type is set to proc-macro. I can't think of any immediate harm that might cause. Unfortunately this wouldn't work if you set the crate type with an attribute.

I'm not sure if adding more documentation will help, since the documentation already directs people towards proc-macro = true. Perhaps the error message could contain some cargo-specific hints, but there isn't much precedent for doing that and seems a little out of place.

@ExpHP

This comment has been minimized.

Copy link
Contributor Author

commented Oct 27, 2018

Hmm, so the troublesome error message comes from rustc, I gather?

The current impression I get is that it is more or less a bug that cargo even allows crate-type = ["proc-macro"]. If this is the case, I think it should be forbidden on cargo's end (read: deprecated, with a warning that points you in the right direction).

Edit: Hmm. Okay, I see what you mean with setting it via attribute. Maybe that could be deprecated as well in rustc, although tbh it doesn't bother me so much that cargo doc is broken if you do this.

@alexcrichton

This comment has been minimized.

Copy link
Member

commented Oct 29, 2018

@ehuss could we perhaps both update the rustc error message as well as simply interpret crate-type = ["proc-macro"] as a proc-macro = true? (perhaps with a warning to prefer the latter)

bors added a commit that referenced this issue Nov 6, 2018
Auto merge of #6256 - ehuss:proc-macro-crate-type, r=alexcrichton
Treat "proc-macro" crate type the same as `proc-macro = true`

Effectively closes #5310 since they are now identical.

@bors bors closed this in #6256 Nov 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.