profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/akyrtzi/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

llvm/llvm-project 8576

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Note: the repository does not accept github pull requests at this moment. Please submit your patches at http://reviews.llvm.org.

apple/swift-syntax 1568

SwiftPM package for SwiftSyntax library.

akyrtzi/cairo-gral 10

A hardware accelerated cairo backend. Leverages GPU hardware as much as possible and minimizes CPU usage.

nathawes/swift 1

The Swift Programming Language

akyrtzi/indexstore-db 0

Index database library for use with sourcekit-lsp

akyrtzi/sourcekit-lsp 0

Language Server Protocol implementation for Swift and C-based languages

akyrtzi/swift 0

The Swift Programming Language

akyrtzi/swift-cmark 0

CommonMark parsing and rendering library and program in C

push eventapple/swift-syntax

Kim de Vos

commit sha 9107c1992585c68439acac5650b9c50bc12e2f2e

Add Buildable gyb

view details

Alex Hoppen

commit sha 8319e756104c5c12575970de7383204a0faca3b0

Merge pull request #268 from kimdv/kimdv/add-buildable-gyb Add Buildable gyb

view details

push time in 30 minutes

PR merged apple/swift-syntax

Add Buildable gyb

From #263

2. Actually create the Buildable types

I think with that we’re already to the main part. Here is a random collection on thoughts, how I would approach it. Again a disclaimer: I haven’t tested any of this and it might be whofully wrong.

First off, I would try and get a raw API up and running. At this stage, I wouldn’t worry about a nice API or result builders yet, I would just want to get an initialiser-based API up and running with which all syntax nodes can be created.

  • As a baseline, I would start with SyntaxBuilders.swift and modify it according to our needs.
  • I wouldn’t be too focused on the current design of the buildables since we probably can’t automatically re-create a generic modelling like it’s currently done for variables here. I’m fine with any design that’s easy to use and we are not concerned about source breakage here.
  • As a first step, I would try modifying the SyntaxBuilders so they are purely initialiser based, that is all children are passed in the initialiser and we don’t need the use* methods anymore.

After this, I am expecting the API to be much worse than it is today, but it should be exhaustive now. This means, we now need to make it easy to use again. I’ve got a couple of (more or less) necessary improvements in my head already, I’m sure there are more once you get to it.

  • Of course the entire result builder thing. Any syntax collection should be buildable using a corresponding result builder.

  • Any non-optional token without custom text (i.e. a keyword or punctuator) ccan be implicitly synthesized and does not have a corresponding argument in the initialiser

    • Example: We don't need to specify the open { for a struct decl.
  • And as far as I can tell we’re now already at a stage, where custom specialisations are needed. These can be made in a separate file through extensions.

    • Example: According to the specification of a VariableDecl, it is (simplified) a var/let keyword with a following PatternBindingList. But that’s not how anybody thinks about a Var decl. We should create an initialiser that’s closer to what we have today, which correctly creates the pattern binding etc.
    • Example: According to the definition of a StructDecl, it takes its members as a MemberDeclBlock, consisting of a pair of braces and decls which might be followed by a semicolon. The braces can already be implicitly synthesized as described above and nobody cares about semicolons. So we should have a specialised initialiser taking a list of decls (through a result builder) that correctly creates the MemberDeclBlock etc.

I think the advantage of this approach (auto-generate a exhaustive, but verbose API and add convenience extensions on top) apposed to the previous approach (hand write everything), is that there is always a fall-back to create every syntax element, even cutting-edge ones. I expect the convenience initialisers to concern the most commonly used syntax elements, which should also be the most stable, so I expect they should be fairly easy to maintain.

What do you think @kimdv? Does this sound good to you?

Okay, now we are ready for the next step. 🚀 (I have modified this file, not sure if it is the right, but then we can start a conversation)

I'm a little confused on how I should approach this.

  • As a baseline, I would start with SyntaxBuilders.swift and modify it according to our needs.
  • I wouldn’t be too focused on the current design of the buildables since we probably can’t automatically re-create a generic modelling like it’s currently done for variables here. I’m fine with any design that’s easy to use and we are not concerned about source breakage here.
  • As a first step, I would try modifying the SyntaxBuilders so they are purely initialiser based, that is all children are passed in the initialiser and we don’t need the use* methods anymore.

So the idea is that inside etc StructDeclSyntaxBuilder should not have add* but all possibilities should be basses within the init method?

+8775 -500

11 comments

12 changed files

kimdv

pr closed time in 30 minutes

delete branch apple/swift-driver

delete branch : cherry-pick-433c66dbe644f5beb6adb9127eba7e838489a707

delete time in 4 hours

push eventapple/swift-driver

Artem Chikin

commit sha e2bbad1a911c905574ea5d1d196526d4199659f0

Remove target `x86_64` specialization from `testExplicitModuleBuildEndToEnd` (cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

view details

Mishal Shah

commit sha d72c0b85721cf74c101756c55edb128a13372d49

Merge pull request #612 from apple/cherry-pick-433c66dbe644f5beb6adb9127eba7e838489a707 [5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…

view details

push time in 4 hours

PR merged apple/swift-driver

[5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…

…dToEnd`

(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

+3 -3

1 comment

3 changed files

shahmishal

pr closed time in 4 hours

pull request commentapple/swift-driver

Verify module interfaces generated from emit-module jobs

@swift-ci test

xymus

comment created time in 9 hours

PR opened apple/swift-driver

Reviewers
Verify module interfaces generated from emit-module jobs

The verify job was previously only added after merge-module jobs which is more prone to generate broken swift interfaces.

+48 -3

0 comment

2 changed files

pr created time in 9 hours

push eventapple/swift-driver

Doug Gregor

commit sha c311fc17514e5695df40324eb032423e964fd461

Update options to match Swift main

view details

Doug Gregor

commit sha 76fe5e2127279dbc15a68d716efe4654234c9547

Merge pull request #613 from DougGregor/update-options Update options to match Swift main

view details

push time in 17 hours

PR opened apple/swift-driver

Reviewers
[5.4] [Build Script Helper] Do not pass `-Ddispatch_DIR` to the Yams CMake …

…build

[Change analagous to: https://github.com/apple/swift-package-manager/pull/3363] With the version-bump of Yams in apple/swift#36366, Yams 4.0.2 now actually expresses the dependency on Dispatch in its CMake config.

With the current behavior of passing -Ddispatch_DIR to its CMake build, we have the following problem on Linux:

  • swift's build-script installs Dispatch into a just-built toolchain which we use to build swift-driver, which will contain, among other things, the Dispatch .swiftmodule.
  • The compiler workspace checkout of swift-corelibs-libdispatch also contains a copy of the Dispatch .swiftmodule.

Both of these will be found, leading to build failures like:

/home/buildnode/jenkins/workspace/swift-PR-Linux/branch-main/swift-nightly-install/usr/lib/swift/dispatch/module.modulemap:1:8: error: redefinition of module 'Dispatch'
19:37:47 module Dispatch {
19:37:47        ^
19:37:47 /home/buildnode/jenkins/workspace/swift-PR-Linux/branch-main/swift-corelibs-libdispatch/dispatch/module.modulemap:1:8: note: previously defined here
19:37:47 module Dispatch {
19:37:47        ^
19:37:47

We also cannot put off building libDispatch until SwiftPM is built, because the libDispatch dylib is required to link SwiftPM. Not passing -Ddispatch_DIR to Yams' CMake build causes it to successfully locate the Dispatch package in the just-built toolchain on its own.

(cherry picked from commit a76b464108e70336e41632511ede3991f9d633e0)

+0 -3

0 comment

1 changed file

pr created time in 18 hours

pull request commentapple/swift-driver

Update options to match Swift main

@swift-ci please test

DougGregor

comment created time in 18 hours

pull request commentapple/swift-driver

Update options to match Swift main

@swift-ci please smoke test

DougGregor

comment created time in 18 hours

PR opened apple/swift-driver

Update options to match Swift main
+7 -2

0 comment

2 changed files

pr created time in 18 hours

PR opened apple/swift-driver

[5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…

…dToEnd`

(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

+3 -3

0 comment

3 changed files

pr created time in 18 hours

pull request commentapple/swift-syntax

Add Buildable gyb

Build failed Swift Test OS X Platform Git Sha - 396f756e90b27e8d75781abecb01635473ec69fa

kimdv

comment created time in a day

pull request commentapple/swift-syntax

Add Buildable gyb

Build failed Swift Test Linux Platform Git Sha - 396f756e90b27e8d75781abecb01635473ec69fa

kimdv

comment created time in a day

pull request commentapple/swift-syntax

Add Buildable gyb

apple/swift#36726

@swift-ci Please test

kimdv

comment created time in a day

pull request commentapple/swift-syntax

Add Buildable gyb

Yes! Let's get it merged and I will fix the 3 things you mentioned after.

I just rebased on main.

kimdv

comment created time in a day

pull request commentapple/swift-format

Add strict flag

Hey @allevato! I have rebased on top of main - which has made the diff between 5.3 branch and this PR quite larger. Should I keep pointing to swift-5.3-branch or change it to main?

I somewhat think that this feature would be served better by having it actually upgrade the severity of the diagnostics themselves to .error instead of .warning

I agree, let me know if you want help with the subsequent refactor. Promoting warnings to errors themselves would also enable me to write tests - I am not sure if it is possible at the moment to do so as the changes are limited to Lint command.

fortmarek

comment created time in a day

created tagapple/sourcekit-lsp

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

Language Server Protocol implementation for Swift and C-based languages

created time in a day

created tagapple/swift-driver

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

Swift compiler driver reimplementation in Swift

created time in a day

created tagapple/swift-syntax

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

SwiftPM package for SwiftSyntax library.

created time in a day

created tagapple/indexstore-db

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

Index database library for use with sourcekit-lsp

created time in a day

created tagapple/swift-stress-tester

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

Stress testing utilities for Swift's tooling

created time in a day

created tagapple/swift-cmark

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

CommonMark parsing and rendering library and program in C

created time in a day

created tagapple/swift-llbuild

tagswift-5.5-DEVELOPMENT-SNAPSHOT-2021-04-19-a

A low-level build system, used by Xcode and the Swift Package Manager

created time in a day

PR opened apple/swift-driver

Reviewers
test SymbolGraph/EmitWhileBuilding when a lit dir is available

As part of rdar://76815547, i want to make sure the symbol-graph's integration into the frontend is properly flexed with both the old driver and the new driver.

+4 -0

0 comment

1 changed file

pr created time in a day