Amend style guide section for formatting where clauses in type aliases

[compiler-errors]

This PR has two parts:

1. Amend wording about breaking before or after the =, which is a style guide bugfix to align it with current rustfmt behavior.
2. Explain how to format trailing (Proposal: Change syntax of where clauses on type aliases #89122) where clauses, which are preferred in both GATs (Change location of where clause on GATs #90076) and type aliases (Unlock trailing where-clauses for lazy type aliases #114662).

r? @joshtriplett

[rustbot]

Some changes occurred in src/doc/style-guide

cc @rust-lang/style

[calebcartwright]

Part of what was also done in #113380 was removing some (but not all) usages of "prefer".

My interpretation of this is that this one is indeed intentional, targeted more at the human developer, aware that the clause can go in either/both position, and trying to encourage the latter because we feel like the style guide has to provide rules for both positions?

(edits: repeated typos, oh my)

[joshtriplett]

I don't think we should use "prefer" in any case where we expect a tool to do any kind of enforcement. But in this case, I don't think we expect a tool to convert between the two where positions?

[compiler-errors]

Tools should not convert. Prefix WC is an error in the positions where it matters, so maybe we don't even need to tell them about preference at all. Happy to reword or remove.

[calebcartwright]

Tools, including rustfmt, certainly could and it's probably worth noting that during some of the earlier rfc and implementation discussions that was explicitly suggested/requested.

I know there's differing philosophies around the should part of the question though

[compiler-errors]

Well given that I'm probably in the position of having the least context and caring the least about this specific wording, one of y'all are free to suggest a rewording here.

[compiler-errors]

I think (A) is the best way to go here, or to just remove the wording altogether and leave it up to the language to enforce what to do with where clause placement. The guide could perhaps just explain what to do in the cases of prefix, suffix, and prefix+suffix where clauses and take no opinions.

[joshtriplett]

FWIW, I don't have objections to either (A) or (C) in isolation; however, I'd object to doing (C) if we're not waiting for a new style edition, because that would produce more churn.

As for (B), I think the style guide should be providing documentation for how to format any language construct that exists in the language. If something hasn't been removed from the language, we should document how to handle it (even if the handling is (C), "convert it to something else"). We shouldn't leave things undocumented/implied.

[joshtriplett]

OK, there's a bigger overriding consideration here. @compiler-errors just pointed out to me that the two locations have a semantic difference: where clauses before the = aren't enforced, while where clauses in the later position (which for item-level type aliases are currently only allowed in nightly) are enforced. So we should never move one to the other as a matter of mere style.

That means we should just describe both positions, and state that since there's a semantic difference between them, the Rust style does not express a preference or suggest moving constraints from one position to the other.

[compiler-errors]

Will update, which should resolve this convo. Hopefully after that we can kick off an FCP?

[calebcartwright]

Yup, agreed with moving ahead

As for (B), I think the style guide should be providing documentation for how to format any language construct that exists in the language

I know this is more a framing/way of thinking moving forward, but I wanted to add before I forget that one potential area of nuance to this is to what degree, if any, the guide must account for formatters that operate prior to the AST validation stage (as rustfmt does), and things that aren't technically valid/exist in the language but which do pass the initial parsing phase

[compiler-errors]

I'm just gonna go ahead and start the FCP here.

@rfcbot fcp merge

[rfcbot]

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

• @calebcartwright
• @compiler-errors
• @joshtriplett
• @yaahc

Concerns:

• require all checkboxes resolved by Amend style guide section for formatting where clauses in type aliases #114901 (comment)

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!

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. 🔔

[calebcartwright]

@rfcbot concern require all checkboxes

(we require a ✔️ from all team members so allow Jane time to review)

[dtolnay]

Jane reviewed last week. @calebcartwright could you resolve the concern?

[calebcartwright]

@rfcbot resolved require all checkboxes

[rfcbot]

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

[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.

[calebcartwright]

@bors r+ rollup=always

[bors]

📌 Commit 2ff14b0 has been approved by calebcartwright

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2ff14b0 with merge 7b4b1b0...

[bors]

☀️ Test successful - checks-actions
Approved by: calebcartwright
Pushing 7b4b1b0 to master...

[rust-timer]

Finished benchmarking commit (7b4b1b0): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.5%, -2.8%]	3
All ❌✅ (primary)	-	-	0

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: 630.239s -> 632.097s (0.29%)
Artifact size: 317.29 MiB -> 317.30 MiB (0.00%)