I've submitted a few small merge requests to the swift-driver, based on the development plan in the README, but now I find I'd like to tackle something a bit bigger. However I'm unable to proceed on my own, so I thought I'd ask here:
One of the tasks outlined is the following:
Find a better way than makeOptions.cpp to translate the command-line options from Swift's repository into Options.swift .
What would "a better way" look like? I see two disadvantages of the current system:
updating Options.swift requires one to build the Swift compiler
makeOptions.cpp is written in C++
Is it possible/feasible/desirable to somehow eliminate the need to build the compiler? If so, where would one start?
Would anything be gained by just rewriting makeOptions into Swift?
Are there other things that could be done that I'm overlooking?
In my opinion this is the biggest downside to the current setup, and the one most likely to cause bootstrapping problems in the future.
I can think of two possible solutions, although someone else might have better ideas.
The first would be to write a new TableGen backend to generate the Swift options definitions directly from Options.td instead of the generated Options.inc. This would allow generating the Swift definitions without needing to build the compiler, but it would still require building most of LLVM + a custom TableGen binary. This would be a lot of work to setup for not much benefit in my opinion.
The other option, which I think is better, would be to define the options in Python instead of TableGen. Then, we could use gyb to generate both Options.inc for the frontend and Options.swift for the driver. This would completely eliminate the need to build LLVM or the compiler frontend to update the driver options. From an implementation perspective, I think it would also be easier to integrate with build-script.
Interesting! This would be a pull request against the main Swift repository, correct? Are there tests verifying the contents of Options.inc? If not, how would we verify that the Python version is working correctly?
Eventually, yes. I haven't thought about this too much, but it might be possible to do in two stages:
Modify makeOptions.cpp to generate Python defs instead of Swift ones, and generate the swift ones from python using gyb. No changes would be required in the frontend yet.
Once the above is working well, copy the generated Python definitions into the frontend, replacing Options.td as the source of truth and using gyb to generate Options.inc
If you search for Options.inc in the frontend, you'll see it's #included directly in a number of places and used by a bunch of macros to generate option handling code. If the changes introduced an issue, I'd expect either the frontend would fail to compile, or a very large part of the test suite would begin failing.