-
Notifications
You must be signed in to change notification settings - Fork 14k
Stabilize Frontmatter #148051
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
base: main
Are you sure you want to change the base?
Stabilize Frontmatter #148051
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -524,7 +524,6 @@ pub fn check_crate(krate: &ast::Crate, sess: &Session, features: &Features) { | |
| gate_all!(contracts_internals, "contract internal machinery is for internal use only"); | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (Commenting on an arbitrary line to make this discussion threaded) From the PR description (emphasis and ellipses mine):
In #146340 I actually struck a (temporary) compromise: We do still strip/lex/recognize frontmatter (and shebang) in item-context Now, I don't know what's best here. I'm eager to know your and T-lang's stance on the matter. Note that we do strip shebang in expression/statement-context (†): If that PR was accepted it would mean that we would strip shebang+frontmatter in item-ctxt includes and wouldn't strip either(!) shebang or frontmatter in expr/stmt-ctxt includes which would make the behavior of shebang+frontmatter consistent thereby fulfilling the original goal of "This applies anywhere shebang stripping is performed." in this specific case (obviously the goal wasn't achieved in other cases, like in the proc_macro API case).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks! I've updated the stabilization report as well as linked to your comment as a place for discussing it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've now made that PR ready & lang-nominated it, sorry for the delay. See the nomination text here: #146377 (comment) (it's maybe a bit rambly since I threw it together rather quickly, I hope it's comprehensible enough).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks! |
||
| gate_all!(where_clause_attrs, "attributes in `where` clause are unstable"); | ||
| gate_all!(super_let, "`super let` is experimental"); | ||
| gate_all!(frontmatter, "frontmatters are experimental"); | ||
| gate_all!(coroutines, "coroutine syntax is experimental"); | ||
|
|
||
| if !visitor.features.never_patterns() { | ||
|
|
||
jieyouxu marked this conversation as resolved.
Show resolved
Hide resolved
|
This file was deleted.
This file was deleted.
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,6 +5,4 @@ x ---🚧️ | |
| // Regression test for #141483 | ||
| //@check-pass | ||
|
|
||
| #![feature(frontmatter)] | ||
|
|
||
| fn main() {} | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,6 +6,4 @@ x ---y | |
| // non-whitespace character preceding them. | ||
| //@check-pass | ||
|
|
||
| #![feature(frontmatter)] | ||
|
|
||
| fn main() {} | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,13 @@ | ||
| ---cargo | ||
| //~^ ERROR: unclosed frontmatter | ||
|
|
||
| //@ compile-flags: --crate-type lib | ||
|
|
||
| #![feature(frontmatter)] | ||
|
|
||
| fn foo(x: i32) -> i32 { | ||
| ---x | ||
| //~^ WARNING: use of a double negation [double_negations] | ||
| //~^ ERROR invalid preceding whitespace for frontmatter close | ||
| //~^^ ERROR extra characters after frontmatter close are not allowed | ||
| } | ||
| //~^ ERROR unexpected closing delimiter: `}` | ||
|
|
||
| // this test is for the weird case that valid Rust code can have three dashes | ||
| // within them and get treated as a frontmatter close. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,30 +1,26 @@ | ||
| error: unclosed frontmatter | ||
| --> $DIR/fence-indented-mismatch.rs:1:1 | ||
| error: invalid preceding whitespace for frontmatter close | ||
| --> $DIR/fence-indented-mismatch.rs:6:1 | ||
| | | ||
| LL | / ---cargo | ||
| ... | | ||
| LL | | | ||
| | |_^ | ||
| LL | ---x | ||
| | ^^^^^^^^ | ||
| | | ||
| note: frontmatter opening here was not closed | ||
| --> $DIR/fence-indented-mismatch.rs:1:1 | ||
| note: frontmatter close should not be preceded by whitespace | ||
| --> $DIR/fence-indented-mismatch.rs:6:1 | ||
| | | ||
| LL | ---cargo | ||
| | ^^^ | ||
| LL | ---x | ||
| | ^^^^ | ||
|
|
||
| warning: use of a double negation | ||
| --> $DIR/fence-indented-mismatch.rs:9:6 | ||
| error: extra characters after frontmatter close are not allowed | ||
| --> $DIR/fence-indented-mismatch.rs:6:1 | ||
| | | ||
| LL | ---x | ||
| | ^^^ | ||
| | | ||
| = note: the prefix `--` could be misinterpreted as a decrement operator which exists in other languages | ||
| = note: use `-= 1` if you meant to decrement the value | ||
| = note: `#[warn(double_negations)]` on by default | ||
| help: add parentheses for clarity | ||
| | ^^^^^^^^ | ||
|
|
||
| error: unexpected closing delimiter: `}` | ||
| --> $DIR/fence-indented-mismatch.rs:9:1 | ||
| | | ||
| LL | --(-x) | ||
| | + + | ||
| LL | } | ||
| | ^ unexpected closing delimiter | ||
|
|
||
| error: aborting due to 1 previous error; 1 warning emitted | ||
| error: aborting due to 3 previous errors | ||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,15 +1,12 @@ | ||
| ----cargo | ||
| //~^ ERROR: unclosed frontmatter | ||
| //~| ERROR: frontmatters are experimental | ||
|
|
||
| //@ compile-flags: --crate-type lib | ||
|
|
||
| // Leading whitespace on the feature line prevents recovery. However | ||
| // the dashes quoted will not be used for recovery and the entire file | ||
| // should be treated as within the frontmatter block. | ||
|
|
||
| #![feature(frontmatter)] | ||
|
|
||
| fn foo() -> &str { | ||
| "----" | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we in a similar situation with shebangs?
The RFC originally framed frontmatters as being stripped like shebangs. I'm assuming that it is an implementation detail that this is currently being handled inside the lexer rather than as a strip before hand.
Is there a reason you put this under the same concern as being CFG? On the surface, they seem independent which could make talking about them harder and risks losing track of one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I'm making a mistake here, but the shebang has a natural and deterministic delimiter, doesn't it?
'\n'There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, it isn't the ambiguity that is a concern for context free but the capping on the delimiters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly, that's why we have the limit of
u8::MAXon the effective delimitation for raw strings. The same rule could be applied here.