• Martin Nowak (5/5) Mar 30 2016 Second beta for the 2.071.0 release.
• Basile B. (3/8) Mar 30 2016 Two regressions found in previous beta are now fixed. Otherwise
• Basile B. (6/17) Mar 30 2016 Actually this morning I've setup and tested 2.070.2 instead of
• Guillaume Piolat (5/10) Mar 30 2016 Everything looks green:
• =?UTF-8?B?THXDrXM=?= Marques (3/8) Mar 30 2016 Who maintains the homebrew recipe? The --devel package is still
• John Colvin (3/14) Mar 30 2016 That would be me. Waiting for merge:
• =?UTF-8?B?THXDrXM=?= Marques (9/11) Mar 30 2016 Thanks!
• John Colvin (3/14) Mar 30 2016 I'm 99.9% certain the Homebrew core devs wouldn't allow something
• Jacob Carlborg (13/14) Mar 30 2016 I'm compiling my projects using the new beta. I get some errors about
• Jacob Carlborg (21/22) Mar 31 2016 I've found other confusing error messages. Compiling the following code:
• Steven Schveighoffer (7/27) Mar 31 2016 These sure seem like bugs (including your other post).
• Jacob Carlborg (5/10) Mar 31 2016 Yeah, deprecation messages.
• Steven Schveighoffer (6/9) Mar 31 2016 The compiler. Your first post has a deprecation indicating it found a
• Jacob Carlborg (5/9) Mar 31 2016 Both examples compile the same with and without -transition=import. The
• Steven Schveighoffer (5/12) Mar 31 2016 Right, so definitely a bug in the compiler. The -transition=checkimports...
• Jacob Carlborg (6/10) Mar 31 2016 Reported two bugs:
• tost (21/26) Apr 03 2016 //foo.d
• Rory McGuire via Digitalmars-d-announce (6/36) Apr 03 2016 I think compiler is supposed to stop you from doing that to protect agai...
• Steven Schveighoffer (8/37) Apr 04 2016 Yes. There are new lookup rules. See my post about it here:

Martin Nowak <code+news.digitalmars dawg.eu> writes:

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

Basile B. <b2.temp gmx.com> writes:

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

Two regressions found in previous beta are now fixed. Otherwise 
NAD.

Basile B. <b2.temp gmx.com> writes:

On Wednesday, 30 March 2016 at 12:04:19 UTC, Basile B. 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

 Two regressions found in previous beta are now fixed. Otherwise 
 NAD.

Actually this morning I've setup and tested 2.070.2 instead of 
the beta and now, with the right version, one of the regression 
is still there.
Unfortunately I was not able to make a good report:

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

Guillaume Piolat <contact gam3sfrommars.fr> writes:

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

Everything looks green:
https://travis-ci.org/d-gamedev-team/gfm
https://travis-ci.org/p0nce/dplug

Though I haven't tested release builds.

=?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:

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

Who maintains the homebrew recipe? The --devel package is still 
at beta 1.

John Colvin <john.loughran.colvin gmail.com> writes:

On Wednesday, 30 March 2016 at 13:04:08 UTC, Luís Marques 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

 Who maintains the homebrew recipe? The --devel package is still 
 at beta 1.

That would be me. Waiting for merge: 
https://github.com/Homebrew/homebrew/pull/50539

=?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:

On Wednesday, 30 March 2016 at 15:48:28 UTC, John Colvin wrote:
 That would be me. Waiting for merge: 
 https://github.com/Homebrew/homebrew/pull/50539

Thanks!

Would it be against the homebrew spirit for the DMD recipe to 
link to some URL like <...lastest-devel.tar.gz>? After all, that 
already happens with the --HEAD version, which doesn't link to 
any specific git commit. That way we wouldn't have to wait for 
the homebrew merges. There's the issue of the hash, but the 
--HEAD version doesn't have that either, and https://dlang.org 
should be trusted.

John Colvin <john.loughran.colvin gmail.com> writes:

On Wednesday, 30 March 2016 at 16:00:34 UTC, Luís Marques wrote:
 On Wednesday, 30 March 2016 at 15:48:28 UTC, John Colvin wrote:
 That would be me. Waiting for merge: 
 https://github.com/Homebrew/homebrew/pull/50539

 Thanks!

 Would it be against the homebrew spirit for the DMD recipe to 
 link to some URL like <...lastest-devel.tar.gz>? After all, 
 that already happens with the --HEAD version, which doesn't 
 link to any specific git commit. That way we wouldn't have to 
 wait for the homebrew merges. There's the issue of the hash, 
 but the --HEAD version doesn't have that either, and 
 https://dlang.org should be trusted.

I'm 99.9% certain the Homebrew core devs wouldn't allow something 
like that.

Jacob Carlborg <doob me.com> writes:

On 2016-03-30 13:03, Martin Nowak wrote:
 Second beta for the 2.071.0 release.

I'm compiling my projects using the new beta. I get some errors about 
the new import rules that I don't really understand:

clang/Type.d(114,24): Deprecation: local import search method found 
overloadset clang.Type.isEmpty instead of overloadset clang.Type.isEmpty

This is where it complains [1], "isEmpty" pulled in from here [2] and 
declared here [3].

[1] https://github.com/jacob-carlborg/dstep/blob/master/clang/Type.d#L114

[2] https://github.com/jacob-carlborg/dstep/blob/master/clang/Type.d#L9

[3] 
https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Array.d#L110

-- 
/Jacob Carlborg

Jacob Carlborg <doob me.com> writes:

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

-- 
/Jacob Carlborg

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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

tost <a b.cd> writes:

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 :)

Rory McGuire via Digitalmars-d-announce writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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