Skip to content

some kinds of amalgamated signal statements appear to be incredibly picky about the whitespace around #define statements #31

@weatherhead99

Description

@weatherhead99

Honestly I don't have time to investigate this and I have no idea why this happens but the following code snippet:
`
#define SW_SCI2 12 : 16 //new VIB redefine
#define SW_SCI1 12 : 15 //new VIB redefine

#define SW_SCI3 12 : 14 //new VIB assignment
#define SW_SCI4 12 : 13 //new VIB assignment

/* Summing Well Combine */
/*define SW [SW_SCI1, SW_SCI2, SW_SCI3, SW_SCI4] */
#define SW [SW_SCI2 , SW_SCI3 , SW_SCI4, SW_SCI1]
`

compiles fine, whilst this one:

`

#define SW_SCI2 12 : 16 //new VIB redefine
#define SW_SCI1 12 : 15 //new VIB redefine
#define SW_SCI3 12 : 14 //new VIB assignment
#define SW_SCI4 12 : 13 //new VIB assignment

/* Summing Well Combine */
/*define SW [SW_SCI1, SW_SCI2, SW_SCI3, SW_SCI4] */
#define SW [SW_SCI2 , SW_SCI3 , SW_SCI4, SW_SCI1]
`

does not compile, appearing that GPP never substituted the definitions of e.g. SW_SCI2 this time. Note the ONLY difference here appears to be an extra carriage return character. This is likely a bug in gpp in my estimation, rather than our parser

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions