Fix unknown-crate when using -Z self-profile with rustdoc

[jyn514]

... by removing a duplicate crate_name field in interface::Config,
making it clear that rustdoc should be passing it to config::Options instead.

Unblocks rust-lang/rustc-perf#797.

[rust-highfive]

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

[jyn514]

    Compiling test v0.0.0 (/checkout/library/test)
error: unused attribute
  --> library/test/src/lib.rs:20:1
   |
20 | #![crate_name = "test"]
   | ^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `-D unused-attributes` implied by `-D warnings`

error: crate-level attribute should be in the root module
  --> library/test/src/lib.rs:20:1
   |
20 | #![crate_name = "test"]
   | ^^^^^^^^^^^^^^^^^^^^^^^

I don't know why this is going wrong :/ the only behavior I changed in rustc was https://github.com/rust-lang/rust/pull/79586/files#diff-5d2a824073d4fcc6b4e60bae734988e6e37f6483fff54626ab3352774d2c55cfL188, which reads crate_name from opts instead of config, but config.crate_name is never set to anything other than None! What am I missing?

[jyn514]

Actually I might know the issue - crate_name is now Some where it was None before, so find_crate_name is never executed.

Is it intended that rustc looks at #[crate_name] even when --crate-name is passed? I found this comment:

rust/compiler/rustc_session/src/output.rs

Lines 54 to 59 in b7ebc6b

	// Look in attributes 100% of the time to make sure the attribute is marked
	// as used. After doing this, however, we still prioritize a crate name from
	// the command line over one found in the #[crate_name] attribute. If we
	// find both we ensure that they're the same later on as well.
	let attr_crate_name =
	sess.find_by_name(attrs, sym::crate_name).and_then(|at| at.value_str().map(|s| (at, s)));

So I guess find_crate_name should be run whether or not --crate-name is set?

[Mark-Simulacrum]

Hm, I am a bit worried -- is this a breaking change? It sounds like it would be, since we presumably weren't validating previously?

[jyn514]

See #79586 (comment) - this is the same behavior as before, just easier to understand. Previously, the crate name would never be Some so this would always run.

[wesleywiser]

We probably don't want this debug statement, or at least, we don't want it in the current form 🙂

[jyn514]

I'm not sure what the policy on debug logging is - I'm happy to revert this, but I'm not sure what a better form would be.

[wesleywiser]

I think in general we try to include some kind of context about what is going on when this value is logged. Seeing for example

[DEBUG]    rustc_data_structures::profiling     my_crate_name` 

isn't super useful but something like debug!("Creating self-profiler: output_directory = {:?}, crate_name = {:?}, event_filters = {:?}", output_directory, crate_name, event_filters); would add more context about what is being logged and could be useful for someone else in the future.

[camelid]

Btw, what does the prefixed ? do here?

[jyn514]

@camelid https://docs.rs/tracing/0.1.22/tracing/?search=#recording-fields

[davidtwco]

LGTM and I think the review comments have been addressed:

@bors r+

[bors]

📌 Commit 878cfb5 has been approved by davidtwco

[bors]

⌛ Testing commit 878cfb5 with merge 2203527...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 2203527 to master...