AlliedModders - Compiler bug?

AlliedModders (https://forums.alliedmods.net/index.php)

- Scripting (https://forums.alliedmods.net/forumdisplay.php?f=107)

- - Compiler bug? (https://forums.alliedmods.net/showthread.php?t=91268)

Can someone confirm this is a compiler bug?

Code:

enum MyEnum

{

    Option1,

    Option2,

    Option3,

}



new MyArray[MyEnum];



MyFunction1(value)  // This function works and compiles fine.

{

    MyArray[Option1] = value;

}



MyFunction2(MyEnum:enum, value)  // I get a tag mismatch warning on 'MyArray' line.

{

    MyArray[enum] = value;

}

Is this simply a limitation of pawn, or is it a bug in the compiler?

EDIT:

Note that it the warning seems to be redundant, as the code works as expected.

Re: Compiler bug?

You're using "enum" as a variable name, when you shouldn't be doing that. Try using another name for it.

Re: Compiler bug?

Well in my actual source I don't name it that. Naming isn't the problem. I'v renamed all the variables to stuff like "blah" and random sequences of letters and the warning is still there.

Re: Compiler bug?

The code you pasted does not emit a warning if you change the variable "enum" to, for example, "e."

Re: Compiler bug?

Hm I never tested that code above, but it's happening in the plugin I'm working on. I think it may have something to do with it being in a different file. Maybe enum's can't be used outside of the file it's defined in?

It is structured like so:

myplugin.sp

Code:

#include <include1>

#include <include2>

include1.inc

Code:

enum MyEnum

{

    Option1,

    Option2,

    Option3,

}



new MyArray[MyEnum];

include2.inc

Code:

MyFunction2(MyEnum:option, value)  // I get a tag mismatch warning on 'MyArray' line.

{

    MyArray[option] = value;

}

EDIT: Actually adding the line:

Code:

PrintToServer("%x", _:option);

Works with no warnings.

Re: Compiler bug?

Creating three files as you just described does not emit a warning for me. If you actually want help with the warning, post your real files.

Re: Compiler bug?

Ok then,

zombiereloaded.sp

Code:

#pragma semicolon 1

#include <sourcemod>

#include <sdktools>

#include <cstrike>

#include <hacks>



#undef REQUIRE_PLUGIN

#include <market>



#define VERSION "3.0-dev"



// Core includes.

#include "zr/zombiereloaded"

#include "zr/cvars"

#include "zr/config"

// .. more irrelevant includes (to this problem)

cvars.inc

Code:

/**

 * List of cvars used by the plugin.

 */

enum CvarsList

{

    Handle:CVAR_CONFIG_PATH_1,

    Handle:CVAR_CONFIG_PATH_2,

    Handle:CVAR_CONFIG_PATH_3,

    Handle:CVAR_CONFIG_PATH_4,

    Handle:CVAR_CONFIG_PATH_5,

    Handle:CVAR_CONFIG_PATH_6,

    // Many more handles, but again, irrelevant.

}



/**

 * Array to store cvar data in.

 */

new g_hCvarsList[CvarsList];

config.inc

Code:

/**

 * Load config file.

 * 

 * @param file  The cvar define of the path to the file.

 * @return      True if the file exists, false if not.

 */

bool:ConfigGetFilePath(CvarsList:cvar, String:path[])

{

    // Get cvar's path.

    decl String:filepath[PLATFORM_MAX_PATH];

    GetConVarString(g_hCvarsList[cvar], filepath, sizeof(filepath));

    

    // Build full path in return string.

    BuildPath(Path_SM, path, PLATFORM_MAX_PATH, filepath);

    

    return FileExists(path);

}

Grr, I think I know why the code I posted earlier was working.

In my enum I have all my entries with the "Handle" datatype, and I define the array as an int array (which is fine), but it seems that all this time the compiler has been reading the datatypes of the enum entry and so all my direct calls to it (eg GetConVarBool(g_hCvarsList[CVAR_BLAH])) returned no error because 'CVAR_BLAH' was defined as a handle.

But in this case, I'm using a variable to pass that enum entry onto a function, so the compiler doesn't know the datatype of whats being passed into the function until it happens. I'm lucky in this case that all of my entries are handles, so to fx this i can just define g_hCvarsList as a handle and the warning goes away.

Thanks for the help. Just going through all the code and thinking about everything helped me realize the problem. Hope what I said made sense so no one else has this problem!

Thanks again,
Greyscale

EDIT: Actually putting a Handle: tag on the array in the ConfigGetFilePath function got rid of the error too. I think it's a better solution.

Re: Compiler bug?

If your array holds handles, you should declare it as "new Handle:g_hCvarsList[CvarsList]" instead of leaving it untagged or forcing the tag in the function. Tagging your enum values as handles shouldn't accomplish anything.

The following three files compile fine exactly as so:

test.sp

PHP Code:


		
			
#include <sourcemod>

#include "file1"

#include "file2"



public OnPluginStart()

{

        ConfigGetFilePath(CVAR_CONFIG_PATH_1, "");

}

file1.inc

PHP Code:


		
			
/**

 * List of cvars used by the plugin.

 */

enum CvarsList

{

           CVAR_CONFIG_PATH_1,

           CVAR_CONFIG_PATH_2,

           CVAR_CONFIG_PATH_3,

           CVAR_CONFIG_PATH_4,

           CVAR_CONFIG_PATH_5,

           CVAR_CONFIG_PATH_6,

           // Many more handles, but again, irrelevant.

}



/**

 * Array to store cvar data in.

 */

new Handle:g_hCvarsList[CvarsList];

file2.inc

PHP Code:


		
			
/**

 * Load config file.

 *

 * @param file  The cvar define of the path to the file.

 * @return      True if the file exists, false if not.

 */

bool:ConfigGetFilePath(CvarsList:cvar, String:path[])

{

        // Get cvar's path.

        decl String:filepath[PLATFORM_MAX_PATH];

        GetConVarString(g_hCvarsList[cvar], filepath, sizeof(filepath));



        // Build full path in return string.

        BuildPath(Path_SM, path, PLATFORM_MAX_PATH, filepath);



        return FileExists(path);

}

If the Handle tag is removed from the array declaration, a tag mismatch warning will be emitted.

Re: Compiler bug?

Your solution is partially correct Fyren.

Being able to tag individual enum members is quite useful and is at least partially supported by the compiler (though I'm not sure if this was intentional).

There's an amxx tutorial on using these to create pseudo-structs that I've used in the dynamic admin menu among others.

I'm not sure if this is a bug as such without knowing what the compiler was meant to support but you could file a bug report to get the error quietened since the compiler does generate the correct code.

Edit: Sorry the original tutorial doesn't bother with tagging but PM's post about 5 down mentions it.