BMX-NG duplicate identifier bug

BlitzMax Forums/Brucey's Modules/BMX-NG duplicate identifier bug

BlitzSupport(Posted 2016) [#1]
Just ran into this:

Local pos:Int = 1

Local pos:Int = 2


BRL BMX correctly says: "Compile Error: Duplicate identifier 'pos'", but...

BMX-NG says "Compile Error: Duplicate identifier '__LocalMain'."


Derron(Posted 2016) [#2]
SuperStrict
Framework Brl.Blitz

Local pos:Int = 1

Local pos:Int = 2


build process:
Building duplicate_01
[ 97%] Processing:duplicate_01.bmx
Compile Error: Duplicate identifier 'pos'.
[/BlitzMaxNG/bin/tests/framework/language/duplicate_01.bmx;6;0]
Build Error: failed to compile (65280) /BlitzMaxNG/bin/tests/framework/language/duplicate_01.bmx
Process complete

(Edit: same result when not using superstrict)

Did you use an older BCC?

bye
Ron


Brucey(Posted 2016) [#3]
You can run "bcc -v" from your bin dir to get the version number :-)


BlitzSupport(Posted 2016) [#4]
C[rikey]-on-a-bike! My bcc wasn't that old, only Jan sometime!

Well done/apologies, works perfect, after all! Need to update more often, obviously...


Brucey(Posted 2016) [#5]
It's a bit of a moving target at the moment...


BlitzSupport(Posted 2016) [#6]
Ken, eh! (Fae Dundee.)


Derron(Posted 2016) [#7]
@ bcc-v

You might think of adding some kind of "build-version-string-file" which you increment on each "git commit" (read about git and hooks). So you could have a "build"-string and an revision-string.
Sometimes you change BCC without incrementing the version string.

Dunno if "BCC NG" should output its version information on compilation (like in a "starting compilation"-message) or whether every output of bcc is considered as an error for BMK...


bye
Ron


Brucey(Posted 2016) [#8]
Sometimes you change BCC without incrementing the version string.

I've generally only been changing the version number if changes result in requiring a rebuild of the modules.


Derron(Posted 2016) [#9]
For module rebuilding this is OK, but for users reporting "x is not possible" a build-date in the compilation output would be nice. But "build date" is not good for individual compilations, so a "revision" would be better - which could be done with some hooks .

without hooks we might use such an approach (accepted solution):
http://stackoverflow.com/questions/3442874/in-git-how-can-i-write-the-current-commit-hash-to-a-file-in-the-same-commit

right below that answer is one which uses the "pre-commit"-hook.
Of course we could use it to increase a "counter" on each commit and to store a date of the commit. So at the end we manipulate a file which BCC includes (a revision/date-file).


Of course we do not need that at all, but it might help with the increasing amount of bug reports.


bye
Ron