Compiler Bug Example Project #40
Description
What version of the compiler were we using? I think I need a 6.2 build again, maybe that is still available.
I think we just tried to build one of our example projects.
Strip it down.
Submit bug on Forums
If no response escalate to GitHub Project/ Issue
Notes from me:
FYI I have a strange compile time error with the new S4A IDE Pro app (6.1.4 I believe) . It still compiles fine with the older "Swift For Arduino" IDE that was version 6.0.
10:39
When building my "CoreAVR" project that is a package I get this:
/usr/bin/swift package update
Everything is already up-to-date
All package dependencies built.
error tracking out of directory file: The file "main.swift" couldn't be opened because there is no such file.
package or module is up to date
bitcode is up to date
/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/MacOS/avr-ar rcs -o libCoreAVR.a /Users/paul/Git/CoreAVR/build/CoreAVR.o
Built static library
Exported module
Built successfully
I think this one is working fine but the new (or just highlighted error message of not finding the main.swift file.
10:42
When I try to build the project that uses this file I get this:
/usr/bin/swift package update
Updating https://github.com/microswift-packages/libc
Updated https://github.com/microswift-packages/libc (0.42s)
Computing version for https://github.com/microswift-packages/libc
Computed https://github.com/microswift-packages/libc at 1.0.0 (0.47s)
Everything is already up-to-date
CoreAVR
building: CoreAVR
package or module is up to date
bitcode is up to date
/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/MacOS/avr-ar rcs -o libCoreAVR.a /Users/paul/Git/CoreAVR/build/CoreAVR.o
Built static library
built: CoreAVR
libc
/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/MacOS/gmake -f microswift/Makefile
Nothing to be done, libc does not require building.
All package dependencies built.
bitcode is up to date
Linking final ELF executable...
/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/MacOS/avr-objcopy -O binary --only-section=.swift1_autolink_entries /Users/paul/Git/FortyEight/build/main.o build/autolink.txt
/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/MacOS/ld.lld -L/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/lib/avr-libc/lib/avr5 -L/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/lib/avr-libgcc/avr5 -L/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/lib/avr-binutils/avr/lib/ldscripts -Tdata 0x800100 -Tavr5.xn --gc-sections /Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/lib/avr-libc/lib/avr5/crtatmega328p.o -lCAVR -o build/main.elf /Users/paul/Git/FortyEight/build/main.o -lSwift -L/Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/uSwift-AVR/Embedded/avr5 /Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/uSwift-AVR/Embedded/avr5/runtime_math_stubs.o /Applications/S4A IDE Pro.app/Contents/XPCServices/BuildEngine.xpc/Contents/Resources/uSwift-AVR/Embedded/avr5/missing_runtime_stub.clang.o -lCoreAVR -L /Users/paul/Library/Application Support/SwiftForArduino/Extensions/Modules/Embedded -L /Users/paul/Library/Application Support/SwiftForArduino/S4A/422/Modules/Embedded -L /Users/paul/Git/CoreAVR -L /Users/paul/Git/FortyEight/.build/checkouts/libc --start-group -lgcc -lm -lc -latmega328p --end-group
ld.lld: error: undefined hidden symbol: $s4main13ControlPacketV6action17memoryMapSelector15registerAddress23numberOfRegistersToReadA2C6ActionO_AC06MemoryfG0Os6UInt16VSitcfCTf4ndnnd_n
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced 6 more times
ld.lld: error: undefined hidden symbol: $s4main13ControlResultV6bufferACSrys5UInt8VGSg_tcfCTf4nd_n
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced 6 more times
ld.lld: error: undefined protected symbol: $s4main13ControlResultV6ActionO11descriptions12StaticStringVvg
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:(main)
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:($s4main9configureyyF)
referenced by main.bc
/Users/paul/Git/FortyEight/build/main.o:($s4main9configureyyF)
referenced 3 more times
LINKING FAILED
Errors occurred during build
This project still builds with the older version 6.0 so there is no rush. I also have not looked into this much so it might be something silly on my end. I figured I would just give you a heads up and not sit on the information if you are working to get out a new version.
Response from Carl:
The first bug is fixed (I think), the second one will be harder but I've fixed it before I'm pretty sure, I just need to root around in my old commits/branches. The problem is, I want to give both of these bugfixes to Kuba to upstream into the main swift repository, this is where I need your help. No one is going to accept these without unit tests! We need to somehow get the cases Brent has created so far and reduce them right down to a reproducible short bit of swift that crashes the compiler. This doesn't involve any actual compiler hacking, it's just ... take the program that produces the compiler crash and hack away bit again and again, until you've got a bare minimum. If you can get it down to just one file of Swift code then I can take it from there, but as a project with ten or more Swift files depending on each other, the won't accept that unit test for upstreaming! What do you think? Can you guys help me? Can I give that to Brent as a mini side project? He can then say he worked on an actual compiler fix for the Swift compiler! (note: working like this on llvm was how I got started as a compiler developer!)
Once you have a minimum test case I'll give it a quick view to tell you if Apple will like it or not, then write a quick forum post saying something like "we have a compiler that's basically like mainstream with a couple of patches for ourselves that make no real difference but with this important PR: and we are seeing this crash with this test case...
You will probably get a reply from someone and it will probably be positive/helpful not a "you're holding it wrong". The also all know me so they'll give you more respect, so long as you mention you're the maintainers who took over Swift for Arduino, they all know it here. If they didn't before, they do now.
And if you don't get useful engagement, raise an Issue on Github and tag the post with the issue, then you'll get noticed, because (Fun Fact), github issues raised automatically cause a matching Radar to be raised! You've probably heard of Radar, it's basically Apple's internal tool that's like JIRA. (p.s. don't mention that fact to anyone, I might get in trouble)
If/when I fix the compiler bugs that [@paul] is working with Brent to get a reproduction/test for, I'll include an up to date 6.3 so we get these. Might need a standard library bump. I haven't checked. But that's easy.