Hi!
I'm trying to start in a mock implementation where at least the type is added after throws (see typed throws pitch for more info) is detected and valid, added to the mangler, AST, and so on. Like it was recently done with async . But I'm totally stuck on compile Swift, I was able to in the past but things has changed a lot.
I'm following the instructions of the apple/swift repository and after all the checkout time I just utils/build-script --release-debuginfo which takes a lot of time, but it gets to a point where it fails out with a <unknown>:0: error: no such module 'SwiftOnoneSupport' .
I'm on latest Big Sur beta and using Xcode 12.0 beta 5.
Could you post more information from the log? Or post the full log into a GitHub gist and share a link to that? I suspect that the failure happened much earlier, but it is leading to several issues down the line, one of which is the missing SwiftOnoneSupport modules.
It may be worth trying with Xcode 12 beta 3 - that's the version currently recommended by the README, and I ran into some issues with beta 5 as well, though they were related to arm64e and I didn't investigate much.
I got it finally compiling, and I'm making changes to the swift AST, so it is the swift-frontend target. How does the testing works through Xcode? The documentation talks about a check-swift target, but there is at least 20 targets that start with that and none of them seems to have tests on it, any ideas?
I don't think any of the targets have the ability to run tests (you still need to use swift/utils/run-test or llvm-project/llvm/utils/lit/lit.py to run them), they build things which are used by the tests.
# What I typically use:
llvm-project/llvm/utils/lit/lit.py -s -vv \
build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/test-macosx-x86_64 \
--filter="mytestname" # remove filter to exercise all tests
I haven't used run-test personally...
@owenv what is your workflow here for building and running tests? Can you suggest what @minuscorp should do?
I think @Jumhyn's suggestion is probably your best option, but in case any of it's helpful:
I usually have 2 builds on my machine, one Ninja release w/ asserts build for running tests and most day-to-day development, and one Xcode debug build that's mostly just for code completion and graphical LLDB debugging. While it is possible to run the test suite with an Xcode build, personally I've found the Ninja build is significantly more reliable (and it's easier to get help if you run into issues because it's used more often)
My Ninja build:
To build: ./utils/build-script --release --skip-build-benchmarks
To run tests: /path/to/swift-source/llvm/utils/lit/lit.py -sv path/to/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/test-macosx-x86_64/
My Xcode build: ./utils/build-script --xcode --debug --skip-build-benchmarks
And then I use the swift-frontend scheme for debugging
Yeah, seconded. The Xcode test targets have always had a bunch of unrelated failures for me that I have to sift through to find any 'real' failures. Ninja is definitely the better choice for test runs.
I agree Ninja builds are more stable and reliable. I’ve also switched over to VSCode for editing (and command-line for LLDB debugging - there’s probably a VSCode plugin for it...). I guess the IDE experience isn’t exactly the same as Xcode but with a few plugins (like Intellisense C/C++) you can make things like code completion and etc a lot better and now I no longer miss using Xcode.
That's interesting @suyashsrijan
Just for curiosity, did you try other things besides VSCode? Also, It took much time to adapt? I often think in try not use Xcode but I always feel like I'll miss things like code completion, lldb will become harder to use, ... and it will unproductive at least in the beginning.
But anyways, I'm just curious to know from people who switched or actually not use Xcode, to see pros and cons and maybe other options of editors, seen some people using different stuff.
I'm uncertain about how to use Xcode to debug for example the swift-frontend. There's no documentation in the Swift repository. And we're talking about new additions the language, so I don't know if I have to rebuild the whole xcode project to let swiftc be able to compile or not
Once you've run build-script with --xcode and opened the generated project, you should be able to use Xcode's built-in functionality to build, run, and debug your code. With the swift-frontend scheme selected, selecting "Edit Scheme..." will let you specify command line arguments (e.g., -typecheck /path/to/file.swift), or you can use the "Debug > Attach to Process by PID or Name" menu option to specify swift-frontend and then invoke the process from your command line. Breakpoints that you set in the Xcode GUI should work as expected.
No, I use VSCode as my primary editor for anything non-Swift/iOS related work. I've always had problems with Xcode and having to do a clean build or even setting up my local checkout of the repo from scratch. So, I decided to switch to ninja builds as I've found them more reliable in the past. The downside was losing Xcode so I decided to give VSCode a try. There are still some things that aren't great (like right-click + find declaration can take a few seconds longer vs. in Xcode) but overall I am happy with my setup and I think I can improve it further with a few more plugins (like Native Debug for LLDB debugging). It didn't take me very long to adjust to the new setup - I was certainly tempted to switch back to Xcode (and continue to deal with the issues), but after a few days I adjusted completely.
You've already gotten a short answer but... we have some resources under docs/DebuggingTheCompiler.md, and docs/ExternalResources.md. Out of the external resources, you might especially want to check out the talk "Becoming an Effective Contributor to Swift".