Remove the ENABLED/DISABLED macros

[rerobika]

The removal of these macros enabled cppcheck to reveal new errors.
These errors are also fixed by the patch.

JerryScript-DCO-1.0-Signed-off-by: Robert Fancsik [email protected]

[akosthekiss]

Looks good in general. But

• There are some new cppcheck suppressions. Cannot these be removed/avoided?
• Why is the new cppcheck-specific macro/guard necessary in the code? Especially in a public header! (jerryscript-compiler.h)
• Rebase and resolve conflicts.
• A humble suggestion to improve a bit on the commit message: "Remove the ENABLED/DISABLED macros // The removal of these macros enabled cppcheck to reveal new errors. These errors are also fixed/suppressed by the patch."

[akosthekiss]

This is something new. At least to me. Why is this necessary?

[rerobika]

This macro was used to prevent JERRY_LIKELY(x) to use __builtin_expect since it's only a GCC extension and cppcheck does not know how to interpret it correctly. Until this workaround there were false positive alarms for the following like of code parts:

any_kind *obj_p = do_somenthing();

if (JERRY_UNLIKELY (obj_p == NULL)) {
 return;
}

JERRY_ASSERT(obj_p);
obj_p->anything++; // warning(nullPointerRedundantCheck): Either the condition 'obj_p==NULL' is redundant or there is possible null pointer dereference: obj_p.

So now whenever the cppcheck is running the JERRY_{UN}LIKELY macros are forced to JERRY_{UN}LIKELY(x), without _CPP_CHECK_. See here.

Moreover, there are no new inline suppressions by the patch and the number of already existing ones have been reduced to 1. This can be resolved later, but I didn't find a good solution it for now.

[dbatyai]

LGTM

[akosthekiss]

Please, rebase and resolve conflicts.

[rerobika]

@akosthekiss The patch is rebased.

[akosthekiss]

LGTM