In 3.5.18 there are too many false warnings and errors!!!

Warning like in attachment can be ignored, but is a non sense!!!!!!!!!!

For example to avoid unreadable UNIONS that make only confusion we use a bits structure:

TYPE SimpleAxisControlWord :
STRUCT
    switchOn : BIT;
    enableVoltage : BIT;
    quickStop : BIT;
    enableOperation : BIT;
    startMove : BIT;
    free5 : BIT;
    free6 : BIT;
    faultReset : BIT;
    halt : BIT;
    free9 : BIT;
    free10 : BIT;
    free11 : BIT;
    free12 : BIT;
    free13 : BIT;
    free14 : BIT;
    free15 : BIT;
END_STRUCT
END_TYPE

We map structure to raw controlword in variable declaration:

VAR
    m_controlWordRaw : UINT;
    m_controlWordPtr : POINTER TO SimpleAxisControlWord := ADR(m_controlWordRaw);
    m_controlWord : REFERENCE TO SimpleAxisControlWord REF= m_controlWordPtr^;
    m_statusWordRaw : UINT;
    m_statusWordPtr : POINTER TO SimpleAxisStatusWord := ADR(m_statusWordRaw);
    m_statusWord : REFERENCE TO SimpleAxisStatusWord REF= m_statusWordPtr^;
...
END_VAR

It's like a fake union many times more readable in code!

IF m_statusWord.fault THEN
   ....

From 3.5.18 a tedious C0139 Warning is compared! This warning tell that m_controlWordRaw isn't used in code! This is only apparent due use of a reference in declaration!

Second problem is impossibility to map ENUMS in IO_Mapping!!!
This now bring in a ERROR!

It's a non sense due variables like modeOfOperation should be managed with ENUMS!
Use of magic numbers in an application is a criminal development method! This error is an invite to magic numbers usage!

Example if we define:

{attribute 'strict'}
TYPE SimpleAxisModeOfOperands :
(
    ProfilePosition := 1,
    HomingMode := 6,
    CyclicPositionMode := 8
) USINT;
END_TYPE

When we map a SimpleAxisModeOfOperands variable to IO field we raise error!

Third problem is ERROR returning REFERENCE TO in methods!
It's in opposite side of OOP paradigm! In opposite side should be implemented also CONSTANT REFERENCE TO!

If is not possible usage of REFERENCE TO in return value we are invited in a OOP privacy violation! A non sense in a OOP paradigm where all properties of an object should remain private and exposed only via methods!

I'm no part of codesys.

C0139 Warning pops up because your pointer value is read only at intitialisation. But the address may change with an online change : (see first hint)
https://help.codesys.com/webapp/_cds_cmd_online_change;product=codesys;version=3.5.14.0

Enumerations are a list a values that a variable may take. Meaning that this variable is expected to not take any other value than those defined in the enumeration.
Using such a type on an input is weird, because you should handle the other case (unexpected values) with a default value. So it does not feel weird to me to get a warning on this point.

OOP does not forbid accessing properties. This is the exact opposite. It advise using properties to protect your internal values. https://help.codesys.com/webapp/_cds_obj_property;product=codesys;version=3.5.14.0#get-and-set-accessors