Re: Row pattern recognition

Hi Seongjun,

> Yes -- here gram.h has both the enum and the macro:
>
> enum yytokentype { ...; INITIAL = 472; ... };
> #define INITIAL 472
>
> The file header says "made by GNU Bison 2.3". That's macOS's system
> bison, and it still emits the #define token macros, so INITIAL collides
> with flex's #define INITIAL 0 in the scanner. Your 3.8.2 emits only the
> enum, which is why you don't see it.

That makes sense.

> 2.3 is the minimum the tree still
> accepts (meson.build asks for >= 2.3) and it's what macOS ships, so a
> build on that floor hits the warning.

Yeah, wee should accept a build envrionment with bison 2.3.

>> probably we should consider change "INITIAL" to something like
>> "INITIAL_P" to avoid the collision?
>
> That matches the _P convention already used for NULL_P / TRUE_P / IN_P,
> so it seemed worth trying. I've attached a small patch that renames the
> token to INITIAL_P in kwlist.h and gram.y; the SQL keyword stays
> "initial". With it applied, both -Wmacro-redefined warnings are gone and
> the build is warning-clean here, still on bison 2.3. The patch is on top
> of v49 and named nocfbot-*.txt so cfbot doesn't pick it up. No rush on
> this -- it can wait for whenever a cleanup pass fits. Please fold it in
> or adjust as you see fit.

Thanks for the patch. Your patch looks good to me except "INITIALLY"
should be before "INITIAL_P" in ASCII. ('L' == 0x4c, '_' == 0x5f in
ASCII).

> - INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIAL INITIALLY INLINE_P
> + INCLUDING INCREMENT INDENT INDEX INDEXES INHERIT INHERITS INITIAL_P INITIALLY INLINE_P

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp