Consolidate configuration macros

[akosthekiss]

The engine's code base has lots of macro guards, making it well-configurable. However, these macros grew somewhat organically and got named as CONFIG_{EN,DIS}ABLE_xxx, CONFIG_xxx, {EN,DIS}ABLE_xxx, JERRY_{EN,DIS}ABLE_xxx, JERRY_xxx, or modulename_xxx. Quite a mix. Moreover, right now it is encoded in some of the names of the macros whether they are enabled/disabled by default (but not in all of the names). And boolean configuration macros make their effect based on whether they are defined or not, while the rest carry their meaning via their content.

I propose to consolidate the configuration macros name and value wise, as shown in the table below:

Current macro	Proposed macro	Proposed value
ES5.1 features
CONFIG_DISABLE_BUILTINS	JERRY_BUILTINS	{0,1}
CONFIG_DISABLE_ANNEXB_BUILTIN	JERRY_ANNEXB_BUILTIN	{0,1}
CONFIG_DISABLE_ARRAY_BUILTIN	JERRY_ARRAY_BUILTIN	{0,1}
CONFIG_DISABLE_BOOLEAN_BUILTIN	JERRY_BOOLEAN_BUILTIN	{0,1}
CONFIG_DISABLE_DATE_BUILTIN	JERRY_DATE_BUILTIN	{0,1}
CONFIG_DISABLE_ERROR_BUILTINS	JERRY_ERROR_BUILTINS	{0,1}
CONFIG_DISABLE_JSON_BUILTIN	JERRY_JSON_BUILTIN	{0,1}
CONFIG_DISABLE_MATH_BUILTIN	JERRY_MATH_BUILTIN	{0,1}
CONFIG_DISABLE_NUMBER_BUILTIN	JERRY_NUMBER_BUILTIN	{0,1}
CONFIG_DISABLE_REGEXP_BUILTIN	JERRY_REGEXP_BUILTIN	{0,1}
CONFIG_DISABLE_STRING_BUILTIN	JERRY_STRING_BUILTIN	{0,1}
ES2015 features
CONFIG_DISABLE_ES2015	JERRY_ES2015	{0,1}
CONFIG_DISABLE_ES2015_ARROW_FUNCTION	JERRY_ES2015_ARROW_FUNCTION	{0,1}
CONFIG_DISABLE_ES2015_BUILTIN	JERRY_ES2015_BUILTIN	{0,1}
CONFIG_DISABLE_ES2015_CLASS	JERRY_ES2015_CLASS	{0,1}
CONFIG_DISABLE_ES2015_MAP_BUILTIN	JERRY_ES2015_MAP_BUILTIN	{0,1}
CONFIG_DISABLE_ES2015_OBJECT_INITIALIZER	JERRY_ES2015_OBJECT_INITIALIZER	{0,1}
CONFIG_DISABLE_ES2015_PROMISE_BUILTIN	JERRY_ES2015_PROMISE_BUILTIN	{0,1}
CONFIG_DISABLE_ES2015_TEMPLATE_STRINGS	JERRY_ES2015_TEMPLATE_STRINGS	{0,1}
CONFIG_DISABLE_ES2015_TYPEDARRAY_BUILTIN	JERRY_ES2015_TYPEDARRAY_BUILTIN	{0,1}
ES compatibility options
CONFIG_DISABLE_UNICODE_CASE_CONVERSION	JERRY_UNICODE_CASE_CONVERSION	{0,1}
ENABLE_REGEXP_STRICT_MODE	JERRY_REGEXP_STRICT_MODE	{0,1}
Engine features
CONFIG_ECMA_NUMBER_TYPE	JERRY_NUMBER_TYPE	{float32,float64,float,double} (was: {1,2})
JERRY_CPOINTER_32_BIT	JERRY_CPOINTER_32_BIT	{0,1}
JERRY_DEBUGGER	JERRY_DEBUGGER	{0,1}
JERRY_DISABLE_JS_PARSER	JERRY_PARSER	{0,1}
JERRY_ENABLE_ERROR_MESSAGES	JERRY_ERROR_MESSAGES	{0,1}
JERRY_ENABLE_EXTERNAL_CONTEXT	JERRY_EXTERNAL_CONTEXT	{0,1}
JERRY_ENABLE_LINE_INFO	JERRY_LINE_INFO	{0,1}
JERRY_ENABLE_LOGGING	JERRY_LOGGING	{0,1}
JERRY_ENABLE_SNAPSHOT_EXEC	JERRY_SNAPSHOT_EXEC	{0,1}
JERRY_ENABLE_SNAPSHOT_SAVE	JERRY_SNAPSHOT_SAVE	{0,1}
JERRY_SYSTEM_ALLOCATOR	JERRY_SYSTEM_ALLOCATOR	{0,1}
JERRY_VM_EXEC_STOP	JERRY_VM_EXEC_STOP	{0,1}
Engine optimizations
CONFIG_ECMA_LCACHE_DISABLE	JERRY_LCACHE	{0,1}
CONFIG_ECMA_PROPERTY_HASHMAP_DISABLE	JERRY_PROPERTY_HASHMAP	{0,1}
Data placement
JERRY_CONST_DATA	JERRY_ATTR_CONST_DATA	anything
JERRY_HEAP_SECTION_ATTR	JERRY_ATTR_GLOBAL_HEAP	anything (was: a section name)
Parser configuration
PARSER_MAXIMUM_CODE_SIZE	JERRY_PARSER_MAXIMUM_CODE_SIZE	number
PARSER_MAXIMUM_IDENT_LENGTH	JERRY_PARSER_MAXIMUM_IDENT_LENGTH	number
PARSER_MAXIMUM_NUMBER_OF_LITERALS	JERRY_PARSER_MAXIMUM_NUMBER_OF_LITERALS	number
PARSER_MAXIMUM_NUMBER_OF_REGISTERS	JERRY_PARSER_MAXIMUM_NUMBER_OF_REGISTERS	number
PARSER_MAXIMUM_STACK_LIMIT	JERRY_PARSER_MAXIMUM_STACK_LIMIT	number
PARSER_MAXIMUM_STRING_LENGTH	JERRY_PARSER_MAXIMUM_STRING_LENGTH	number
Allocator configuration
CONFIG_MEM_HEAP_AREA_SIZE	JERRY_GLOBAL_HEAP_SIZE	number (in KB)
Developer options
JERRY_VALGRIND	JERRY_VALGRIND	{0,1}
JMEM_GC_BEFORE_EACH_ALLOC	JERRY_MEM_GC_BEFORE_EACH_ALLOC	{0,1}
JMEM_STATS	JERRY_MEM_STATS	{0,1}
PARSER_DUMP_BYTE_CODE	JERRY_PARSER_DUMP_BYTE_CODE	{0,1}
REGEXP_DUMP_BYTE_CODE	JERRY_REGEXP_DUMP_BYTE_CODE	{0,1}

Notes:

• Alternatively, the prefix of all configuration macros might be JERRY_CONFIG_ instead of JERRY_.
• There is one 'boolean' config macro that cannot/shouldn't be rewritten to 0/1: JERRY_NDEBUG. Traditionally, the semantics of an NDEBUG that macro is defined/not-defined everywhere.
• I haven't listed JERRY_GET_CURRENT_CONTEXT above as I hope it goes away soon (see Remove the JERRY_GET_CURRENT_CONTEXT macro #2512).
• I find the value set of the existing CONFIG_ECMA_NUMBER_TYPE (1/2) somewhat counterintuitive. Thus, I've proposed to enable string values (float32,float64,float,double). I think that approach could be managed by some preprocessor magic (using ## concatenation).

Some additionally observed problems:

• Not all of the above configuration options are available via the python build script and/or cmake options (i.e., they have to be passed as compiler arguments).
• Not all of the above configuration options are available as feature enum labels of the engine, so they are not queryable at run-time. (Among others,) this leads to leaking macro usage into users of the engine (e.g., jerry-main, jerry-ext, or jerry-port using jerry-core macros in #ifs).
• Not all of the above macros are documented at all.
• Configuration macro names and cmake option names are quite unaligned, which adds one more layer to the naming mix.

Foreseen work items:

• Refactoring of the jerry-core code base to rename the macros and guard code blocks based on macro values.
• Follow up in the cmake build system to pass macros with values to the compiler.
• Follow up in the python build tool to pass the right cmake options.
• Follow up in the lit-magic-strings.inc.h generator tool (gen-magic-strings.py).
• Follow up in jerry-main, jerry-port, and jerry-ext, to ensure that 'leaked' macros are used according to the new semantics.
• Follow up in targets to adapt the builds (mostly: with which options cmake is called).

I think such a rework would help code quality, clarity, and maintainability. I'm also volunteering to work on this, but I'd like to get some feedback first so that it's not done in vain. So, please, let me know what you think about this in general, or about any of the details (e.g., preferred config macro names, values, etc.)

PS: I know that we have had quite some discussion about config macros before, even heated ones. I'm not afraid of putting the topic on the table again, believing that it may make the project better.

[zherczeg]

I think this is a good idea as long as we finish it completely.

One more thing: we need an easy way to enable group of features excluding some of them. E.g. I want an ES 5.1 engine except regular expressions.

[lygstate]

Looks good, better before 2.0 release

[Achie72]

As someone who is "fairly" new to contributing, i highly support the idea. The current ones make enable/disable way too confusing, as contributors (unless they have a fair bit of knowledge in the system) have to constantly think about the "disable the disabled to make it enabled", which leads to constant headaches and macro define checkups. A unified system can help to spare this process, and make contributing much easier.
As for the proposed names personally i don't think the JERRY_CONFIG_ is a good idea instead of just JERRY_. To me it seems redundant and makes the macro names unnecessarily long.
The macro documentation idea could be helpfull for new contributors,i think, as we have a lot of them, also the macro-cmake naming could be unified as well.