Error when dumping the AST for hundreds of files

Ok, the tests are done. I added a few invocations to Driver/driver-compile.swift like you suggested, and I thought it best to also add a new invocation to Driver/actions.swift.

You also said to test the frontend similarly to Frontend/batch-mode.swift, so I added a new file called Frontend/ast-dump.swift that did something similar. To be honest, maybe the new file tests a bit more than it should for a frontend test, but I can always move some tests or delete them if need be.

I'm still not sure I understand everything about the test system, so feel free to point out any corrections. For instance, do I need to add the new file to a list of files somewhere?

I should also say that a few of the existing tests in driver_compile.swift are failing in my computer, but they were also failing on my build from the master branch, so it doesn't seem to be something I did...

Anyway, the PR is updated if you want to take a look. I'm trying to get it done in time for the last Swift 5 merge on the 16th, so this will be my priority for the next few days :)

Thanks for resolving that problem! Faced with this too a month ago trying to write “plugin” for static validation. I looked in PR comments and saw that you want to fix WMO later. Please, make it work with WMO too, so I could write my tool based on it :)
Will incremental builds will work with ast-dump and many-filed output?

1 Like

I'll do my best!

I'm not sure how incremental builds work, it might be interesting to go after it if the ast-dumps start taking too long... but it does work with many output files using -output-file-map like Jordan said.

Ok, the changes to the tests are up. Here's hoping they're the last ones!

Ok, I fixed the test errors that showed up on the CI, as well as couple of others that were failing locally.

It's worth noting that some of the failed tests in the CI were failing because they don't seem to have any primary files. I'm assuming this only happens because they call -frontend directly, and that it wouldn't happen in normal situations. In any case, I added a fallback to the old behavior if no primary files are found. That should take care of both the tests and some other edge cases I maybe haven't thought about.

There are still two tests that fail locally for me. SILOptimizer/globalopt.sil fails with:

Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /Users/vini/Development/swift/swiftFork/llvm/include/llvm/Support/Casting.h, line 241.

and Reflection/typeref_lowering.swift fails with:

.../test/Reflection/typeref_lowering.swift:1059:19: error: CHECK-64-NEXT: expected string not found in input
// CHECK-64-NEXT: (multi_payload_enum size=9 alignment=8 stride=16 num_extra_inhabitants=253 bitwise_takable=1
                  ^
<stdin>:519:2: note: scanning from here
 (multi_payload_enum size=9 alignment=8 stride=16 num_extra_inhabitants=0 bitwise_takable=1
 ^
<stdin>:545:2: note: possible intended match here
 (multi_payload_enum size=9 alignment=8 stride=16 num_extra_inhabitants=254 bitwise_takable=0
 ^

I would have fixed the tests if I could but I really have no idea what they're supposed to do, so I'm hoping this is just my thing and that it won't trigger any errors in the CI.

:+1: I'm going to assume / hope those are failures unrelated to your change.

By the way, it's a little easier to not have discussions going on here and on GitHub. Usually once there's a PR we keep implementation discussions there because we have the code to comment on.

1 Like