The builtin {cargo|rail|road|tram}type functions do not work if the corresponding tables are defined by the user

[stormcone]

There is a topic on the forum that the cargotype function does not work:
https://www.tt-forums.net/viewtopic.php?t=90428

I did some test and looks like that in functioncall.py the global constant tables are empty if the tables defined by the nml file:
https://github.com/OpenTTD/nml/blob/bbe945ed348dfe19d284908983c8bb55e0d840ad/nml/expression/functioncall.py#L480C1-L485

I put the following commands after line 494:

    generic.print_dbg(6, global_constants.cargo_numbers)
    generic.print_dbg(6, global_constants.railtype_table)

If I define the cargotable and the railtypetable, then that is the output:

      {}
      {}

So looks like the tables are empty.
If I do not define the railtypetable, the second table is not empty:

      {}
      {'RAIL': 0, 'MONO': 1, 'MGLV': 2}

Version

$ nmlc --version
0.7.4

Expected result:
The attached nml file can be compiled

Actual result:
nmlc ERROR: "test.nml", line 16: Parameter for railtype() must be a string literal that is also in your railtype table

Steps to reproduce:

• nmlc test.nml
  Output:
  nmlc ERROR: "test.nml", line 16: Parameter for railtype() must be a string literal that is also in your railtype table

• Edit the test.nml: comment out the railtypetable:
  // railtypetable { RAIL, ELRL, MONO, MGLV }
nmlc test.nml
  Output:
  nmlc ERROR: "test.nml", line 24: Parameter for cargotype() must be a string literal that is also in your cargo table

• Comment out the cargotable and the cargotype_available if statements too:

// cargotable { PASS, MAIL, LVST }
// if (cargotype_available("LVST"))
// {
// 	item(FEAT_CARGOS, cargo_lvst, cargotype("LVST"))
// 	{ 
// 		property { weight: 12.0/16; }
// 	}
// }

nmlc test.nml
Output:
nmlc info: 0 sprites, 0 cached, 0 orphaned, 0 duplicates, 0 newly encoded (native)
nmlc info: Railtype items: 1/64
nmlc info: Concurrent ActionD registers: 1/64 ("test.nml", line 14)

cargo_type_test.zip

[glx22]

Hmm order of events is annoying, builtin validation happens during parsing, while populating the tables happens during preprocessing.

It think the issue started with 93c8cfc for cargotable, and with 1070b5d for railtypetable.

[glx22]

Named parameters seem to have a similar issue when used as 3rd and 4th arguments of item. They don't exist before preprocessing but item checks for them during parsing.