Attempting to compile SwiftFoundation with Silver

Currently trying to compile only these two files as one jar:


Using this command:

ElementsCC.exe --assembly=SwiftFoundation --out=bazel-out/darwin_x86_64-fastbuild/bin/external/swift_foundation -q --ref=external/local_jdk/jre/lib/rt.jar --ref=external/elements/References/Cooper/swift.jar --ref=external/elements/References/Cooper/cooper.jar --ref=external/elements/References/Cooper/elements.jar external/swift_foundation/Sources/SwiftFoundation/SemanticVersion.swift external/swift_foundation/Sources/SwiftFoundation/Version.swift -t=staticlibrary -m=cooper

Getting this error:

/private/var/tmp/_bazel/811f60be6a1051cf49585ebc378f1218/bazel-sandbox/1161139342624471822/execroot/repo/external/swift_foundation/Sources/SwiftFoundation/SemanticVersion.swift (11:43) [E36] Interface type expected, found "RawRepresentable<RawValue>!"
/private/var/tmp/_bazel/811f60be6a1051cf49585ebc378f1218/bazel-sandbox/1161139342624471822/execroot/repo/external/swift_foundation/Sources/SwiftFoundation/SemanticVersion.swift (36:9) [E114] Method has no result
Compilation failed

Any suggestions?

FTR, this would be so much easier if you could (a) use and (b) provide actual projects.

ok:

	public init?(rawValue: String) {
		return nil // E114 Method has no result
	}

looks like a bug. return should be supported, with nil only, in a bailable initializer. will log.

For

public struct SemanticVersion: Equatable, RawRepresentable, CustomStringConvertible { // E36 Interface type expected, found "RawRepresentable<RawValue>!"

i believe you need to provide the generic parameter for RawRepresentable, eg:

public struct SemanticVersion: Equatable, RawRepresentable<String>, CustomStringConvertible {

compiles ok. I agree the error could be better there, so i’ll log that too.

thanx!

Thanks, logged as bugs://78196

Thanks, logged as bugs://78197

Sorry but if you recall I’m integrating the compiler into http://bazel.build
which fwiw is working pretty well!

RE: that generic declaration, this code compiled as is with the standard
swift compiler so having to modify this code seems like something I
shouldn’t have to do, right?

Cool.

probably not. i logged it as a two-part bug, (a) that the error is confusing, bit (b) that we should match Apple Swift’s behavior. TBH i;m not quite sure why it compiles in Apple Swift, i guess there’s rues for inferring generic parameters that i’m not 100% up to speed with, we’ll figure it out.

Not sure if your team has ever tried to compile this project, I noticed you
have a fork of it on GitHub.

When I tried to glob and compile the whole module there were hundreds of
errors. I started trying to compile subsections so I could file discrete
bugs with your team. I’ll share more as I go.

We have, but it’s been a while.

Note that the goal with Silver never is/has been 100% sure compatibility. Some of the syntaxes and corner cases of Apple Swift we juts cannot support on all platforms (such some of more esoteric generics and protocol (ab)uses), because the runtimes impose their own restrictions on whats allowed.

Totally understand and what you’ve done so far is remarkable! Am I going
the wrong direction trying to get foundation working? I want to be able to
cross compile things like: https://github.com/apple/swift-protobuf

Derek,

Just wanted to throw in my two cents: I too am of the opinion that a Foundation port would be useful in some scenarios. I am testing the feasibility in a side project I am doing now, only porting those bits I need. As Marc said above, in the end there may be cases that it does not work well or may not work at all. But I figure the more Swift code we can share the better.

If I get to a point where I think things can work or not, I would love to put it out there to share and have others work on it at the same time, or if there is a project already out there, to contribute patches to it to make it work in Elements.

Thank you,
Tyler

I think the reality is that any dependency my project will take in will
likely “import Foundation” and its unsustainable for me to be constantly
forking and rewriting things that depend on it.
I too am happy to contribute to something that helps provide this
portability layer. SwiftFoundation seems like a good place to start. I’m
having a hard time understanding the boundaries between SwiftBaseLibrary vs
RTL(2) vs Cooper vs (Swift)Foundation.

Thanx, much appreciated!

not necessarily, no.bat least 50% of your previous report was an actual bug, possibly more. There’ll be a mixture of (a) more stuff we can./need to fix and (b) finding a way to deal with stuff we can’t fix, and how to integrate that. Wonder how open the PureSwift guys woods be to some #if SILVERs…

Thing is, Silver (and Elements in general) is sort of designed towards sharing Elements code across platforms. not for sharing platform vendor code with Elements.

IOW. the goal to write an iOS and an Android app in Swift is to use Silver for both, not Xcode for one and Elements for the other. DFito, say, when sing C# for .NEt and Mac — use ROC# for both, not Visual C# and ROC#. More like Case Study: Curaçao Weather | RemObjects Software.

That’s not to say getting more “Apple Swift” code to compile won’t be good, and getting a version of Foundation that provides API level compatibility (whether 100%,or 10% shared with PureSwift) would not be good.

that’d be super appreciated.

  • cooper.jar/echoes.dll, libToffee: small helper libraries that add stuff ALL LANGUAGES need, thats missing on the platform (say, unsigned ints for Cooper, LINQ for Cocoa, etc)

  • Swift(BaseLibrary): stuff the Swift language “needs”, like [:] types, and some basic compatibility types (extensions to make String more like Apple Swift string, etc)

  • Elements RTL: a totally independent optional library that provides a common set of APIs, across all platforms. It’s what you wanna use Foundation for, just that ts not foundation but an API we designed.

does that make sense?

OK cool, that is all making sense.

I’m currently trying to reconcile how I’d structure an application to
support both Android and iOS targets with a single swift codebase. I
imagine I’d have cross platform protocols and implement instances of that
protocol with native libs on JVM and Cocoa, respectively. I just think its
unavoidable that code which could potentially be cross compiled will depend
on bits of Foundation that require modification to support this compiler,
that is non-ideal because they end up being forks that easily get out of
sync.

For my project in particular, protobuf support is a must on both iOS and
Android. Ideally, the API would be identical in both languages at a code
level, otherwise this swift code abstraction loses some of its appeal. That
is the main reason I am trying to compile ProtobufSwift (which seems to
rely on Foundation), I’d like to be able to use one uniform API for both
platforms.

The trick is to not use Foundation, for base stuff, but to use Elements RTL. Only use plattform specific APIs for plaforrm=specific code (eg Apple Maps, in the case study i linked). I have a blog post in the works with some more notes and strategies, hopefully for next week.

Strategy: try to port the protobuf to compile against Elements RTL instead of the rest of Foundation. That way, it’llwork on all four platforms immediately.

bugs://78196 got closed with status fixed.

If you have a moment to upload this I can test this out and report more
issues. Thanks!

will do!

Done!