Scoped compiler options

[cardillan]

Task to add scopes to compiler options. Currently, all options have a global scope. New scopes will be:

• global: settable in the main input file,
• module: settable at a module level,
• local: settable at an AST node level.

The #set directive used in the main input file sets the option at the global level. When used inside a module imported through the require directive, it sets the option at the module level. Modules imported via require directive from another module inherit options from the global scope, not from the module that required them, to avoid conflicts in case a module gets imported from two different modules using different options.

The #set directives can be placed anywhere in the source file, however they should be placed at the very top of each file, before every other directive except a module declaration.

When compiling a standalone module (as a remote processor), the module is also the main input file and therefore the options set within it are global.

(Note that a module declaration will be required for all files to be included via the require directive.)

A new #setlocal directive sets options locally. This directive applies to the next AST node. Multiple #setlocal directives can be applied to the next node. To apply the directive to more AST nodes in succession, it is possible to use a code block.

A #setlocal directive can be used with function declaration, in which case it sets the option for the entire function body.

Trying to set a non-local compiler option using #setlocal causes an error.

Compiler directive	Scope
auto-printflush	global
boundary-checks	local
function-prefix	global
goal	local
instruction-limit	global
link-guards	global
mlog-indent	global
optimization	local
passes	global
print-unresolved	global
profile	global
remarks	local
sort-variables	global
symbolic-labels	global
syntax	module
target	module
target-optimization	local
specific optimizations	local
execution flags	global
altering code weight	local

Inline functions

Effective options within the body of an inline function correspond to effective options of the function declaration, they aren't inherited from the call site (this will need to be specifically handled). This is motivated by the principle of least surprise.

Specific option handling

Option syntax

All modules are implicitly compiled using the strict syntax. If the syntax option is used within a module, the only value that can be set is strict.

Option target

Option target, when set within a module, specifies the target supported by the module. If the global target setting isn't compatible with the target specified by the module, a compilation error occurs with a message 'Module <module name> in file <file name> requires target compatible with <target>.'

Target compatibility matrix:

Target	Compatible targets
6.0	6.0, 7.0
7.0	7.0
7.1	7.1 or higher
8.0	8.0 or higher

The incompatibility between 7.0 and 7.1 is caused by different instruction mappings.

Future targets will be compatible with all higher targets, unless a backwards-incompatible feature is introduced to Logic.

Option goal

Function and array inlining are governed by the goal option set in the global scope.

Function call and array access inlining are governed by the local goal option at the site of the function call/array access. It is therefore possible to prevent inlining of a specific function call/array access if need be.

Setting the goal option locally primarily allows to prevent or enforce unrolling or particular loops, or converting particular case expressions to jump tables.

Optimization options

Optimization options are handled specifically:

1. Activating/deactivating an optimizer is only allowed at a global level. For example, when optimization is set to none at the global level, no optimizations will happen regardless of module or local scope compiler directives.
2. At the local level, it is possible to switch between optimization levels, if the given optimization is active.
3. Some optimization options won't be local. The final list will be created during implementation.

Altering code weight

A new option will be created to alter code weight by multiplying it with some additional factor. This can be used to preferentially choose a specific portion of code for speed optimizations (e.g. loop unrolling).

To decrease the code weight, it will be possible to multiply it with a value lower than 1.