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?

…dToEnd`

(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

@swift-ci test

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

…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)

@swift-ci please test

@swift-ci please smoke test

@swift-ci test

…dToEnd`

(cherry picked from commit 433c66dbe644f5beb6adb9127eba7e838489a707)

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

Build failed Swift Test Linux Platform Git Sha - 396f756e90b27e8d75781abecb01635473ec69fa

apple/swift#36726

@swift-ci Please test

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

I just rebased on main.

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.

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.