Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
May 08, 2016 Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
In my struct I have some methods with these signatures: void opIndexAssign(T)(in GLColor!T color, in int x, in int y) void opIndexAssign(T1, T2)(in GLColor!T1 color, in Vector2!T2 vector) void opIndexAssign(in uint value, in int x, in int y) And when I try to do this: thing[2, 2] = GLColor!float(1, 1, 1); I get a compiler error like so: E:\Dropbox\Projects\d\mach\sdl\surface.d(434): Error: none of the overloads of 'opIndexAssign' are callable using argument types (GLColor!float, int, int), candidates are: E:\Dropbox\Projects\d\mach\sdl\surface.d(406): mach.sdl.surface.Surface.opIndexAssign(const(uint) value, const(int) x, const(int) y) Meaning the overloads using GLColor are apparently silently ignored? I had the same problem with another method. Here are my overloads: void fill(in uint color) void fill(T)(in GLColor!T color) void fill(in ubyte r, in ubyte g, in ubyte b, in ubyte a = 255) void fill(in Box!int box, in uint color) void fill(T)(in Box!int box, in GLColor!T color) void fill(in Box!int box, in ubyte r, in ubyte g, in ubyte b, in ubyte a = 255) void fill(in SDL_Rect* rect, in uint color) And when I try to do this: thing.fill(GLColor!float(1, 1, 1)); I get another compiler error: E:\Dropbox\Projects\d\mach\sdl\surface.d(429): Error: none of the overloads of 'fill' are callable using argument types (GLColor!float), candidates are: E:\Dropbox\Projects\d\mach\sdl\surface.d(179): mach.sdl.surface.Surface.fill(const(uint) color) E:\Dropbox\Projects\d\mach\sdl\surface.d(187): mach.sdl.surface.Surface.fill(const(ubyte) r, const(ubyte) g, const(ubyte) b, const(ubyte) a = cast(ubyte)255u) E:\Dropbox\Projects\d\mach\sdl\surface.d(191): mach.sdl.surface.Surface.fill(const(Box!int) box, const(uint) color) E:\Dropbox\Projects\d\mach\sdl\surface.d(199): mach.sdl.surface.Surface.fill(const(Box!int) box, const(ubyte) r, const(ubyte) g, const(ubyte) b, const(ubyte) a = cast(ubyte)255u) E:\Dropbox\Projects\d\mach\sdl\surface.d(203): mach.sdl.surface.Surface.fill(const(SDL_Rect*) rect, const(uint) color) The module containing the GLColor struct is definitely imported correctly, and I don't see how this could be an issue with the GLColor since its (admittedly meager) unittests all pass. What am I missing? |
May 09, 2016 Re: Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
Posted in reply to pineapple | On Sunday, 8 May 2016 at 13:28:47 UTC, pineapple wrote:
> [...]
> I get a compiler error like so:
>
> E:\Dropbox\Projects\d\mach\sdl\surface.d(434): Error: none of the overloads of 'opIndexAssign' are callable using argument types (GLColor!float, int, int), candidates are:
> E:\Dropbox\Projects\d\mach\sdl\surface.d(406): mach.sdl.surface.Surface.opIndexAssign(const(uint) value, const(int) x, const(int) y)
>
> Meaning the overloads using GLColor are apparently silently ignored?
No they are not ignored, otherwise the following would not compile:
----
struct GLColor(T){T t0,t1,t2;}
struct Thing
{
void opIndexAssign(T)(in GLColor!T color, in int x, in int y){}
void opIndexAssign(T1, T2)(in GLColor!T1 color, in Vector2!T2 vector){}
void opIndexAssign(in uint value, in int x, in int y){}
}
void main(string[] args)
{
Thing thing;
thing[2,2] = GLColor!float(1, 1, 1);
}
----
Can you show your GLColor struct ? Maybe it contains an alias this or something else that mess the overload resolution.
|
May 09, 2016 Re: Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Häggman | On Monday, 9 May 2016 at 00:27:17 UTC, Peter Häggman wrote: > Can you show your GLColor struct ? Maybe it contains an alias this or something else that mess the overload resolution. My GLColor struct: http://pastebin.com/mUcA6G85 |
May 09, 2016 Re: Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
Posted in reply to pineapple | On Monday, 9 May 2016 at 11:22:37 UTC, pineapple wrote:
> On Monday, 9 May 2016 at 00:27:17 UTC, Peter Häggman wrote:
>> Can you show your GLColor struct ? Maybe it contains an alias this or something else that mess the overload resolution.
>
> My GLColor struct: http://pastebin.com/mUcA6G85
No problem here (tested with everything in a single module). I can't help more.
Front end version ?
|
May 10, 2016 Re: Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Häggman | On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote: > No problem here (tested with everything in a single module). I can't help more. > Front end version ? Well, this is the full struct that has those malfeasant overrides: http://pastebin.com/9h2s028J |
May 10, 2016 Re: Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
Posted in reply to pineapple | On Tuesday, 10 May 2016 at 09:57:11 UTC, pineapple wrote:
> On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote:
>> No problem here (tested with everything in a single module). I can't help more.
>> Front end version ?
>
> Well, this is the full struct that has those malfeasant overrides: http://pastebin.com/9h2s028J
I found the problem -
It turns out I was importing that glcolor module at both the top of the file and in a version(unittest) block. I'm not sure _why_ that broke things, but removing the redundant unittest import fixed my problem.
|
May 11, 2016 Re: Compiler silently ignores some method overloads | ||||
---|---|---|---|---|
| ||||
Posted in reply to pineapple | On Tuesday, 10 May 2016 at 22:17:00 UTC, pineapple wrote: > On Tuesday, 10 May 2016 at 09:57:11 UTC, pineapple wrote: >> On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote: >>> No problem here (tested with everything in a single module). I can't help more. >>> Front end version ? >> >> Well, this is the full struct that has those malfeasant overrides: http://pastebin.com/9h2s028J > > I found the problem - > > It turns out I was importing that glcolor module at both the top of the file and in a version(unittest) block. I'm not sure _why_ that broke things, but removing the redundant unittest import fixed my problem. This looks like a bug. Please report it at https://issues.dlang.org/ , if possible with a minimal example, thanks! |
Copyright © 1999-2021 by the D Language Foundation