handle compilation of contracts properly (v4.x.x -> v5.x.x)

[marc0olo]

@thepiwo raised the issue that people using the hosted compiler (which will be updated to v5.x.x) will have problems if their contracts rely on certain Sophia functionalities which faced breaking changes. for example accessing String.length requires stdlib include 'String.aes' since v5.x.x

problems we see for actual users/developers:

• compiling "broken contracts" the new compiler will cause errors
  • if they have a pragma @compiler =< 4.3 the compiler will raise an expected error that the contract is incompatible with v5.x.x and we know that the contract must be compiled with a compiler v4.x.x
  • if the contracts don't include a pragma an "unexpected error" will occur
• we assume that
  • many developers wrote contracts without explicitely specifying a pragma
  • many have included their contracts within javascript sourcecode

we definitely need instructions for users how to deal with it.

ideally the SDK

• properly handles at least the expected error returned by the compiler if the pragma is set correctly and notifies the dev with an appropriate message
• the developer can define for each contract which compiler version should be used

---

as @thepiwo mentioned different versions of the hosted compiler can be used by specifying the version in the header:

• curl https://compiler.aeternity.io/version -H 'Sophia-Compiler-Version: 5.0.0'

[mradkov]

Can we use the latest compiler by default after Iris and dry-run the contract calls before they get broadcasted?

In case this fails - we switch to a failover compiler with lower pragma?

[kenodressel]

I guess we could strive for a middle ground:

• If we use the latest compiler by default I would just go for it and broadcast the transaction immediately, no need to create lots of dry run traffic
• We should obviously respect the pragma, take the latest "valid" compiler
• When everything else fail, we should probably hand the responsibility (with meaningful error messages) back to the dev and have him/her find a fail-over strategy

[marc0olo]

• We should obviously respect the pragma, take the latest "valid" compiler

so that would mean that the SDK needs to handle that properly based on parsing the pragma and the dev needs to be able to pass URL for at least all major releases from v4.0.0 - v6.0.0 of the compiler, right? IMO we should have fixed URLs for the hosted compiler version then instead of requiring to pass the respective version in the header.

what's your take on that @davidyuk?

[davidyuk]

This stuff doesn't seem to be heavily related to sdk. HTTP compiler can automatically set a proper backend according to pragma and maybe some heuristic on source code (like if pragma is not defined and contract uses String.length without importing String.aes).

[thepiwo]

HTTP compiler can automatically set a proper backend according to pragma

I agree with that. I don't thin we should use some heuristic though.

[marc0olo]

I second that. so for choosing the right backend we need https://github.com/aeternity/aesophia_http to handle that stuff based on the provided pragmas, right? or did you mean another solution? I just want to be sure that we have the same understanding.

and if no pragma is set the http compiler will use the latest backend version by default.

[davidyuk]

we need https://github.com/aeternity/aesophia_http to handle that stuff based on the provided pragmas, right?

yes

[hanssv]

aesophia_http runs one (1) version of the compiler I don't think there are any plans to change this.

[davidyuk]

Firstly, this doesn't seem to be a big problem now (until we have a new compiler with breaking changes🙂). Also, we are not using a compiler for contract calls now (calldata lib instead), so future breaking changes would affect only contract deployments. I'm proposing to close his issue with an agreement to deploy compilers on different domains per version (like 6.compiler.aepps.com) to don't break existing apps that depend on compiler.aepps.com/latest.compiler.aepps.com in case of new compiler version