Supported backends annotation

[loicrouchon]

We need a backend annotation that can be applied on a Module.
If this annotation is not provided, then, all backends would be considered as supported.

This will be useful for tools like ceylon.build to discover modules for JVM / JS backends.
It could also be used in the compiler to throw an error in case your trying to compile for a backend which is not supported.

[gavinking]

Sure. But I thought there was already an issue proposing this...?

[loicrouchon]

#327 was mentioning it but it has been closed and split into #499 and #500 that doesn't mention this feature.

[lucaswerkmeister]

With this, #969 / ceylon/ceylon-compiler#1648 could be fixed in the typechecker.

[gavinking]

@quintesse isn't this part of what you're working on with the new native stuff?

[quintesse]

It would have to be part of it when implementing it fully, yes, mostly for #499 while for now I was handling #500 first.

What would the annotation be? A new one like suggested here (backend) or do we repurpose native for this? The only potential problem I see with the latter is if we ever support more than 2 backends we'd either have to let you write native("jvm,js") or change the restrictions on the annotation to allow more than one.

[gavinking]

I would reuse native, yes.

[quintesse]

I'm wondering about something here. What is this annotation supposed to do actually? It seems okay as an indication, but you can't really trust it can, you? I mean, you could easily write a module that was backend dependent and not use this annotation. So the absence of this annotation would not guarantee that the module can be used by all backends. Without that guarantee it seems to lose much of its value, right?

[luolong]

Well, @gavinking suggested at one point that it's native platform availability is an attribute of a module. So, typechecker could (in theory) validate that the imported module indeed supports the the platform it is marked for.

[quintesse]

Well I'm not so sure it could validate it, except perhaps to check that you're not lying (saying your code is for the JVM backend when it's obviously for the JS backend). But I don't think it can actually strictly check it (otherwise we could just generate the required information, right?).
And if we can't strictly trust that annotation (the developer just forgot to put it there) then we're back to checking the repository for the existence of CAR/JAR vs JS artifacts for the real answer.
So I still wonder what the usefulness is of this annotation.

[gavinking]

@quintesse there were two things we came up with for this:

1. To indicate which modules are platform-specific in a large project like ceylon-sdk with multiple modules.
2. To avoid the need to annotate the module import native in every place the module is used.

[quintesse]

@gavinking ok, understood, so we simply say that each compiler backend will refuse to compile a module annotated native for a different backend.
That seems easy enough.
If you don't mind I'd still like to at least add the possibility to add a native annotation on imports for those cases where the module wasn't annotated.

[gavinking]

If you don't mind I'd still like to at least add the possibility to add a native annotation on imports for those cases where the module wasn't annotated.

Well my problem with all this is that there's currently no validation at all that if some declaration is backend-specific, then it is only used from within other declarations specific to that same backend.

So basically, as this functionality exists today, annotating a module import with native would do essentially nothing useful, since you don't actually make any use of this information.

[quintesse]

I'll close this now because this is now implemented as described in the issue at least.