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

Bump allocated RawSyntax #544

Merged
merged 14 commits into from
Aug 9, 2022
Merged

Bump allocated RawSyntax #544

merged 14 commits into from
Aug 9, 2022

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Aug 2, 2022

  • Introduce SyntaxArena that manages the memory of RawSyntax
  • RawSyntaxData is the "data" of raw syntax managed by SyntaxArena, and it has
    • Unowned pointer to the SyntaxArena
    • Tagged union of "token" or "layout" data where all data are managed by the SyntaxArena
  • RawSyntax is now just a pointer wrapper of RawSyntaxData and APIs.
  • Root SyntaxData now owns the SyntaxArena of the root RawSyntax.

For intermediate solution SyntaxArena has static var default which is used by Factory methods. This cannot be a permanent solution because it's never deallocate the memory. In future all factory methods will require explicit arena to use.

@rintaro rintaro requested a review from ahoppen as a code owner August 2, 2022 23:03
@rintaro rintaro changed the title Bump allocated RawSyntax [WIP]Bump allocated RawSyntax Aug 2, 2022
switch kind {
case 0:
return false
return .spaces(text.count / 1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not emit a division when the base is 1 like this?

@@ -0,0 +1,113 @@
//===------------------ RawSyntax.swift - Raw Syntax nodes ----------------===//
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Header should reflect the file name.

* Introduce 'SyntaxArena' that manages the memory of RawSyntax
* 'RawSyntax' now has
  - Unowned pointer to the 'SyntaxArena'
  - Tagged union of "token" or "layout" where all data are managed by
    the 'SyntaxArena'
* Root 'SyntaxData' now 'SyntaxArena' of the root 'RawSyntax'
@rintaro rintaro force-pushed the rewrite-rawsyntax branch 3 times, most recently from 219743b to 6511704 Compare August 5, 2022 22:13
Copy link
Member

@CodaFi CodaFi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You love to see it.

@rintaro rintaro force-pushed the rewrite-rawsyntax branch 2 times, most recently from 1c41cae to c08a749 Compare August 5, 2022 22:44
@rintaro
Copy link
Member Author

rintaro commented Aug 5, 2022

@swift-ci Please test

@rintaro
Copy link
Member Author

rintaro commented Aug 6, 2022

The test error is:

/home/build-user/swift-syntax/lit_tests/coloring.swift:235:12: error: CHECK: expected string not found in input
 // CHECK: <str>"</str>\<anchor>(</anchor><int>1</int><anchor>)</anchor><str></str>\<anchor>(</anchor><int>1</int><anchor>)</anchor><str>"</str>
           ^
<stdin>:148:11: note: scanning from here
 """</str>
          ^
<stdin>:150:2: note: possible intended match here
 <str>"</str>\<anchor>(</anchor><int>1</int><anchor>)</anchor>\<anchor>(</anchor><int>1</int><anchor>)</anchor><str>"</str>
 ^

The difference is <str></str> missing in the actual result, but I feel the new behavior is preferable. What do you think @ahoppen ?

NOTE: This happens because I removed the stored "source presence" flag from RawSyntax, and tokens with empty string is now considered .missing. So the classifier skips the empty token.

@rintaro
Copy link
Member Author

rintaro commented Aug 6, 2022

@swift-ci Please test

@rintaro
Copy link
Member Author

rintaro commented Aug 6, 2022

@swift-ci Please test

Copy link
Collaborator

@ahoppen ahoppen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, looks really good to me. I’ve got a few comments, mostly regarding doc comments, inline. Some general comments:

  • I’m not sure we should use RawTriviaPiece.make instead of an initializer. But we can discuss this as a follow-up.
  • Looking through this, I’m not sure if you’re always consistent whether SyntaxArena is the first or last parameter. I think we should be consistent in this.
  • Should the preconditions be assertions instead that are disabled in Release builds?
  • Would it make sense to group methods on RawSyntax into three different categories (which are different extensions, separated by a // MARK: - ):
    • Methods that work on all RawSyntax nodes
    • Methods that fail a precondition when invoked on tokens
    • Methods that fail a precondition when invoked on layouts

And if you make any changes to this PR, could you make them in separate commits. That would make reviewing of these changes a lot easier because I don’t have to look through all the other changes again. And then you can squash once we agree this PR is good to merge.

Sources/SwiftSyntaxParser/SyntaxParser.swift Show resolved Hide resolved
Sources/SwiftSyntax/Trivia.swift.gyb Show resolved Hide resolved
Sources/SwiftSyntax/TokenKind.swift.gyb Show resolved Hide resolved
Sources/SwiftSyntax/TokenKind.swift.gyb Show resolved Hide resolved
Sources/SwiftSyntax/SyntaxData.swift Show resolved Hide resolved
Sources/SwiftSyntax/RawSyntax.swift Outdated Show resolved Hide resolved
Sources/SwiftSyntax/RawSyntax.swift Outdated Show resolved Hide resolved
Sources/SwiftSyntax/RawSyntax.swift Outdated Show resolved Hide resolved
// Allocate and initialize the list.
let layoutBuffer = arena.allocateRawSyntaxBuffer(count: count)
initializer(layoutBuffer)
// validateLayout(layout: RawSyntaxBuffer(layoutBuffer), as: kind)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you intend to add the validation again or are we dropping it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding. To be precise, I'm moving the validation from Syntax to RawSyntax.
https://github.com/rintaro/swift-syntax/blob/bump-ptr-allocation-and-everything/Sources/SwiftSyntax/gyb_generated/SyntaxValidation.swift
And do it whenever it's created.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I’m fine with adding validation again in a follow-up PR.

Sources/SwiftSyntax/Trivia.swift.gyb Outdated Show resolved Hide resolved
@rintaro
Copy link
Member Author

rintaro commented Aug 8, 2022

Looking through this, I’m not sure if you’re always consistent whether SyntaxArena is the first or last parameter. I think we should be consistent in this.

The current rule is:

  • Factories (e.g. makeXXX(), usually static method) receives the SyntaxArena first
  • Modifiers (e.g. withXXX(), appendingXXX(), instance methods) receives the SyntaxArena last

I think arena should be first in general, but modifiers receiving it first (e.g. replacingChild(arena: arena, at: index, with: newChild)) doesn't look natural.

@rintaro
Copy link
Member Author

rintaro commented Aug 8, 2022

Should the preconditions be assertions instead that are disabled in Release builds?

I only used precondition for some RawSyntax modifiers, and a couple of SyntaxArena methods where I think the performance penalty is acceptable, and it shouldn't really happen.
We could use assert for RawSyntax modifiers as it is not public, but I have a plan to expose it as a SPI, so I'd like to keep them precondition.

@rintaro
Copy link
Member Author

rintaro commented Aug 8, 2022

Would it make sense to group methods on RawSyntax into three different categories

Yes totally. I think we could even split them into separate files. But I just tried to keep the existing code/method order to keep this PR as small as possible.

@rintaro
Copy link
Member Author

rintaro commented Aug 8, 2022

apple/swift-stress-tester#183
@swift-ci Please test

1 similar comment
@rintaro
Copy link
Member Author

rintaro commented Aug 8, 2022

apple/swift-stress-tester#183
@swift-ci Please test

@rintaro
Copy link
Member Author

rintaro commented Aug 9, 2022

apple/swift-stress-tester#183
@swift-ci Please test

1 similar comment
@rintaro
Copy link
Member Author

rintaro commented Aug 9, 2022

apple/swift-stress-tester#183
@swift-ci Please test

@rintaro
Copy link
Member Author

rintaro commented Aug 9, 2022

apple/swift-stress-tester#183
@swift-ci Please test

@rintaro rintaro merged commit 342a9d2 into apple:main Aug 9, 2022
@rintaro rintaro changed the title [WIP]Bump allocated RawSyntax Bump allocated RawSyntax Aug 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants