-
Notifications
You must be signed in to change notification settings - Fork 357
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
[Indented syntax improvements] Dart implementation #2467
base: main
Are you sure you want to change the base?
Conversation
…d-syntax-improvements
…d-syntax-improvements
…d-syntax-improvements
…d-syntax-improvements
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.
@nex3 This is ready for review. Here are some questions I wanted to flag as you review. Thanks!
allowNewlines
is set totrue
in some cases, like in parser* functions or inscss.dart
, where the value is non-impactful. Should this usage be differentiated somehow for clarity?
For classes where it's universally non-impactful, I'd define a local _whitespace()
function that takes no arguments with a comment explaining that the value isn't relevant.
- There are some places, like in
_atRootQuery
, whereallowNewlines
is true because it is inside parentheses. I opted to not use the_inParentheses
variable except for one place where the consumption did rely on it, in_supportsCondition
. Would it be more idiomatic to use_inParentheses
, even if the consumption is in the same function?
I think how it is now is better.
- In the
+
include syntax, I am not supporting whitespace after the+
as it can be part of a selector. This differs from the=
mixin syntax- should they be the same?
There's already an odd inconsistency here where whitespace is allowed after =
but not after +
, so I think it's fine to expand that to allowing newlines as well. It's possible that we should deprecate that, but it's not in-scope for this change.
- I added paren/bracket context to
almostAnyValue
, with the only change being that they must be matched. That means the error fora:has(d[)]
will be changed from "Expected identifer" to "Expected]
". SincealmostAnyValue
is used for more than selectors, should I make this functionality opt-in, dependent on a parameter? Based on the places where this is used, I don't foresee issues with bracket matching, but want to verify.
It's fine to change this error. Arguably the bracket error is clearer anyway.
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.
@nex3 This is ready for another round of review, along with the spec draft 1.2. Thanks!
lib/src/parse/stylesheet.dart
Outdated
@@ -1064,7 +1074,7 @@ abstract class StylesheetParser extends Parser { | |||
ImportRule _importRule(LineScannerState start) { | |||
var imports = <Import>[]; | |||
do { | |||
whitespace(); | |||
whitespace(allowNewlines: false); |
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.
Can you explain more what needs to be changed? As far as I can tell, allowNewlines is false throughout the import rule.
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.
@nex3 Changes made. I also have an outstanding question here- https://github.com/sass/dart-sass/pull/2467/files/38e05bf45a34f175921f5be1d8efbf4ab2c54a9a#r1896194128
Blocked until proposal is accepted.
[skip sass-embedded]