spcomp exits with no output for methodmap static function call

[geominorai]

Help us help you

• I have checked that my issue doesn't exist yet.
• I have tried my absolute best to reduce the problem-space and have provided the absolute smallest test-case possible.
• I can always reproduce the issue with the provided description below.

Environment

• Operating System version: Windows
• Current SourceMod version: 1.9.0.6252
• Current SourceMod snapshot: 1.10.6339

• I have updated SourceMod to the latest version and it still happens.
• I have updated SourceMod to the latest snapshot and it still happens.

Description

Compiler exits prematurely with no errors or messages.

Problematic Code (or Steps to Reproduce)

methodmap B {
  public static void TestB() {
  	A.TestA();
  	PrintToServer("TestB");
  }
}

methodmap A {
  public static void TestA() {
  	PrintToServer("TestA");
  }
}

Logs

Output from Sublime:
[Finished in 0.9s with exit code 3221225477]
or
[Finished in 0.8s]

Output from spcomp:

[Fyren]

You can't forward declare (or use) methodmaps currently. In the future, run spcomp yourself if you have a problem like this because there is output, Sublime is just not showing it to you (though the output is hitting an assert).

[geominorai]

Aye, running spcomp just gives me:

Copyright (c) 1997-2006 ITB CompuPhase
Copyright (c) 2004-2017 AlliedModders LLC

and running compile gives me:

//SourceMod Batch Compiler
// by the SourceMod Dev Team


//// spcomp_methodmap_bug.sp
// Internal error.

[Fyren]

Oh, the asserts only show with debug builds, of course. It will just crash in release builds.

The short term fix in SP for this is only to show an error saying methodmap A is yet undefined. Switch the order, unless you need them both to refer to each other.

[dvander]

I have this on my todo list, but it is a bit tricky. In the first pass, any identifier that has not been seen is assumed to be a function. It's a reasonable assumption because functions aren't ordered, whereas variable declarations are. However this means the A in A.TestA() is producing a function symbol, and when methodmap A { is parsed, it gets confused that there are two symbols for A.

The quick fix to kill the assert would be to reject the methodmap if the symbol is already defined as a function or variable.

A proper fix would be to implement support for out-of-order methodmaps. Instead of calling fetchfunc() in primary(), I would create a new iPLACEHOLDER symbol type, and allow transitions from iPLACEHOLDER to iFUNCTN or iMETHODMAP.

I'll probably do the quick fix first just in case the proper fix doesn't work out.

[dvander]

I can't reproduce this on master - I get an error message instead of a crash or assert. Properly supporting this kind of declaration will be a future thing.