Comment #0 by bearophile_hugs — 2012-01-19T11:23:32Z
In DMD 2.058head std.string.rjustify is deprecated, so this program:
import std.string;
void main() {
rjustify!string("hello", 10);
}
Gives the correct error message:
test.d(3): Error: function std.string.rjustify!(string).rjustify is deprecated
But this program gives no deprecated errors:
import std.string;
void main() {
auto J = &rjustify!string;
J("hello", 10);
}
(In reply to comment #2)
The fix from pull #670 gets confused when there are "undeprecated" overloads; for example, here are several ways that a deprecated function can still be called through a function pointer:
int foo(int a) { return 0; }
deprecated int foo(float a) { return 1; }
void main()
{
int function(float) fp1 = &foo;
auto fp2 = cast(int function(float))&foo;
assert(fp1(0.0) == 1);
assert(fp2(0.0) == 1);
}
If foo(int) instead of foo(float) is deprecated, then an error is issued even though it should be possible to take the address of the undeprecated function.
(I've been having similar problems trying to fix issue 144; in these situtations, I think AddrExp::semantic is too early in the compilation process for applying fixes that may be affected by overload resolution.)
Comment #4 by k.hara.pg — 2012-07-19T08:57:10Z
(In reply to comment #3)
> If foo(int) instead of foo(float) is deprecated, then an error is issued even
> though it should be possible to take the address of the undeprecated function.
>
> (I've been having similar problems trying to fix issue 144; in these
> situtations, I think AddrExp::semantic is too early in the compilation process
> for applying fixes that may be affected by overload resolution.)
An example that accidentally rejected with current git head:
deprecated int foo(float a) { return 1; }
int foo(int a) { return 0; }
void main()
{
int function(float) fp1 = &foo;
// test.d(10): Error: function test.foo is deprecated <- Bad!
}
Comment #5 by github-bugzilla — 2012-07-19T09:00:18Z
The deprecation check needs to be done where the overload set is resolved, wherever that is.
Comment #7 by k.hara.pg — 2012-07-19T09:37:43Z
(In reply to comment #6)
> The deprecation check needs to be done where the overload set is resolved,
> wherever that is.
DotVarExp and VarExp have `hasOverloads` field that means whether the overloaded symbol is really resolved or not.
In these cases, CastExp::semantic and AddrExp::implicitConvTo might be better places.