Skip to content

Clarify nightly style policy #180

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.

Sign up for GitHub

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

Merged
merged 6 commits into from
Jul 5, 2023
+36 −0
Merged

Clarify nightly style policy #180

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ebdff2a
Clarify nightly style policy
compiler-errors May 3, 2023
9863dcd
caleb's applicable suggestions
compiler-errors Jun 14, 2023
af1b043
policy -> procedure
compiler-errors Jun 14, 2023
3559725
tweaks
compiler-errors Jun 14, 2023
f78907f
Update nightly-style-procedure.md
compiler-errors Jun 14, 2023
468570a
Clarify "nightly" style guide chapter
compiler-errors Jun 21, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions nightly-style-policy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
Initial PR(s) implementing new syntax filed against rust-lang/rust should
generally leave the rustfmt subtree untouched. In cases that that need to
modify rustfmt (for example, to fix compiler errors that come from adding
new variants to AST representation), they should modify rustfmt in such a
way to keep existing formatting verbatim.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for awareness, I will update this later with a direct link to a "how to" rustfmt doc on this once we have one, refs rust-lang/rustfmt#5770


Rustfmt is allowed to implement nightly-only formatting behavior without that
syntax being specified by the style guide. Initial PR implementors are
encouraged but not required to open a PR against rustfmt suggesting an initial
formatting behavior, or formatting may later be implemented as a PR by anyone,
pending approval of the implementation from T-rustfmt. T-style should be
notified to approve the interim style proposed by these PRs, but this decision
is not binding and may be revisited until the feature is stabilized and the
formatting is codified in the style guide.

Much like breaking nightly feature changes in the Rust compiler, changes should
be not done unnecessarily, and should take into account the feature's adoption
and readiness for stabilization. However, changes may be done until the feature
is stabilized for various reasons: new understanding of the feature's usage in
the language, recommendation from T-style, or changes in the implementation of
the feature.

Feature stabilization should be blocked on confirmation and codification of
formatting bheavior. At this point, T-style may also propose alternative
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to recall whether t-style wanted to only block on the rules being codified in the style guide, or both codified rules and rustfmt implementation being completed.

I also don't recall if we discussed whether either needs explicit buy-in from t-lang.

And one typo:

Suggested change
Feature stabilization should be blocked on confirmation and codification of
formatting bheavior. At this point, T-style may also propose alternative
Feature stabilization should be blocked on confirmation and codification of
formatting behavior. At this point, T-style may also propose alternative

Copy link
Member Author

@compiler-errors compiler-errors Jun 14, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or both codified rules and rustfmt implementation being completed.

I think that should be handled between T-rustfmt and T-lang specifically.

I also don't recall if we discussed whether either needs explicit buy-in from t-lang.

I can open an issue on the T-lang repo about T-style codification being a blocker though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any thoughts/objections to me proposing this as an agenda item for this week's meet, and then creating an action item for this?

for my .02 we could go ahead and merge as-is (barring objections/requested changes from others) and then if necessary revisit and adjust the text if the t-lang conversations necessitate doing so

formatting at the time of stabilization, with any breaking changes weighted
according to the principle stated above.