search

bmx-ng / bcc

A next-generation bcc parser for BlitzMax
zlib License
33 stars 13 forks source link

Unsupported type for name mangling #643

Closed thareh closed 7 months ago

thareh commented 7 months ago

Good day,

There seems to be a new issue:

test.mod/test1.mod/test1.bmx

SuperStrict

Module test.test1

Import BRL.Collections

Local map1:TTreeMap<String, String> = New TTreeMap<String, String>()
Framework BRL.Blitz
Import BRL.StandardIO
Import test.test1

Print "TEST"

Produces the error Unsupported type for name mangling : $TMapNode.

Thank you.

woollybah commented 7 months ago

Yeah, the issue is that it's trying to build the generated name while it loads...

Given that we know what the name is going to be, we may as well store that and pass it in via the .i file, then there's nothing to do other than fill in the blank.

We'll be passing in both the scope and class mangled names now, which is a change to the .i format (for generic classes).

woollybah commented 7 months ago

So now it puts "test_test1|test_test1_IIterableS" into the .i file. And on load, populates scope with "test_test1" and the class with "test_test1_IIterableS" (which I had it trying to work out during parsing).

thareh commented 7 months ago

Thank you! You're the best! If only I had the wits to understand what you're describing, maybe some day...

GWRon commented 7 months ago

Once the solution is there ... I guess we understand it :)

I understood it the way that the parser had issues/was not ready to/.. creating "test_test1_IIterableS" out of "test_test1" and the given source code. So to ease that pain Brucey added this information to the .i-file making it easier for bcc to work with it.

Now this makes me wonder if such an extension could help the bcc in other cases too. So storing "meta information" during generation instead of having bcc doing guess work multiple (?) times.