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.
A hardware accelerated cairo backend. Leverages GPU hardware as much as possible and minimizes CPU usage.
The Swift Programming Language
Index database library for use with sourcekit-lsp
Language Server Protocol implementation for Swift and C-based languages
The Swift Programming Language
CommonMark parsing and rendering library and program in C
push eventapple/swift-syntax
commit sha 9107c1992585c68439acac5650b9c50bc12e2f2e
Add Buildable gyb
commit sha 8319e756104c5c12575970de7383204a0faca3b0
Merge pull request #268 from kimdv/kimdv/add-buildable-gyb Add Buildable gyb
push time in 30 minutes
PR merged apple/swift-syntax
From #263
2. Actually create the
Buildable
typesI 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 theuse*
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 astruct
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 followingPatternBindingList
. But that’s not how anybody thinks about aVar
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 theuse*
methods anymore.
So the idea is that inside etc StructDeclSyntaxBuilder should not have add*
but all possibilities should be basses within the init
method?
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
commit sha e2bbad1a911c905574ea5d1d196526d4199659f0
Remove target `x86_64` specialization from `testExplicitModuleBuildEndToEnd` (cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)
commit sha d72c0b85721cf74c101756c55edb128a13372d49
Merge pull request #612 from apple/cherry-pick-433c66dbe644f5beb6adb9127eba7e838489a707 [5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…
push time in 4 hours
PR merged apple/swift-driver
…dToEnd`
(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)
pr closed time in 4 hours
pull request commentapple/swift-driver
Verify module interfaces generated from emit-module jobs
@swift-ci test
comment created time in 9 hours
PR opened apple/swift-driver
The verify job was previously only added after merge-module jobs which is more prone to generate broken swift interfaces.
pr created time in 9 hours
push eventapple/swift-driver
commit sha c311fc17514e5695df40324eb032423e964fd461
Update options to match Swift main
commit sha 76fe5e2127279dbc15a68d716efe4654234c9547
Merge pull request #613 from DougGregor/update-options Update options to match Swift main
push time in 17 hours
PR opened apple/swift-driver
…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)
pr created time in 18 hours
create barnchapple/swift-driver
branch : cherry-pick-a76b464108e70336e41632511ede3991f9d633e0
created branch time in 18 hours
pull request commentapple/swift-driver
Update options to match Swift main
@swift-ci please test
comment created time in 18 hours
pull request commentapple/swift-driver
Update options to match Swift main
@swift-ci please smoke test
comment created time in 18 hours
pull request commentapple/swift-driver
[5.5] Remove target `x86_64` specialization from `testExplicitModuleBuildEn…
@swift-ci test
comment created time in 18 hours
PR opened apple/swift-driver
…dToEnd`
(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)
pr created time in 18 hours
create barnchapple/swift-driver
branch : cherry-pick-433c66dbe644f5beb6adb9127eba7e838489a707
created branch time in 18 hours
pull request commentapple/swift-syntax
Build failed Swift Test OS X Platform Git Sha - 396f756e90b27e8d75781abecb01635473ec69fa
comment created time in a day
pull request commentapple/swift-syntax
Build failed Swift Test Linux Platform Git Sha - 396f756e90b27e8d75781abecb01635473ec69fa
comment created time in a day
pull request commentapple/swift-syntax
apple/swift#36726
@swift-ci Please test
comment created time in a day
pull request commentapple/swift-syntax
Yes! Let's get it merged and I will fix the 3 things you mentioned after.
I just rebased on main
.
comment created time in a day
pull request commentapple/swift-format
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.
comment created time in a day
created tagapple/sourcekit-lsp
Language Server Protocol implementation for Swift and C-based languages
created time in a day
created tagapple/indexstore-db
Index database library for use with sourcekit-lsp
created time in a day
created tagapple/swift-stress-tester
Stress testing utilities for Swift's tooling
created time in a day
created tagapple/swift-cmark
CommonMark parsing and rendering library and program in C
created time in a day
created tagapple/swift-llbuild
A low-level build system, used by Xcode and the Swift Package Manager
created time in a day
PR opened apple/swift-driver
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.
pr created time in a day