From ebdff2abd925d29d56749d635f0b86c59c5b0987 Mon Sep 17 00:00:00 2001 From: Michael Goulet Date: Wed, 3 May 2023 03:17:35 +0000 Subject: [PATCH 1/6] Clarify nightly style policy --- nightly-style-policy.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 nightly-style-policy.md diff --git a/nightly-style-policy.md b/nightly-style-policy.md new file mode 100644 index 0000000..3e548fa --- /dev/null +++ b/nightly-style-policy.md @@ -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. + +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 +formatting at the time of stabilization, with any breaking changes weighted +according to the principle stated above. \ No newline at end of file From 9863dcda7c477cb93e46be826992cc9fe602e699 Mon Sep 17 00:00:00 2001 From: Michael Goulet Date: Wed, 14 Jun 2023 11:45:53 -0700 Subject: [PATCH 2/6] caleb's applicable suggestions Co-authored-by: Caleb Cartwright --- nightly-style-policy.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/nightly-style-policy.md b/nightly-style-policy.md index 3e548fa..41e8d55 100644 --- a/nightly-style-policy.md +++ b/nightly-style-policy.md @@ -5,22 +5,26 @@ new variants to AST representation), they should modify rustfmt in such a way to keep existing formatting verbatim. 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 +syntax being specified by the style guide. The initial authors of PRs +implementing new features in rust-lang/rust are encouraged, but not +required, to open a PR against +[rustfmt](https://github.com/rust-lang/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 +Much like breaking nightly feature changes in the Rust compiler, any changes +to formatting behavior for nightly syntax should be made cautiously and with +thorough consideration to avoid churn. Changes should not be 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 +formatting behavior. At this point, T-style may also propose alternative formatting at the time of stabilization, with any breaking changes weighted according to the principle stated above. \ No newline at end of file From af1b04306a0951c82311f05609153f1390e12571 Mon Sep 17 00:00:00 2001 From: Michael Goulet Date: Wed, 14 Jun 2023 18:49:17 +0000 Subject: [PATCH 3/6] policy -> procedure --- nightly-style-policy.md => nightly-style-procedure.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename nightly-style-policy.md => nightly-style-procedure.md (100%) diff --git a/nightly-style-policy.md b/nightly-style-procedure.md similarity index 100% rename from nightly-style-policy.md rename to nightly-style-procedure.md From 35597250f5fcfa27acf5fd8c1c827d1c1e13d3ad Mon Sep 17 00:00:00 2001 From: Michael Goulet Date: Wed, 14 Jun 2023 18:53:00 +0000 Subject: [PATCH 4/6] tweaks --- nightly-style-procedure.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/nightly-style-procedure.md b/nightly-style-procedure.md index 41e8d55..cd724a1 100644 --- a/nightly-style-procedure.md +++ b/nightly-style-procedure.md @@ -1,3 +1,8 @@ +The style guide may or may not prescribe formatting behavior for nightly syntax +in preparation for a feature's eventual stabilization, and to record in +principal the behavior implemented by rustfmt around nightly syntax, but that +behavior is not binding until the feature is stabilized. + 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 @@ -27,4 +32,4 @@ the feature. Feature stabilization should be blocked on confirmation and codification of formatting behavior. At this point, T-style may also propose alternative formatting at the time of stabilization, with any breaking changes weighted -according to the principle stated above. \ No newline at end of file +according to the breaking changes principle stated above. From f78907f5123c7a765d325aa67d4c9f339f1ce3e9 Mon Sep 17 00:00:00 2001 From: Michael Goulet Date: Wed, 14 Jun 2023 12:34:16 -0700 Subject: [PATCH 5/6] Update nightly-style-procedure.md --- nightly-style-procedure.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/nightly-style-procedure.md b/nightly-style-procedure.md index cd724a1..cb63d0c 100644 --- a/nightly-style-procedure.md +++ b/nightly-style-procedure.md @@ -1,6 +1,6 @@ The style guide may or may not prescribe formatting behavior for nightly syntax -in preparation for a feature's eventual stabilization, and to record in -principal the behavior implemented by rustfmt around nightly syntax, but that +in preparation for a feature's eventual stabilization or to reflect actual +the behavior implemented by rustfmt around nightly syntax, but that behavior is not binding until the feature is stabilized. Initial PR(s) implementing new syntax filed against rust-lang/rust should From 468570a02856a6bbe3994164e1a16a13b56b5cf4 Mon Sep 17 00:00:00 2001 From: Michael Goulet Date: Wed, 21 Jun 2023 13:41:48 -0700 Subject: [PATCH 6/6] Clarify "nightly" style guide chapter --- nightly-style-procedure.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/nightly-style-procedure.md b/nightly-style-procedure.md index cb63d0c..a4babf4 100644 --- a/nightly-style-procedure.md +++ b/nightly-style-procedure.md @@ -1,7 +1,8 @@ The style guide may or may not prescribe formatting behavior for nightly syntax -in preparation for a feature's eventual stabilization or to reflect actual -the behavior implemented by rustfmt around nightly syntax, but that -behavior is not binding until the feature is stabilized. +in the "nightly" chapter in preparation for a feature's eventual stabilization +or to reflect actual the behavior implemented by rustfmt around nightly syntax. +This behavior is not binding until the feature is stabilized and the text is moved +into the appropriate section of the style guide. Initial PR(s) implementing new syntax filed against rust-lang/rust should generally leave the rustfmt subtree untouched. In cases that that need to