On 3/31/16 3:22 AM, Jacob Carlborg wrote:
> On 2016-03-30 13:03, Martin Nowak wrote:
>> Second beta for the 2.071.0 release.
>
> I've found other confusing error messages. Compiling the following code:
>
> class Foo
> {
>      import core.stdc.config;
>
>      struct Bar
>      {
>          c_long a, b; // line 7
>      }
> }
>
> With the -transition=checkimports flag gives the following error messages:
>
> main.d(1): Deprecation: class main.Foo alias core.stdc.config.c_long
> found in local import
> main.d(7): Deprecation: local import search method found nothing (null)
> instead of alias core.stdc.config.c_long
> main.d(1): Deprecation: class main.Foo alias core.stdc.config.c_long
> found in local import
> main.d(7): Deprecation: local import search method found nothing (null)
> instead of alias core.stdc.config.c_long
>

These sure seem like bugs (including your other post).

The repetition (in case you are wondering) is because the compiler prints a message for every usage of a symbol. In this case, you defined two symbols, so you get two deprecation messages.

Note these aren't error messages, you should still get a binary.

-Steve

On 2016-03-31 15:21, Steven Schveighoffer wrote:

> These sure seem like bugs (including your other post).

In my code or in the compiler?

> The repetition (in case you are wondering) is because the compiler
> prints a message for every usage of a symbol. In this case, you defined
> two symbols, so you get two deprecation messages.
>
> Note these aren't error messages, you should still get a binary.

Yeah, deprecation messages.

-- 
/Jacob Carlborg

On 3/31/16 10:29 AM, Jacob Carlborg wrote:
> On 2016-03-31 15:21, Steven Schveighoffer wrote:
>
>> These sure seem like bugs (including your other post).
>
> In my code or in the compiler?

The compiler. Your first post has a deprecation indicating it found a symbol twice in the same place :) The second seems like there should be no issues. I assume it compiles identically both with and without -transition=import? If that's the case, there should be no message.

-Steve

On 2016-03-31 16:59, Steven Schveighoffer wrote:
> The compiler. Your first post has a deprecation indicating it found a
> symbol twice in the same place :) The second seems like there should be
> no issues. I assume it compiles identically both with and without
> -transition=import? If that's the case, there should be no message.

Both examples compile the same with and without -transition=import. The issues only appear with the -transition=checkimports flag enabled.

-- 
/Jacob Carlborg

On 3/31/16 3:15 PM, Jacob Carlborg wrote:
> On 2016-03-31 16:59, Steven Schveighoffer wrote:
>> The compiler. Your first post has a deprecation indicating it found a
>> symbol twice in the same place :) The second seems like there should be
>> no issues. I assume it compiles identically both with and without
>> -transition=import? If that's the case, there should be no message.
>
> Both examples compile the same with and without -transition=import. The
> issues only appear with the -transition=checkimports flag enabled.
>

Right, so definitely a bug in the compiler. The -transition=checkimports flag is supposed to tell you about changes in behavior between the prior regime (achieved with -transition=import) and the current regime.

-Steve

On 2016-03-31 21:21, Steven Schveighoffer wrote:

> Right, so definitely a bug in the compiler. The -transition=checkimports
> flag is supposed to tell you about changes in behavior between the prior
> regime (achieved with -transition=import) and the current regime.
>
> -Steve

Reported two bugs:

https://issues.dlang.org/show_bug.cgi?id=15857
https://issues.dlang.org/show_bug.cgi?id=15856

-- 
/Jacob Carlborg

On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote:
> Second beta for the 2.071.0 release.
>
> http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html
>
> Please report any bugs at https://issues.dlang.org
>
> -Martin

//foo.d
module foo;

void main() {}

class A {

	void bar(int i) {}

	void baz() {
		import othermodule;
		bar("abc");
	}
}

// othermodule.d
module othermodule;

void bar(string s) {}

compiled with

dmd foo.d othermodule.d

gives

foo.d(11): Error: function foo.A.bar (int i) is not callable using argument types (string)

is this a feature of the new name lookup algorithm or a bug? Adapting my codebase would be trivial :)

On Sun, Apr 3, 2016 at 1:59 PM, tost via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote:
>
>> Second beta for the 2.071.0 release.
>>
>> http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.0.html
>>
>> Please report any bugs at https://issues.dlang.org
>>
>> -Martin
>>
>
> //foo.d
> module foo;
>
> void main() {}
>
> class A {
>
>         void bar(int i) {}
>
>         void baz() {
>                 import othermodule;
>                 bar("abc");
>         }
> }
>
> // othermodule.d
> module othermodule;
>
> void bar(string s) {}
>
> compiled with
>
> dmd foo.d othermodule.d
>
> gives
>
> foo.d(11): Error: function foo.A.bar (int i) is not callable using
> argument types (string)
>
> is this a feature of the new name lookup algorithm or a bug? Adapting my codebase would be trivial :)
>

I think compiler is supposed to stop you from doing that to protect against
hijacking.
http://dlang.org/hijack.html

R

On 4/3/16 7:59 AM, tost wrote:
> On Wednesday, 30 March 2016 at 11:03:51 UTC, Martin Nowak wrote:
>> Second beta for the 2.071.0 release.
>>
>> http://dlang.org/download.html#dmd_beta
>> http://dlang.org/changelog/2.071.0.html
>>
>> Please report any bugs at https://issues.dlang.org
>>
>> -Martin
>
> //foo.d
> module foo;
>
> void main() {}
>
> class A {
>
>      void bar(int i) {}
>
>      void baz() {
>          import othermodule;
>          bar("abc");
>      }
> }
>
> // othermodule.d
> module othermodule;
>
> void bar(string s) {}
>
> compiled with
>
> dmd foo.d othermodule.d
>
> gives
>
> foo.d(11): Error: function foo.A.bar (int i) is not callable using
> argument types (string)
>
> is this a feature of the new name lookup algorithm or a bug? Adapting my
> codebase would be trivial :)

Yes. There are new lookup rules. See my post about it here: http://www.schveiguy.com/blog/2016/03/import-changes-in-d-2-071/

To fix, you should import with selective:

import othermodule: bar;

If you need both bar(int) and bar(string) from their respective locations, I'd suggest a renaming import.

-Steve