Fix servo crate name confliction on documentation

[wusyong]

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix Docs are not built for libservo #32412

• There are tests for these changes OR it should be able to build all ports
• These changes do not require tests because ___

The name of winit binary is conflicted with servo crate.
We can't read documentation of servo library crate at the moment.
It's actually the winit binary documentation.

[mrobinson]

Hrm. I have been considering this change for a while, but I'm not sure if it's the right one. Renaming the library because of a documentation issue seems like the wrong incentive structure. Is there a way to fix the documentation without the rename. Perhaps we could move the runner/winit port documentation out of rustdoc and simply disable documentation for that crate?

[wusyong]

The tracking issue of this bug is cargo/#6313. I didn't follow through all conversations, but the beginning of the thread said this will be considered a hard error in the future.

Adding doc = false to the bin will just make mach build generate nothing. Another way I could think of is cargo doc -p libservo with features you specified and add this to mach. But this still won't solve the winit binary name is conflicted with servo library.

[mrobinson]

An alternate approach here might be to rename the runner project, but have it produce the a binary with the name "servo." It's my understanding that the binary artifact itself will not conflict, but the documentation might.

[wusyong]

I tried this before. Artifacts will not conflict indeed, but doc will. Carge doc will still warn about this if there are crates with same names despite the fact that they might have different package names.

[bors-servo]

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

[wusyong]

I think another workaround could be adding another command argument like --lib instead.
I can look into it if you think this is better.
But we'll need to verify other mach commands because they all go through run_cargo_build_like_command function.

[mrobinson]

I suspect that if changing the name of the crate is on the only way to fix this, it makes more sense to change the name of the crate of the binary rather than the crate of the library.