It seems iPad Playgrounds somehow has a different compiler than everywhere else. For example the following code in the current iPad Playgrounds 4.5.1 which uses Swift 5.10 causes a mysterious floating error…
enum EZIO20 {
static func foo<T>(x: T) {}
enum Nested {
func bar() {}
}
}
// error: Cannot find type 'T' in scope
// appears different places depending on surrounding code
It was driving me batty and I thought I found a bug in Swift but trying that code in the online Compiler Explorer using Swift 3.1.1, 5.10, and nightly, they all compiled fine.
So it appears the iPad Playgrounds compiler is bugged but I’m wondering how this is even possible? I thought the compiler is the compiler, so If you have the 5.10 compiler here or there it should be the same no? This bug makes it seem as though iPad Playgrounds somehow has a different/modified version of Swift 5.10. Or is something else going on, like iPad Playgrounds is post-processing the compilers result and inserting its own error for some reason? Idk
Another iPad Playgrounds bug is it won’t compile this valid code
var `default`: Int { 0 }
I feel I’ve run into a couple other ways that iPad Playgrounds erroneously errors but can’t specifically remember them. Anyways I just don’t get how it’s different if it has THE Swift 5.10 compiler. Or maybe it doesn’t. Do people mess with the compiler? How/why is my Swift different than yours? Maybe if I understood this I could predict or figure out quicker that the error isn’t me.
(aside: I can workaround the first bug by moving either the generic function or the nested type to an extension)
I'd be more interested if the flags the application uses would cause crashes in some more parsing or type sensitive scenarios, like your examples static+generics constraints and backticked tokens when using reserved keywords.
I was bored, so that leads to rabbit holes and me downloading Playgrounds on macOS. I used Console to see what would be spit out for a failed compilation and we do get a Compilation failed for <private> message. This came from the SwiftCompilerExtension category, and there is indeed Playground.app/Contents/PlugIns/CompilerExtension.appex. Using strings, I found:
Compiling with frontend arguments: %{private}@
Compilation complete.
Compiling with driver arguments: %{private}@
We don't know if these 100% mean compiler arguments but we can strongly imply that. The subsystem for the Console message was com.apple.PlaygroundBuild, which refers to the PlaygroundBuild.framework, where the relevant binary is PlaygroundBuild.framework/Versions/A/PlaygroundBuild. Using strings again I see some familiar flags:
Where some indeed are compiler flags, but probably not all of them in the binary. Notice that this is where the string to enable bare regexes is written. Now, I'm not a compiler expert to really know what all of the flags do or how some would work together to cause issues like you have observed in your examples. Although, a very easy one is setting a very low value for -solver-memory-threshold.
However the idea/fact that the app is passing in flags makes sense given it targets iPadOS as an application and works within a more memory constrained environment. There are probably also tradeoffs by providing a beginner friendly "fast/instant" UX. I believe the official Apple solution to the compilation issues would be: "buy a Mac".
During my rabbit hole I even went as far as trying to decompile the plugins and framework which did get me something to think about, but was just for fun.