Skip to content
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.

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

Clarify nightly style policy #180

Merged
merged 6 commits into from
Jul 5, 2023
Merged
Changes from 1 commit
Commits
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
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
compiler-errors marked this conversation as resolved.
Show resolved Hide resolved
compiler-errors marked this conversation as resolved.
Show resolved Hide resolved
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
compiler-errors marked this conversation as resolved.
Show resolved Hide resolved
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.
compiler-errors marked this conversation as resolved.
Show resolved Hide resolved

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
compiler-errors marked this conversation as resolved.
Show resolved Hide resolved
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

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.