RFC: Rustdoc configuration via Cargo (includes feature descriptions) by tgross35...

		# Rationale and alternatives
		[rationale-and-alternatives]: #rationale-and-alternatives

		At a high level, the following changes will be necessary:
		1. Cargo will accept a new `[tools.rustdoc]` table that it does not validate

I won't speak for clippy, but can say authoritatively that this is not accurate for rustfmt. For reference many of the issues were articulated back in #3389

I wrote this hastily and didn't articulate the goal very well. To be clear: are you saying that rustfmt has no interest in being configurable via Cargo.toml, even if it doesn't need to parse the file itself? I did see #3389 (comment) but I didn't see any specifics there.

It is a good point that the clippy discussion is moot here, since that manifested into [lints]

I did see #3389 (comment) but I didn't see any specifics there.

#3389 (comment)

To be clear: are you saying that rustfmt has no interest in being configurable via Cargo.toml

I'm saying that it's not accurate to state that rustfmt is "currently in the process of figuring out how to also allow specification via Cargo.toml". We're absolutely not working towards this, nor are we even contemplating it.

even if it doesn't need to parse the file itself?

I don't know how this can be avoided. I'm not sure about rustdoc, but I know that rustfmt (and rustc) are regularly utilized independent of cargo. In those cases, rustfmt would only have two options: either deal directly with the cargo manifest file or completely ignore it. Both of those have significant drawbacks, a couple of which I spoke to a bit in the comment linked above.

I'm saying that it's not accurate to state that rustfmt is "currently in the process of figuring out how to also allow specification via Cargo.toml". We're absolutely not working towards this, nor are we even contemplating it.

That makes sense; I have seen feature requests and users.rust-lang questions, but I never saw the official follow up.

I don't know how this can be avoided. I'm not sure about rustdoc, but I know that rustfmt (and rustc) are regularly utilized independent of cargo. In those cases, rustfmt would only have two options: either deal directly with the cargo manifest file or completely ignore it. Both of those have significant drawbacks, a couple of which I spoke to a bit in the comment linked above.

If the design in this RFC were to be followed, rustfmt would just accept an argument like this:

rustfmt . --config-json '{"array_width": 100, "wrap_comments": true, ...}'

The config argument would be created by Cargo (or other build systems) and the data would follow the exact schema of rustfmt.toml so the same deserializers can be used. So rustfmt doesn't need to be aware of Cargo.toml or parse it itself.

I haven't been able to view your comment, if you already discussed something like this there. Github navigates to the PR but not the comment, maybe it's on a rebased commit (there's nothing on this page either, which is where it navigates when I click your name in the "Reviewers" list, and it's nowhere in the entire chain of that PR for me). Would you mind pasting the contents here?

Indeed the direct link seems to be inoperable, thanks GitHub Given the scope and objective of this thread, I'm going to put the text of that comment into a collapsed section, as I don't want things to get over-indexed on rustfmt when rustfmt isn't really a focus topic of this proposal; I just didn't want there to be any misrepresentation about rustfmt happenings in the text.

In a similar vein, I'd rather not try to debate or solution rustfmt specifics here. Suffice to say the rustfmt position is "no", we're not actively pursuing changing that, and there's several challenges that would have to be discussed and resolved before it'd be remotely feasible for rustfmt go that route (setting aside whether or not we should). Such discussions would be better suited to either t-rustfmt on zulip or in the r-l/rustfmt repo, though full transparency, I don't feel we've got the adequate bandwidth right now, even just to dive more deeply into the challenges and design topics.

Comment text from PR 3389#discussion_r1110364556
I will also speak into the rustfmt specifics of this, but I first want to underscore my view that it's important to consider this holistically around the experience and expectations developers may have for configuration across the various official tools if we move ahead with this proposal.

I do not have the receipts handy, but I'm sure many have seen/heard comments to the effect of "I have edition set to 2018 in Cargo.toml, but when I run `rustc ...` it's using edition 2015 instead of edition 2018".

Essentially, it's a relatively common occurrence for some developers to (incorrectly) assume that info defined in Cargo.toml is honored by all tools even outside a cargo context. While this isn't necessarily a problem for tools typically, or always, invoked as part of some cargo ... subcommand flow, it's a persistent topic that pops up for tools that are utilized from both cargo and non-cargo contexts (rustc, rustdoc, rustfmt).

Fundamentally, my concern is that supporting more configuration values in Cargo.toml could exacerbate this issue. If this proceeds, then I'd love to find a way to help ameliorate this by somehow increasing awareness of when values in Cargo.toml can be used/will be honored, and crucially, when they won't. (though unfortunately I've no prescriptions).

As for rustfmt, quick overview for anyone unfamiliar:

rustfmt can and often is invoked in a cargo context via `cargo fmt`, but it's also commonly invoked directly both by humans and machines (e.g. editor/ide use cases to format single file, subset of a single file, etc.). In the `cargo fmt` scenario obviously relevant Cargo.toml info is utilized, but `rustfmt ...` itself doesn't, so when running `rustfmt` directly, one needs to explicitly specify the edition to use a non-2015 edition. rustfmt also supports various [config options](https://rust-lang.github.io/rustfmt/?version=v1.5.1&search=) that can be specified in a rustfmt.toml file.

We've had requests to support allowing rustfmt config options to also be defined in Cargo.toml, but it's something we've always pushed back on for a number of reasons, one of which being that rustfmt would either have to ignore the edition value in Cargo.toml while honoring other aspects of Cargo.toml, or essentially introduce breaking behavior where the default/implicit edition rustfmt would utilize would change in some contexts (since the ecosystem default is still 2015 and rustfmt does not currently utilize Cargo.toml defined edition, like rustc and rustdoc)

I understand this proposal is focused on lints, and it's not my intent to scope creep. I would, however, feel more comfortable if we could either set an upper bound on how far this could extend to other tools (explicitly, even if only notionally, to not expand beyond lints), or determine if this could/should expand, and if so then try to address the potential challenges this could present for other tools

another comment from that same thread that highlights some of the issues
Shared as a screen grab: