Re: LDC 1.1.0-beta3 has been released!

[kink via Digitalmars-d-announce]

On Wednesday, 12 October 2016 at 09:31:20 UTC, Chris wrote:

I had this problem with `beta3` when compiling a vibe.d project.
[...]
I went back to `beta2` and it worked.


GitHub issues are much preferred over forum posts. For this 
particular one (breaking dub when outputting static libraries), 
we already have one: 
https://github.com/ldc-developers/ldc/issues/1819

Re: LDC 1.1.0-beta3 has been released!

[kink via Digitalmars-d-announce]

On Wednesday, 12 October 2016 at 08:28:59 UTC, Manu wrote:

How's the MS progress on PDB in LLVM?


Pretty good. See 
https://github.com/ldc-developers/ldc/issues/1716#issuecomment-252727032, there's a VS screenshot of the current state on Win64 with LLVM 3.9.

Re: LDC 1.1.0-beta3 has been released!

[Chris via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 07:29:00 UTC, Sönke Ludwig wrote:

Am 09.10.2016 um 14:32 schrieb Kai Nacke:

Hi everyone,

LDC 1.1.0-beta3, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.071.2 frontend and 
standard library

and supports LLVM 3.5-3.9.

We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, 
Linux/ARM

(armv7hf), now bundled with DUB. :-)

As usual, you can find links to the changelog and the binary 
packages

over at digitalmars.D.ldc:
http://forum.dlang.org/post/nbbocctpmaofpdxqm...@forum.dlang.org

Regards,
Kai



Just noticed that the release binaries are missing from 
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0-beta3


This means that the beta currently cannot be tested with 
TravisCI (wanted to test a DUB related regression fix).


I had this problem with `beta3` when compiling a vibe.d project.

Performing "release" build using /D/ldc2-1.1.0-beta3/bin/ldc2 for 
x86_64.


vibe-d:utils 0.7.30-rc.1: building configuration "library"...
Error: failed to create path to file: 
.dub/obj/../../.dub/packages/vibe-d-0.7.30-rc.1/vibe-d/.dub/build/library-release-linux.posix-x86_64-ldc_0-2530BD99F72930F46E92BF1D555FBB9A/libvibe-d_utils.a

No such file or directory

I went back to `beta2` and it worked.

Re: LDC 1.1.0-beta3 has been released!

[Manu via Digitalmars-d-announce]

On 11 October 2016 at 23:16, Kai Nacke via Digitalmars-d-announce
 wrote:
> On Tuesday, 11 October 2016 at 09:16:36 UTC, Johan Engelen wrote:
>>
>> On Tuesday, 11 October 2016 at 07:29:00 UTC, Sönke Ludwig wrote:
>>
>> Whoops, that's my bad :(
>> (I editted a little and clicked the "save draft" button which turned it
>> into a draft again, I think)
>
>
> :-) Unintentionally I did the same with the beta2 release.
>
> Regards,
> Kai

How's the MS progress on PDB in LLVM?

Re: Beta 2.072.0-b2

[Sönke Ludwig via Digitalmars-d-announce]

Am 10.10.2016 um 12:45 schrieb Sönke Ludwig:

Am 10.10.2016 um 12:20 schrieb Martin Nowak:

On Monday, 10 October 2016 at 09:03:53 UTC, Sönke Ludwig wrote:

Of course, the new error is more restrictive than it should be, namely
if the uninitialized pointer field gets written before the first read,
it would still be safe.


That's surprising b/c void initializers for struct fields didn't use to
work.


Hm, thanks for the hint - if that's still the case, that leads to the
very simple workaround of simply removing the "= void". Would have been
nice in theory to have real void initialization of course, plus it was
there for working around that (fixed?) issue with slow compilation times
for large static arrays, but there is probably no real reason now to
keep it.


I need to research the intent behind this to say sth. detailed, though
usually an shouldn't break working code, only deprecate it.




Okay, I stumbled over another occurrence of this:

Bugzilla 16195: delete should be @system
  <- This makes it impossible to use `scope` variables in @safe scopes. 
The whole scope/function needs to be marked trusted now.


Bugzilla 14496: void initialization of member with indirections must not 
be @safe
  <- This makes it impossible to use std.typecons.scoped as an 
alternative, because it requires void initialization due to its disabled 
default constructor, or it would again affect the @safety of the whole 
surrounding scope.


I think both need to be adjusted to use a deprecation warning instead of 
an error. But the first one in conjunction with `scope` variables should 
be legal anyway, as long as the variable doesn't leave the scope (e.g. 
DIP1000). Maybe it makes sense to lower this to "scope (exit) () 
@trusted { delete var; } ();" instead of "scope (exit) delete var;" for 
now (making sure that the stack allocation optimization still works).