Indented syntax improvements

[jamesnw]

No description provided.

[jamesnw]

@nex3 I'd appreciate a quick check that this approach is in the right direction. Essentially, I'm looking at every invocation of whitespace(), and determining whether a statement could end, in which case consumeNewlines should be false.

(For the WIP, I'm explicitly setting consumeNewlines: false in places I've covered, just to track progress, but those would be cleaned up.)

So far, this has covered most of my needs, with a few edge cases inside _expression.

I also want to check my assumption that the AST parsing classes should mirror these changes- for instance, should /lib/src/parse/media_query.dart mirror the changes in /lib/src/parse/stylesheet.dart:_mediaQuery?

There are also some parse*() functions in stylesheet.dart that seem to only be used by the AST, and mirror other functions- for instance parseArgumentDeclaration and _argumentDeclaration, or parseUseRule and _useRule. What are these used for, and (if the changes need to be applied there as well) how would I test them?

[nex3]

It's a little unfortunate that we'll have to remember to consider each call to whitespace() in the future to determine whether or not it needs this flag, but I don't see a clearly better way to handle this. If you want to require every call site to specify this explicitly, you can write:

Suggested change

	void whitespace({bool consumeNewlines = false}) {
	void whitespace({required bool consumeNewlines}) {

I also want to check my assumption that the AST parsing classes should mirror these changes- for instance, should /lib/src/parse/media_query.dart mirror the changes in /lib/src/parse/stylesheet.dart:_mediaQuery?

There are also some parse*() functions in stylesheet.dart that seem to only be used by the AST, and mirror other functions- for instance parseArgumentDeclaration and _argumentDeclaration, or parseUseRule and _useRule. What are these used for, and (if the changes need to be applied there as well) how would I test them?

The other parser classes are usually used to do secondary parses of interpolated constructs. Since they're not being parsed at the stylesheet level, whitespace should never be meaningful for them, so they should always allow newlines.

[jamesnw]

Thanks!

I was initially thinking of using whitespace(consumeNewlines: false) temporarily to track where I've checked, and then going back and removing the default value. But you're right that we want future changes to know they have to be intentional about this as well, and I'll make it required once I've made the initial pass.

[jamesnw]

@nex3 I'm close to wrapping up newline handling, but have a question.

In @supports and @import ... supports rules, I'm not sure what the correct output is. The proposed spec reads "In the indented syntax, LineBreak is not whitespace in the ImportAtRule, SupportsAtRule or MediaAtRule, except inside of parentheses or square brackets as defined by CSS syntax."

In the SCSS format, I'm seeing some curious whitespace handling that wouldn't conform to the above- here are some examples, with the failing versions commented out.

Should I match existing SCSS behavior, or does the SCSS behavior need to be fixed here?

[nex3]

Yes, it's an SCSS bug that no whitespace is allowed after the ( in that case.

[jamesnw]

Moved to sass#2467