Release D 2.108.0
Glad to announce D 2.108.0, ♥ to the 36 contributors. This release comes with 8 major changes and 36 fixed Bugzilla issues, including: - In the language, named arguments for functions have been implemented and documented. - In phobos, std.uni has been upgraded to Unicode 15.1.0. - In dub, the fetch command now supports multiple arguments, recursive fetch, and is project-aware. http://dlang.org/download.html http://dlang.org/changelog/2.108.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Re: Beta 2.108.0
The RC for 2.108 has been released, which includes the following changes from the initial beta: - Named Arguments is now implemented and documented as a new feature in this release. The beta supports the feature, but was left undocumented while some remaining issues were being fixed. - Hexstrings now implicitly convert to integer arrays. The beta had introduced support to allow casting to arrays only. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.108.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Beta 2.108.0
Glad to announce the first beta for the 2.108.0 release, ♥ to the 35 contributors. This release comes with 7 major changes and 48 fixed Bugzilla issues, including: - In the language, support has been added for Interpolated Expression Sequences. - In phobos, std.uni has been upgraded to Unicode 15.1.0. - In dub, the fetch command now supports multiple arguments, recursive fetch, and is project-aware. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.108.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.107.1
Glad to announce D 2.107.1, ♥ to the 6 contributors. http://dlang.org/download.html This point release fixes 15 issues over 2.107.0, see the changelog for more details. http://dlang.org/changelog/2.107.1.html -Iain on behalf of the Dlang Core Team
Re: Bug fixes for Mac OSX landing in 2.107.1
On Tuesday, 27 February 2024 at 06:08:51 UTC, Danilo wrote: On Monday, 26 February 2024 at 12:55:32 UTC, Iain Buclaw wrote: This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x. Will DMD still work with macOS 12.7.x and Xcode 14.2? The Mac Pro x64 (waste bin model) doesn‘t get any updates anymore, as it first came out in 2013. Yes, all issues reported by the Xcode 15 linker were subtle corruptions of the mach-o format that are (mostly) silently accepted by the Xcode 14 and older linkers. MacOS 10.7 remains to be the absolute minimum version supported due to the requirement of native TLS. This'll only be bumped to 10.8/10.9 when coalesced sections get dropped (https://issues.dlang.org/show_bug.cgi?id=22464).
Bug fixes for Mac OSX landing in 2.107.1
Hi, Over the last 2-3 years, there's been a slow build-up of issues on MacOS that have now come home to roost, and they could no longer be ignored/worked arounded in CI as GHA has made Xcode 15.0.1 the default SDK since ~end of January/February 2024. **RESOLVED**: Linker errors - [ld: symbol count from symbol table and dynamic symbol table differ](https://github.com/dlang/dmd/pull/16221) This was caused by off-by-one mismatch in codegen symbol counters for the two tables. - [ld: unaligned pointer(s) for architecture x86_64](https://github.com/dlang/dmd/pull/16224) / warning: alignment (1) of atom 'anon' is too small and may result in unaligned pointers / warning: pointer not aligned at address This was caused by DMD forcing `__debug_line` sections to be emitted into the final executable to work around lack of backtrace support on OSX. This section now has the _correct_ flags assigned to it so it gets discarded at link-time - see notes on BREAKING changes. - [ld: GOT load reloc does not point to a movq instruction](https://github.com/dlang/dmd/pull/16227) Sometimes it was only seen with `dmd -O`, sometimes caused by `long * int` expressions. The underlying cause was symbol references being emitted as `X86_64_RELOC_GOT_LOAD` in the relocation table, but the instruction that accessed the symbol wasn't `MOVQ`. - [ld: address=0x0 points to section(2) with no content](https://github.com/dlang/dmd/pull/16222) This was triggered by g/shared array instantiated from a template and initialized with `[]` - such as the the variable `string[] rt_options = []` in D runtime - its empty initializer was being written to a data section that expected non-empty data. **RESOLVED**: Linker warnings - [ld: warning: pointer not aligned at __OBJC_PROTOCOL_$](https://github.com/dlang/dmd/pull/16219) This was caused by `extern(Objective-C)` functions and/or variables being emitted as `align(3)`. - [ld: warning: no platform load command found, assuming: macOS](https://github.com/dlang/dmd/pull/16223) This was caused by a missing `LC_BUILD_VERSION` command in all compiled modules. Jacob Carlborg did [the hard work years ago](https://github.com/dlang/dmd/pull/10476) to add support. Instead though a simplified version was committed that didn't include support for embedding CoreFoundation/framework/SDK version information in compiled objects - it wasn't necessary to fix the issue, and the linker fills in all SDK information for us anyway. **WONTFIX**: Workarounds - [ld: Assertion failed: (slot < _sideTableBuffer.size())](https://github.com/dlang/dmd/pull/16240) / ld: Assertion failed: (resultIndex < sectData.atoms.size()) Whilst the cause is unknown, the trigger is by using DMD with Xcode 15.0.1. The assumption is that the linker supplied with Xcode 15.0.1 is unstable/buggy as code generated by GCC/G++/G... also triggered this assertion. The confirmed fix is to upgrade to at least **Xcode 15.1** / CommandLineTools for Xcode 15.1. **CHANGES**: - **BREAKING**: File/line information is no longer embedded into the executable via `__debug_line` section. On developer machines, backtraces will still work as expected as D runtime supports getting this information instead via the `atos` command. Someone with a vested interest should look into adding `.dSYM` support to D runtime. (https://issues.dlang.org/show_bug.cgi?id=20510) - Setting `MACOSX_DEPLOYMENT_TARGET` now results in its value being embedded into all compiled objects for macOS. An invalid setting will result in a compile-time error. - As a result of all the above issues, it is impossible to build anything with DMD when using Xcode 15. The interim workaround to build DMD itself is to use LDC as the host compiler. This will be resolved as soon as 2.107.1 is released. This implies that the **minimum required version of DMD** to build on Mac OSX 13+ will be 2.107.1 / 2.108.x. If there's interest in making an RC release ahead of 1st March so MacOS/x86 users can do any last minute checking, now would be the time to know. There's been no testing on any real world project. Iain.
Re: real.sizeof
On Monday, 5 February 2024 at 16:45:03 UTC, Dom DiSc wrote: Why is real.sizeof == 16 on x86-systems?!? Its the IEEE 754 extended format: 64bit mantissa + 15bit exponent + sign. It should be size 10! I mean, alignment may be different, but why wasting so much memory even in arrays? Padding. x86 ABI prefers things to be aligned, so on x86 it's 12 bytes, x86_64 16 bytes. In both cases you don't get any extra precision over the 80-bits that x87 gives you.
Release D 2.107.0
Glad to announce D 2.107.0, ♥ to the 37 contributors. This release comes with 10 major changes and 61 fixed Bugzilla issues, including: - Unrecognized pragmas are no longer an error, but instead simply ignored. - Added `@core.attribute.standalone` for shared static module constructors. - In D runtime, a new module `core.stdc.stdatomic` has been implemented. http://dlang.org/download.html http://dlang.org/changelog/2.107.0.html -Iain on behalf of the Dlang Core Team
Beta 2.107.0
Glad to announce the first beta for the 2.107.0 release, ♥ to the 35 contributors. This release comes with 9 major changes and 52 fixed Bugzilla issues, including: - Unrecognized pragmas are no longer an error, but instead simply ignored. - Added `@core.attribute.standalone` for shared static module constructors. - In D runtime, a new module `core.stdc.stdatomic` has been implemented. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.107.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.106.1
Glad to announce D 2.106.1, ♥ to the 4 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.106.0, see the changelog for more details. http://dlang.org/changelog/2.106.1.html -Iain on behalf of the Dlang Core Team
Release D 2.106.0
Glad to announce D 2.106.0, ♥ to the 33 contributors. This release comes with... - In the D language, it is now possible to statically initialize AAs. - In dmd, there's a new `-nothrow` CLI flag. - In dub, `dub init` now has a select menu for package format and license. As always, you can find the release binaries and full changelog on the dlang.org site. http://dlang.org/download.html http://dlang.org/changelog/2.106.0.html -Iain on behalf of the Dlang Core Team
Re: First Beta 2.106.0
On Friday, 3 November 2023 at 04:33:12 UTC, Andrej Mitrovic wrote: On Thursday, 2 November 2023 at 09:13:55 UTC, Iain Buclaw wrote: On Thursday, 2 November 2023 at 07:49:32 UTC, Imperatorn wrote: Why is it named nothrow if what it's really doing is not adding the unwinders? A nothrow switch could imply it's doing something in relationship to nothrow, which it doesn't (unless it's secretly enforcing nothrow in the codebase). `-nothrow` is equivalent to putting `nothrow:` at the top of every compiled module. That kind of goes against what it says in the changelog: Recursively adding `nothrow:` was implied but I err towards brevity. And it also mentions: The switch does not affect semantic analysis But surely it has effect on semantics? I assume scope statements are disallowed if -nothrow is set and would lead to compilation errors? Right, statements that depend on exceptions as part of their operation can't possibly work because no unwind tables, eh regions, etc... are generated.
Re: First Beta 2.106.0
On Thursday, 2 November 2023 at 07:49:32 UTC, Imperatorn wrote: Why is it named nothrow if what it's really doing is not adding the unwinders? A nothrow switch could imply it's doing something in relationship to nothrow, which it doesn't (unless it's secretly enforcing nothrow in the codebase). `-nothrow` is equivalent to putting `nothrow:` at the top of every compiled module.
Re: First Beta 2.106.0
On Thursday, 2 November 2023 at 02:07:13 UTC, Andrej Mitrovic
wrote:
Does it also affect AAs in structs? For example:
```d
struct S
{
static int[int] x = [4:4];
}
```
Will this now work?
Yes, there are a few kinks that need ironing out though,
hopefully before the RC in a couple weeks.
One open PR
https://github.com/dlang/dmd/pull/15744
and another found issue
https://issues.dlang.org/show_bug.cgi?id=24209
First Beta 2.106.0
Glad to announce the first beta for the 2.106.0 release, ♥ to the 33 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.106.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.105.3
Glad to announce D 2.105.3, ♥ to the 4 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.105.3, see the changelog for more details. http://dlang.org/changelog/2.105.3.html -Iain on behalf of the Dlang Core Team
Re: Spec for the ‘locality’ parameter to the LDC and GDC builtin magic functions for accessing special CPU prefetch instructions
On Saturday, 19 August 2023 at 19:23:38 UTC, Cecil Ward wrote: I’m trying to write a cross-platform function that gives access to the CPU’s prefetch instructions such as x86 prefetch0/1/2/prefetchnta and AAarch64 too. I’ve found that the GDC and LDC compilers provide builtin magic functions for this, and are what I need. I am trying to put together a plain-English detailed spec for the respective builtin magic functions. My questions: Q1) I need to compare the spec for the GCC and LDC builtin magic functions’ "locality" parameter. Can anyone tell me if GDC and LDC have kept mutual compatibility here? I'd have thought GCC and LLVM have mutual compatibility thanks to a common target API in Intel's `_mm_prefetch()` function (and in fact, the magic locality numbers match `_MM_HINT_*` constants). ``` #define _MM_HINT_T0 1 #define _MM_HINT_T1 2 #define _MM_HINT_T2 3 #define _MM_HINT_NTA 0 ``` Q2) Could someone help me turn the GCC and LDC specs into english regarding the locality parameter ? - see (2) and (4) below. https://gcc.gnu.org/projects/prefetch.html Q3) Does the locality parameter determine which _level_ of the data cache hierarchy data is fetched into? Or is it always fetched into L1 data cache and the outer ones, and this parameter affects caches’ _future behaviour_? It really depends on the CPU, and what features it has. x86 SSE intrinsics are described in the x86 instruction manual, along with the meaning of T[012], and NTA. https://www.felixcloutier.com/x86/prefetchh Q3) Will these magic builtins work on AAarch64? It'll work on all targets that define a prefetch insn, or it'll be a no-op. Similarly one or both read-write or locality arguments might be ignored too.
DMD Beta 2.105.0
Glad to announce the first beta for the 2.105.0 release, ♥ to the 34 contributors. This release comes with 10 major changes, including: - In the compiler, assignment-style syntax is now allowed for `alias this`. - In the library, integration with the Valgrind memcheck tool has been added to the garbage collector. - In dub, there's a new `--d-versions` CLI flag. As always, you can find the release binaries and full changelog on the dlang.org site. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.105.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.104.0
Glad to announce D 2.104.0, ♥ to the 38 contributors. This release comes with 11 major changes, including: - In the compiler, User Defined Attributes now parse template arguments. - In the standard library, `std.typecons.Rebindable` now supports all types - In dub, new properties `cSourcePaths` and `cImportPaths` have been added to pass C sources and add additional search paths for C headers to the compiler. As always, you can find the release binaries and full changelog on the dlang.org site. http://dlang.org/download.html http://dlang.org/changelog/2.104.0.html -Iain on behalf of the Dlang Core Team
Re: Beta 2.104.0
On Tuesday, 2 May 2023 at 03:08:00 UTC, zjh wrote: On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. [104](https://dlang.org/changelog/2.104.0.html) ```d alias Tint = int; @Tint void f(); ``` Here says not to use basic types as attributes, but the following example give it another basic type? ```d @int void f(); ``` The keyword here in the changelog is: **would**; that is to say, the compiler previously rejected basic types, but now they are accepted. It was already allowed to put types in UDAs, but the parser would reject basic types written directly, requiring the use of an alias. I'll have a think about how that entry could be rephrased to avoid confusion, though you are welcome to raise your own pull request to clarify the wording.
Beta 2.104.0
Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. This release comes with 11 major changes, including: - In the compiler, User Defined Attributes now parse template arguments. - In the standard library, `std.typecons.Rebindable` now supports all types - In dub, new properties `cSourcePaths` and `cImportPaths` have been added to pass C sources and add additional search paths for C headers to the compiler. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.104.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.103.1
Glad to announce D 2.103.1, ♥ to the 5 contributors. http://dlang.org/download.html This point release includes three regression fixes, and three bug fixes over 2.103.0, see the changelog for more details. http://dlang.org/changelog/2.103.1.html -Iain on behalf of the Dlang Core Team
Re: Release D 2.103.0
On Monday, 3 April 2023 at 17:56:25 UTC, jmh530 wrote: The changelog doesn't list the fix to log1p https://github.com/dlang/phobos/pull/8712 Was there a bugzilla issue for it? Must have been missed.
Release D 2.103.0
Glad to announce D 2.103.0, ♥ to the 43 contributors. This release comes with 9 major changes, including: - In the compiler, `-preview=dip25` is now enabled by default. - In the standard library, std.uni Grapheme functions have been updated to conform to Unicode 15 - In dub, the `--color` argument now accepts the values `auto`, `never`, and `always`. http://dlang.org/download.html http://dlang.org/changelog/2.103.0.html -Iain on behalf of the Dlang Core Team
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 14:40:04 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.103.0 release The release candidate for 2.103.0 is now available, which has 11 bug fixes since the initial beta release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.103.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Beta 2.103.0
Glad to announce the first beta for the 2.103.0 release, ♥ to the 43 contributors. This release comes with 9 major changes, including: - In the compiler, `-preview=dip25` is now enabled by default. - In the standard library, std.uni Grapheme functions have been updated to conform to Unicode 15 - In dub, the `--color` argument now accepts the values `auto`, `never`, and `always`. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.103.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.102.2
Glad to announce D 2.102.2, ♥ to the 8 contributors. This is the last point release for 2.102 series, and the beta for 2.103 will be released shortly. http://dlang.org/download.html This point release fixes a few issues over 2.102.1, see the changelog for more details. http://dlang.org/changelog/2.102.2.html -Iain on behalf of the Dlang Core Team
Re: Release D 2.102.0
Glad to announce D 2.102.1, ♥ to the 6 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.102.0, see the changelog for more details. http://dlang.org/changelog/2.102.1.html -Iain on behalf of the Dlang Core Team
Re: Release D 2.102.0
On Sunday, 5 February 2023 at 01:59:47 UTC, Andrej Mitrovic wrote: On Thursday, 2 February 2023 at 12:30:50 UTC, Iain Buclaw wrote: http://dlang.org/download.html Seems there's problems with the installer script: https://issues.dlang.org/show_bug.cgi?id=23671 Indeed, it's not downloading the *new* version of https://dlang.org/d-keyring.gpg As a workaround remove ~/dlang/d-keyring.gpg and try again.
Re: Release D 2.102.0
Glad to announce the first beta for the 2.102.1 point release, ♥ to the 6 contributors. This fixes two breaking regressions found in dub 1.31.0 after the initial release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.102.1.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 17:22:46 UTC, Ali Çehreli wrote: I am aware how complex unicode collation is[1] but I somehow find it very wrong to list Ömer at the end. :) [...] > Steven Schveighoffer > Vladimir Panteleev > Walter Bright > Ömer Faruk IRMAK Obviously because I am used to the Turkish alphabet but in any case because Ö is very much related to O, I find it universally better to list Ö right after O. (The same should be for all latin based characters.) I see there is std.uni.icmp which uses dmd/std/internal/unicode_tables.d but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters. You are more than welcome to raise a PR to fix the sort. :-) https://github.com/dlang/tools/blob/master/contributors.d#L107-L113
Release D 2.102.0
Glad to announce D 2.102.0, ♥ to the 40 contributors. This release comes with support for multiple message arguments in `static assert()`, stack allocated `scope` array literals, a new preview switch to add support for `@system` variables, and many more. Downloads and full changelog are available from the dlang site. http://dlang.org/download.html http://dlang.org/changelog/2.102.0.html -Iain on behalf of the Dlang Core Team
Re: GDC documentation is online and 13.x development updates.
On Sunday, 15 January 2023 at 19:00:50 UTC, Johan wrote: On Tuesday, 6 December 2022 at 12:13:59 UTC, Iain Buclaw wrote: Hi, There is now (long overdue) expanded documentation of the user-facing features of GDC online on GCC's documentation site. https://gcc.gnu.org/onlinedocs/gdc/ Just now, I had trouble finding this. I don't think there is a pointer on GDC's own website? (https://gdcproject.org/) Hi Johan, Good point, I really need to give a bit more TLC to the site repository.
Re: Beta 2.102.0
On Sunday, 1 January 2023 at 10:10:07 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.102.0 release, ♥ to the 37 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.102.0.html The release candidate for the 2.102.0 release is now out.
Re: Release D 2.101.2
On Monday, 2 January 2023 at 18:30:38 UTC, Mike Bierlee wrote: The Windows installer download link is broken on the main page: https://downloads.dlang.org/releases/2022/dmd-2.101.2.exe Still says 2022. I have no idea why its using year-based links to the releases. I've changed that to version-based here https://github.com/dlang/dlang.org/pull/3484
Beta 2.102.0
Glad to announce the first beta for the 2.102.0 release, ♥ to the 37 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.102.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team
Release D 2.101.2
Glad to announce D 2.101.2, ♥ to the 3 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.101.1, see the changelog for more details. http://dlang.org/changelog/2.101.2.html -Iain on behalf of the Dlang Core Team
Re: Release D 2.101.0
On Tuesday, 27 December 2022 at 19:22:41 UTC, Les De Ridder wrote:
I've been able to reduce it to this:
`void f() { import std.file : exists; exists(""); }`
(or `void f() { import std; exists(""); }`)
Create two files (`a.d` and `b.d`) with this code.
Build with: `dmd.exe -m32 -inline -O a.d b.d`
Removing any of the flags allows the compilation to proceed.
1. Raise a bug report
2. Use digger to bisect dmd and locate which change introduced it.
Release D 2.101.1
Glad to announce D 2.101.1, ♥ to the 11 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.101.0, see the changelog for more details. http://dlang.org/changelog/2.101.1.html -Iain on behalf of the Dlang Core Team
GDC documentation is online and 13.x development updates.
Hi, There is now (long overdue) expanded documentation of the user-facing features of GDC online on GCC's documentation site. https://gcc.gnu.org/onlinedocs/gdc/ (also in [PDF](https://gcc.gnu.org/onlinedocs/gdc.pdf) or [PostScript](https://gcc.gnu.org/onlinedocs/gdc.ps.gz) or an [HTML tarball](https://gcc.gnu.org/onlinedocs/gdc-html.tar.gz)) The GDC options documentation has been around since the start. What's new is the language reference section, covering code generation choices specific to GDC - what attributes are supported, intrinsics, pragmas, predefined versions, language extensions, missing features and deviations from spec, ... More could be added or elaborated upon, such as what linkage do different symbols get, mixed language programming with C and C++, the anatomy of a TypeInfo and ModuleInfo object, and so on. This is enough as a first revision just to get it off the ground. Being a first revision, expect some grammar mistakes, and unclear use of language in some parts throughout. If any curious reader spots any such mistakes, or thinks there needs to be more clarity in some phrase or paragraph, you can either [raise a bugzilla issue against GDC](https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc=d=13.0) or name and shame me here. Meanwhile GDC-13 development is still tracking DMD's mainline branch, no plans to switch to a stable D2 release just yet. DMD releases will resume a predictable cadence in the New Year, starting with the 2.102-beta release in January, meaning 2.102-final in February. So the expected D2 version GDC-13 would be using is v2.103.1 by the time our May release comes around. Regards, Iain.
Re: D demangler for C++
On Monday, 28 November 2022 at 16:16:43 UTC, Witold Baryluk wrote: On Monday, 28 November 2022 at 12:48:15 UTC, max haughton wrote: Wouldn't some of those tools already have one via libiberty? https://github.com/gcc-mirror/gcc/blob/master/libiberty/d-demangle.c `libiberty` has way more things than just D demangler. And some projects might not be comfortable with its licensing. And libiberty uses autoconf / automake, which is just gross for most people. The idea is to have something simpler, portable (zero conf), just for this task, so it is as easy as possible to integrate and have flexible licensing. Many of the tools do not use libiberty, but just call `abi::__cxa_demangle` for example. Take a look for for a heaptrack tool: https://github.com/KDE/heaptrack/blob/master/src/interpret/heaptrack_interpret.cpp#L40-L56 You are free to use `libiberty` if you want. My demangler is just another option. As the author, you're free to re-license that file as whatever so long as you email me for permission. A clean-room implementation would likely be better though - libibert/d-demangle.c comes with backwards compatibility baggage that anyone implementing a tool/library today would not be interested in.
Re: Release D 2.101.0
On Thursday, 17 November 2022 at 02:35:14 UTC, jmh530 wrote: I'm not sure what the typically gets picked up, but I had done the search at the link below: https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Amerged+ImportC+ and it didn't look like any of the recent bug fixes were listed on the changelog (I only see 23123 and 23340). So for instance: https://github.com/dlang/dmd/pull/14528 https://github.com/dlang/dmd/pull/14509 https://github.com/dlang/dmd/pull/14508 https://github.com/dlang/dmd/pull/14490 https://github.com/dlang/dmd/pull/14485 https://github.com/dlang/dmd/pull/14481 https://github.com/dlang/dmd/pull/14480 I've just ran `rdmd -version=Contributors_Lib changed v2.100.2..v2.101.0` with my [hacked version of tools/changed.d](https://forum.dlang.org/post/jhmjyccxjxfrnboea...@forum.dlang.org), and all of a sudden I get "209 fixed Bugzilla issues" from "72 contributors". My faith in git log retrieving correct information has plummeted. :-) I'll push the fixed generated list into dlang.org, thankfully we'll never have to deal with this again (unless - queue dramatic three-beat sting - phobos is merged into dmd/druntime too).
Re: Release D 2.101.0
On Wednesday, 16 November 2022 at 20:51:19 UTC, jmh530 wrote: Thanks again, but it doesn't look like the changelog is picking up everything. It really would help if you provide some bugzilla urls or PRs that you think should have been picked up. Granted, I'm not sure exactly when the deadline is, but I see a whole bunch of PRs merged from Walter on ImportC on the Github repo, but only one ImportC item listed in the changelog under DMD compiler fixes (and that looks like this is actually a druntime PR). The one after that seems to be a phobos bug fix. Freeze was on 11th October.
Release D 2.101.0
Glad to announce D 2.101.0, ♥ to the 63 contributors. This release comes with shortened method syntax enabled by default, new bit-field support added as a preview feature, a new `std.typecons.SafeRefCounted` type that can be used in `@safe`, numerous improvements to dub (including colorized output), and many more. http://dlang.org/download.html http://dlang.org/changelog/2.101.0.html -Iain on behalf of the Dlang Core Team
Re: Release D 2.100.2
On Friday, 4 November 2022 at 12:39:04 UTC, Guillaume Piolat wrote: On Friday, 4 November 2022 at 02:44:57 UTC, Iain Buclaw wrote: On Tuesday, 1 November 2022 at 21:56:39 UTC, Ruby The Roobster wrote: On Tuesday, 1 November 2022 at 19:57:11 UTC, JN wrote: Windows is showing SmartScreen warnings when trying to run the Windows installer. Also, the installed version reports as v2.100.2-dirty. The next few releases are unsigned as those with the keys cannot be contacted (or, that's from what I've heard.) Code signing certs have been expired for nearly two years now, and are no longer functional. It is not yet decided what this should be replaced with, granted that buying a cert now is both eye-wateringly more expensive compared to 2016, and appears to force you to have some form of 2FA - be it hardware token or cloud signing platform. Last time I had to do this: Basically you have Certum.pl which provides cloud-signing, this company responds quickly, getting a individual OV certificate takes about 2-3 days. "cloud" signing with needs a phone token, a phone app SimplySign, that last 15 minutes or so. If this can be distributed between a group of people - let's say six or more - that might be OK, but not exactly as seamless as, say, just trigger a GitHub runner pipeline an walk away. On the other hand, .p12/.pfx vendors are almost entirely COMODO/Sectigo now, it works offline, getting a certificate is more painful with them and will require a hardware token even for OV beginning this month. 0. It's less hassle not to do anything, but well we could have a supply-chain attack one day. 1. If cloud/simplysign workflow is OK, Certum may be less hassle. 2. Possibly safer / less problems in build to just get the EV from Sectigo in a hardware token. Especially if you commit the secret in CI. Since November signing will require hardware token or private key in cloud (2FA). What does in a hardware token mean for us? Is it required to have it to hand every time we have to sign a beta, rc, final release binary? Does it bound us to a specific OS because of locked in proprietary tools? In what way would it hamper the ability to sign built binaries on a virtual machine, in a remote server, behind a read-only console UI?
Re: Release D 2.100.2
On Tuesday, 1 November 2022 at 21:56:39 UTC, Ruby The Roobster wrote: On Tuesday, 1 November 2022 at 19:57:11 UTC, JN wrote: Windows is showing SmartScreen warnings when trying to run the Windows installer. Also, the installed version reports as v2.100.2-dirty. The next few releases are unsigned as those with the keys cannot be contacted (or, that's from what I've heard.) Code signing certs have been expired for nearly two years now, and are no longer functional. It is not yet decided what this should be replaced with, granted that buying a cert now is both eye-wateringly more expensive compared to 2016, and appears to force you to have some form of 2FA - be it hardware token or cloud signing platform.
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On Wednesday, 2 November 2022 at 04:42:06 UTC, Mike Parker wrote: ## Iain For the benefit of the industry folks who only join us in the quarterlies, Iain recapped some of the things he'd covered in the two previous monthly meetings, such as the move to Backblaze for downloads.dlang.org and docharchives.dlang.io, the transition to Cloudflare that gives us the benefit of free data transfer with Backblaze, and the general tidying up of the dlang.io namespace. He then said that Martin Nowak will not be doing any more releases of the D language. Iain had been going through the build scripts that we currently have and figuring out what needs to be done to tailor them to run in GitHub Actions. It was taking much longer than he had anticipated. In the interim, he thought he could at least merge master into stable and get some 2.101.0 alpha builds set up by hand. (He then [announced the first beta on October 17](https://forum.dlang.org/thread/etvlqbomriskyeihz...@forum.dlang.org).) The release candidate is out now! https://dlang.org/download.html We plan to do v2.101.0 release on the 14th November. Next, he gave us a summary of his experience at the GNU Cauldron where he attended a meetup of GCC/GDB maintainers. He reported that there are some really interesting things going on with GCC internals regarding the direction in which they're taking the compiler, including several things we're doing already. For example, they're adding options to automatically initialize all static variables to 0 or a bitmask. This sort of thing is good news for him, as he currently has to do all the memsets by hand in GDC. It's a win if the middle-end can do this for him. If you're interested in all the GCC internal changes that Iain was gushing about and how he can benefit from them in GDC, please ask him :-) Correction, initialize all *local* variables. This new feature of GCC was added to increase the security and predictability of a program by preventing uninitialized memory disclosure and use. This really shifts the dynamics between front-end (language implementation) and middle-end (compiler framework), because now, if GCC fails to zero out all bits in an object, it's no longer a GDC bug, rather a GCC security issue. :-)
Re: Beta 2.101.0
On Monday, 17 October 2022 at 11:35:22 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.101.0 release, ♥ to the 299 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.101.0.html Release Candidate is live now. As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team.
Re: Beta 2.101.0
On Tuesday, 18 October 2022 at 22:04:50 UTC, Anonymouse wrote: On Monday, 17 October 2022 at 11:35:22 UTC, Iain Buclaw wrote: [...] Thanks! Question. From the changelog; Posix (excl. Darwin): Switch default GC signals from SIGUSR1/2 to SIGRTMIN/SIGRTMIN+1 What should I tell gdb to handle to catch those? `SIG33` and `SIG34`? Check whether it is already stopping on those signals. ``` (gdb) handle SIG33 SIG34 SignalStop Print Pass to program Description SIG33 Yes Yes Yes Real-time event 33 SIG34 Yes Yes Yes Real-time event 34 ``` If not, append `stop` to the above command.
Re: Beta 2.101.0
This has been fixed, ♥ to the 62 contributors. ;-)
Re: Beta 2.101.0
On Monday, 17 October 2022 at 12:51:58 UTC, rassoc wrote: On 10/17/22 13:35, Iain Buclaw via Digitalmars-d-announce wrote: Glad to announce the first beta for the 2.101.0 release, ♥ to the 299 contributors. Thank you and congrats on the first (beta) release as the new release manager! But say, what's happening with the linked issues? Clicking the first few goes back to stuff submitted in 2006 and fixed in 2012ish. Might also explain the high contributor count, some of these names haven't been active in D for years. DMD and D Runtime were merged together into one repository, this includes all histories, so I suspects it's picking up all authors from that. You can verify the what was read in by the changelog tools by running: ``` git log --pretty='format:%aN|%aE' v2.100.2..v2.101.0-beta.1 | sort -u ``` See https://github.com/dlang/tools/blob/master/contributors.d#L81 I think for this release only, we can work around this by using pathspecs to exclude druntime. ``` ( git -C dmd log --pretty='format:%aN|%aE' v2.100.2..upstream/stable ':!druntime' git -C dmd log --pretty='format:%aN|%aE' v2.100.2..upstream/stable druntime git -C druntime log --pretty='format:%aN|%aE' v2.100.2..upstream/stable ) | sort -u ```
Beta 2.101.0
Glad to announce the first beta for the 2.101.0 release, ♥ to the 299 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.101.0.html As usual please report any bugs at https://issues.dlang.org -Iain
Re: Generate a pointer to a method of a struct
On Friday, 14 October 2022 at 18:34:58 UTC, kdevel wrote:
dmd and gdc optimize the lambda invocations away. Nonetheless
the expression looks somewhat too big. To overcome this I tried
to generate the function pointer outside of the struct:
```
auto funcptr (alias method) ()
{
return
}
:
fun = funcptr!bar;
:
```
Which works but neither dmd nor gdc were able to optimize the
additional function call away.
pragma(inline, true)
auto funcptr (alias method) ()
Re: Release D 2.100.2
On Sunday, 11 September 2022 at 08:34:40 UTC, Martin Nowak wrote: Glad to announce D 2.100.2, ♥ to the 18 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.100.2, see the changelog for more details. http://dlang.org/changelog/2.100.2.html -Martin Thanks for your hard work and effort doing this! Not nearly enough praise has been given for you keeping this up for many years. Wish you all the best!
Re: GCC 12.2 Released (D v2.100.1)
On Wednesday, 7 September 2022 at 21:46:26 UTC, Per Nordlöw wrote: On Friday, 19 August 2022 at 11:36:09 UTC, Iain Buclaw wrote: GCC version 12.2 has been released. Thanks again, Ian. What are the options for installing GDC 12.2 on Ubuntu 22.04? GCC PPA or build from source? That'd be a question for the package maintainer. I should be meeting them next week at a conference, so can ask why GCC 12.1 was never landed in LTS. The usual PPA to go to for latest toolchain builds is https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: Since the meeting, Iain and I have set up a new server for the archived downloads. We've moved away from AWS and are now using Backblaze (with free bandwidth, thanks to the Bandwith Alliance and our use of Cloudflare). All 235.2 GB of DMD downloads have been moved. Iain can correct me if I'm wrong, but I believe this is active right now, so anything you download from downloads.dlang.org will come from there. As for the code-signing certificate, we're trying to decide on an option that's best for us. In the meantime, the last I heard, Martin Nowak was going to put out a release of 2.100.1 without signing the Windows executable. The new download archive on Backblaze is still on stand-by for now. After the 2.100.2 release proper has gone out, we'll make the switch. What is active right now on Backblaze is the revival of https://docarchives.dlang.io
Re: Beta 2.100.2
On Wednesday, 31 August 2022 at 15:48:05 UTC, matheus wrote: On Wednesday, 31 August 2022 at 13:20:51 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.100.2 point release, Thanks. N.B.: We had some delays to clarify the expired EV certificate and the next releases will ship without signed Windows binaries due to the complications and cost of EV certificates. Is possible to share the costs for this? Anywhere in the ballpark of an $750 to $1300 annual fee. Can only give an estimate as on top of the eye-watering EV prices, there may be more equally high fees for attestation and cloud signing. To put that in context, the original certificate ordered in 2018 cost only $267 and was valid for **3 years**. That's a price inflation of over 150% year-on-year! The process has gotten more complex too, as it is now required to have some sort of [hardware token](https://cabforum.org/2022/04/06/ballot-csc-13-update-to-subscriber-key-protection-requirements/) in order to sign, not exactly CI pipeline friendly. Cloud-based HSM solutions exist, but at an opaque cost, and our current workflow will still be broken after getting it set-up anyway. All this for at most only 12 signed Windows binaries per year (maybe 36 if you include the beta and rc releases). It's getting hard to justify proceeding with this cost unless we are *really* confident with just exactly what we are doing. I've only come across one other language compiler that has an open issue for a lack of code signed release binaries. It seems that an agreement was made with the Mozilla foundation to use their [autograph service](https://github.com/mozilla-services/autograph), but they've made no progress on it for the last 7 years, and there are still no signed releases. No one has raised an issue so far for all DMD releases since that occurred in the last 12 months, so either lack of signing isn't an problem, or people are just ignoring/working around whatever warning messages you might get for running unsigned binaries (NB: haven't used Windows since 2003 so I have no clue what happens when you run an unsigned binary).
Re: GCC 12.2 Released (D v2.100.1)
On Friday, 19 August 2022 at 15:38:01 UTC, Ruby The Roobster wrote: On Friday, 19 August 2022 at 13:44:35 UTC, bachmeier wrote: On Friday, 19 August 2022 at 11:36:09 UTC, Iain Buclaw wrote: - Updated the D front-end from v2.100.0-rc1 to v2.100.1. GDC is now ahead of DMD? No. It's just that the download link for v2.100.1 is broken, so the current version was changed to display v2.100.0. Not quite, binaries just haven't been built yet due to certificate signing issues breaking the current workflow (that and the process is all reliant on one person who no longer has any free time). But that's another matter.
GCC 12.2 Released (D v2.100.1)
Hi, GCC version 12.2 has been released. GCC 12.2 is the first bug-fix release from the GCC 12 branch containing important fixes for regressions and serious bugs in GCC 12.1 with 11 bugs fixed in GDC since the previous release. Notable changes: - Updated the D front-end from v2.100.0-rc1 to v2.100.1. - Linkage of `pragma(inline, true)` functions has been changed to linkonce/comdat, as they are now compiled into every compilation unit they are referenced from. If you were previously getting unresolved references to pragma inline symbols at link-time, this has now been fixed. If you encounter difficulties, while you may contact me directly, it is better to visit https://gcc.gnu.org/bugzilla and file a problem report. There's also the [#gdc](https://dlang.slack.com/archives/C6LTP6MV1) channel on the Dlang Slack or [#d.gdc](irc://irc.libera.chat/d.gdc) on Libera.Chat IRC (or try your luck on [Discord](https://discord.gg/hj6ByvrVus)) for any general queries, support, consulting, and/or social. Until the next major/minor release... Regards, Iain.
Re: DConf 2022 pre+watch party!
On Thursday, 28 July 2022 at 16:09:46 UTC, Rikki Cattermole wrote: Hello everyone! It is back, DConf IRL. To celebrate we will have a bit of a pre-party over in the Discord voice channel, as well as a bit of a watch party going on during the conference live streams. We may switch over to Jitsi later on depending on how the IRL BeerConf goes and if someone ends up joining from there. Discord invite link: https://discord.gg/bMZk9Q4 It all starts tomorrow, so stock up because it's going to be 6 days of D! How did this work out? :-) Shall we start a jitsi meet-up?
Re: D News April-May - DConf '22 BeerConf Has a Sponsor!
On Sunday, 29 May 2022 at 12:41:18 UTC, Mike Parker wrote: GDC 12.1 (the first GDC release with the D version of the D backend), That should also be frontend, not backend. :-)
Re: GCC 12.1 Released (D v2.100-rc.1)
On Friday, 6 May 2022 at 11:57:47 UTC, Iain Buclaw wrote: Hi, I am proud to announce another major GCC release, 12.1. This year, the biggest change in the D front-end is the version bump from v2.076.1 to **[v2.100.0-rc.1](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b4acfef1342097ceaf10fa935831f8edd7069431)**. For the full list of front-end changes, please read the [change log on dlang.org](https://dlang.org/changelog/2.100.0.html). As and when DMD releases new minor releases of v2.100.x, they will be backported into the next minor release of GCC. The GCC-12 release branch has now been [sync'd up](https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0556c356e541aa106dcc4276db429ee0d2343d99) with the release of DMD v2.100.0.
Re: GCC 12.1 Released (D v2.100-rc.1)
On Wednesday, 11 May 2022 at 19:08:15 UTC, Anonymouse wrote: gcc-d 11.2.0-4 has been removed from the [core] repository. Does anyone know what's going on there? You should ask the package maintainers. https://github.com/archlinux/svntogit-packages/commit/6ebddb843f621263f4ce6e5a8b2b6856f337c218
Re: GCC 12.1 Released (D v2.100-rc.1)
On Saturday, 7 May 2022 at 20:14:51 UTC, Witold Baryluk wrote: Good you mentioned that! I was not aware of the sponsorship program, and now that I know, I gladly will chip in (well, just did it moments ago). For testing infrastructure, I would suggest tracking compilation speed and memory usage and output binary size of GDC on amd64 and aarch64 at least (to detect compiler getting slower, or due to growth of Phobos / druntime), and having a public website showing this data. Something like this maybe https://fast.vlang.io/ Cheers. Thanks for the suggestion. Vladimir did in fact do that for dmd last decade, it only ran for a couple years though. Have been thinking about maybe reviving it every so often. https://blog.cy.md/2015/05/05/is-d-slim-yet/ Adam (maybe in a TWID post) did a few months back lament that D1 vs D2 equivalent code compiles slower with the latter. The bulk of which in the trivial case came from Druntime and how many modules are imported (D1 object.d had no imports, D2 object.d imports around 25 modules). Remove the excessive imports and the original speed was observed again. That's only one small example though of where perceived slowness comes from the library becoming more complex over time - and I expect it only to increase as more of the old opaque compiler-library interface is replaced with a templated interface that exposes the guts of what each helper does (for improved run-time performance, of course).
Re: GCC 12.1 Released (D v2.100-rc.1)
On Friday, 6 May 2022 at 13:30:41 UTC, Steven Schveighoffer wrote: Why is this news not captured [here](https://gcc.gnu.org/gcc-12/changes.html)? I would have expected to see it in the language specific changes. I need some more time to push in that content to the GCC site. Expect it some time over the next fortnight.
Re: Problem with GC - linking C++ & D (with gdc)
On Tuesday, 26 April 2022 at 10:23:15 UTC, Claude wrote:
Hello,
Hello,
<%--SNIP--%>
Does anyone have any idea what's going on?
(if I just compile a single D file with "int main() { int* a =
new int(42); return *a; }", it works as intended.)
The `new` keyword requests the druntime GC to allocate memory,
however you haven't initialized the D run-time in your program.
main.cpp
```D
extern "C" int rt_init();
extern "C" const int* ct_parse();
int main(int argc, char ** argv)
{
rt_init();
return *ct_parse();
}
```
Re: gdc or ldc for faster programs?
On Monday, 31 January 2022 at 10:33:49 UTC, Siarhei Siamashka wrote: I wonder if GDC can do the same? GDC as a front-end doesn't dictate what the optimization passes are doing, nor does it have any real control what each level means. It is only ensured that semantic doesn't break because of an optimization pass.
Re: Beerconf February 2022
On Saturday, 12 February 2022 at 22:20:09 UTC, Steven Schveighoffer wrote: # BEERCONF Hi, Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2022FebruaryBeerConf Password: `__traits(parameter)` **How do I join?** You'll need to have a [compatible browser](https://jitsi.github.io/handbook/docs/user-guide/supported-browsers) to connect to the meeting. Alternatively you can install jitsi-meet with flatpak. **Wait, it's not Saturday?** Timezones are weird, right? **OK, so what do I do?** Join and [wear your Beerconf T-Shirt](https://www.zazzle.com/store/dlang_swag?rf=238129799288374326). See you all there!
Re: Beta 2.099.0
On Wednesday, 16 February 2022 at 09:05:39 UTC, Basile B. wrote: On Tuesday, 15 February 2022 at 16:12:25 UTC, Iain Buclaw wrote: Maybe an issue could be raised against the [dlang-bot](https://github.com/dlang/dlang-bot) to request better handling of ambiguous commit messages? Yes but in the meantime I find strange that you have just approved a PR that will have the same effect [with issue 2]. [with issue 2]: https://github.com/dlang/dmd/pull/13663 I probably reviewed it on my phone - the github app is very good at hiding lots of information I would have otherwise spotted on desktop. :-)
Re: Beta 2.099.0
On Tuesday, 15 February 2022 at 13:27:18 UTC, Basile B. wrote: On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.099.0 release, ♥ to the 99 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.099.0.html As usual please report any bugs at https://issues.dlang.org -Martin Issue 3 is wrongly [referenced]. I will not create a bugzilla entry because I think this is not fixable [referenced]: https://dlang.org/changelog/2.099.0.html#bugfix-list Maybe an issue could be raised against the [dlang-bot](https://github.com/dlang/dlang-bot) to request better handling of ambiguous commit messages?
Re: gdc or ldc for faster programs?
On Thursday, 27 January 2022 at 20:28:40 UTC, Siarhei Siamashka wrote: On Thursday, 27 January 2022 at 18:12:18 UTC, Johan Engelen wrote: But the language requires ODR, so we can emit templates as weak_odr, telling the optimizer and linker that the symbols should be merged _and_ that ODR can be assumed to hold (i.e. inlining is OK). Thanks! This was also my impression. But the problem is that Iain Buclaw seems to disagree with us. He claims that template functions must be overridable by global functions and this is supposed to inhibit template functions inlining. Is there any independent source to back up your or Iain's claim? For example, druntime depends on this behaviour. Template: https://github.com/dlang/druntime/blob/a0ad8c42c15942faeeafb016e81a360113ae1b6b/src/rt/config.d#L46-L58 Regular symbol: https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/test/config/src/test19433.d#L1 If we can rely on instantiated symbols to not violate ODR, then you would be able to put symbols in the .link-once section. However all duplicates must also be in the .link-once section, else you'll get duplicate definition errors.
Re: gdc or ldc for faster programs?
On Wednesday, 26 January 2022 at 18:39:07 UTC, Siarhei Siamashka wrote: It's not DMD doing a good job here, but GDC11 shooting itself in the foot by requiring additional esoteric command line options if you really want to produce optimized binaries. The D language shot itself in the foot by requiring templates to have weak semantics. If DMD and LDC inline weak functions, that's their bug.
Re: gdc or ldc for faster programs?
On Wednesday, 26 January 2022 at 11:43:39 UTC, forkit wrote: On Wednesday, 26 January 2022 at 11:25:47 UTC, Iain Buclaw wrote: Whenever I've watched talks/demos where benchmarks were the central topic, GDC has always blown LDC out the water when it comes to matters of math. .. https://dlang.org/blog/2020/05/14/lomutos-comeback/ Andrei forgot to do a follow up where one weird trick makes the gdc compiled lumutos same speed as C++ (and faster than ldc). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96429
Re: gdc or ldc for faster programs?
On Wednesday, 26 January 2022 at 04:28:25 UTC, Ali Çehreli wrote: On 1/25/22 16:15, Johan wrote: > On Tuesday, 25 January 2022 at 19:52:17 UTC, Ali Çehreli wrote: >> >> I am using compilers installed by Manjaro Linux's package system: >> >> ldc: LDC - the LLVM D compiler (1.28.0): >> based on DMD v2.098.0 and LLVM 13.0.0 >> >> gdc: dc (GCC) 11.1.0 >> >> dmd: DMD64 D Compiler v2.098.1 > > What phobos version is gdc using? Oh! Good question. Unfortunately, I don't think Phobos modules contain that information. The following line outputs 2076L: pragma(msg, __VERSION__); So, I guess I've been comparing apples to oranges but in this case an older gdc is doing pretty well. Doubt it. Functions such as to(), map(), etc. have pretty much remained unchanged for the last 6-7 years. Whenever I've watched talks/demos where benchmarks were the central topic, GDC has always blown LDC out the water when it comes to matters of math. Even in more recent examples where I've been pushing for native complex to be replaced with std.complex, LDC was found to be slower with std.complex, but GDC was either equal, or faster than native (and GDC std.complex was faster than LDC).
Re: GDC has just landed v2.098.0-beta.1 into GCC
On Tuesday, 30 November 2021 at 19:37:34 UTC, Iain Buclaw wrote: Hi, The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. I've spoken with the folks at compiler explorer and they've fixed up their build scripts to that this is now live to play around with @ https://d.godbolt.org/ Regards, Iain.
Re: GDC has just landed v2.098.0-beta.1 into GCC
On Friday, 3 December 2021 at 13:48:48 UTC, Patrick Schluter wrote: On Tuesday, 30 November 2021 at 19:37:34 UTC, Iain Buclaw wrote: Hi, just a little question that annoys me in my project which is mainly written in C and clashes with the D code I'm integrating slowly into it. I generate the makefile dependencies with the -MMD option of gcc and that option generates .d files (which are not D language files), this is annoying as I had to rename my D files with a .D extension. Is there a way to force gcc to use another extension? Is this extension clash been solved somehow, as the man of gcc 10.2 lists .d as the extension for Dlang files. Yes, with -MF to specify the output dependency file.
Re: GDC has just landed v2.098.0-beta.1 into GCC
On Thursday, 2 December 2021 at 11:44:33 UTC, Per Nordlöw wrote: On Tuesday, 30 November 2021 at 19:37:34 UTC, Iain Buclaw wrote: The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. To try this out do I build gcc with only the D language frontend enabled? Yes, if you want it to build fast, you can use `--disable-bootstrap`.
GDC has just landed v2.098.0-beta.1 into GCC
Hi, The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. As the D front-end for GDC is now itself written in D, in order to build GDC, you will need a working GDC compiler (GCC version 9.1 or later). Of the tested ports that work for bootstrapping the new front-end, x86_64-linux-gnu is the most battle tested. Others that have been checked and verified to work include: - mips-linux-gnu - powerpc64le-linux-gnu - sparcv9-sun-solaris - x86_64-portbld-freebsd12 - amd64-openbsd6.9 - x86_64-netbsd - x86_64-apple-darwin20. **Why specifically v2.098.0-beta.1?** No real reason, other than it was just the last time that I had synchronized my [development branch](https://github.com/D-Programming-GDC/gcc/tree/ibuclaw/gdc) with upstream dmd. You can expect this to be bumped again to the latest commit made to [dmd master](https://github.com/dlang/dmd/commits/master) in the coming week, and for GDC to closely follow DMD development until around end of March when we'll switch over to whatever will be the upcoming DMD version just before the GCC-12 release freeze. --- ``` $ git show --oneline --stat 5fee5ec362f d: Import dmd b8384668f, druntime e6caaab9, phobos 5ab9ad256 (v2.098.0-beta.1) ... 2803 files changed, 338878 insertions(+), 193928 deletions(-) ``` --- **What's left in the pipeline?** For the next six months until May, its just the usual, too many things to do, too little time to do them. I haven't forgotten about other improvements that I started looking into at the beginning of this development cycle: - Hosting release binaries on the gdc project site (or github, or both) - Updating the compilers on the explorer site to version 11 - Add more targets to the gdc build infrastructure. If you think you could contribute in any way, please don't hesitate to jump on the [#gdc](https://dlang.slack.com/archives/C6LTP6MV1) channel on the Dlang Slack or [#d.gdc](irc://irc.libera.chat/d.gdc) on Libera.Chat IRC and ask about it. See you around at the next release or update. Regards, Iain. # If you are interested in helping support ongoing development or infrastructure costs for CI and platform testing, you can do so by making a donation to the [D Language Foundation](https://dlang.org/foundation/donate.html), approximations of costs into USD are up on my [Github Sponsor page](https://github.com/sponsors/ibuclaw/).
Re: Debugging D code with GDB
On Monday, 29 November 2021 at 14:48:21 UTC, Luís Ferreira wrote: On Sun, 2021-11-28 at 21:59 +, Iain Buclaw via Digitalmars-d-learn wrote: DMD doesn't emit this information. GDB can't work miracles when the compiler isn't pulling its own weight. I confirm this is an issue with DMD. I filed a bug in the issue tracker, in case you want to follow: https://issues.dlang.org/show_bug.cgi?id=22551 Anyway, DMD exports the symbol, it should work if you do something like `myPrint()`, but I think there is another problem on calling it, due to defective calling convention on both DMD and LDC implementations. LDC exports the symbol correctly, although. Indeed, gdb assumes calling convention is same as default for target (actually its been years since I last looked, but are calling conventions tags in dwarf? Does gdb know about functions with thiscall or regparm attributes?) Another thing on the gdb side, it is currently missing D language support for overloads, so that the correct function would be picked when you call e.g std.math.sin(1f).
Re: Debugging D code with GDB
On Saturday, 27 November 2021 at 14:17:11 UTC, Eduard Staniloiu
wrote:
Hello,
I'm trying to use `gdb` to debug D binaries, but I'm having
trouble accessing the methods of a struct or class. It seems
that `gdb` doesn't see them.
Given the following simple example
```
// test.d
struct S
{
int x;
void myPrint() { writefln("x is %s\n", x); }
}
void main(string[] args)
{
S s;
}
```
Compile the source file with debug simbols (`dmd -g test.d
-of=test`) and open the binary with gdb (`gdb test`) and run
the following
```
break _Dmain # break at D entry point
run
ptype s
type = struct test.S {
int x;
}
print s.myPrint()
Structure has no component named myPrint.
```
As you can see, when I try to access the `myPrint()` method I
get the error
"Structure has no component named myPrint."
DMD doesn't emit this information. GDB can't work miracles when
the compiler isn't pulling its own weight.
Re: Beerconf October 2021
On Saturday, 30 October 2021 at 12:11:45 UTC, Brian Callahan wrote: On Saturday, 30 October 2021 at 08:00:49 UTC, Iain Buclaw wrote: **What is Beefconf?** (The beefconf typo is back this month ) One of these days I'll learn to type, until then I'll just keep on blaming my semi-broken laptop keyboard. ;-)
Re: Beerconf October 2021
On Monday, 18 October 2021 at 13:44:05 UTC, Steven Schveighoffer wrote: # BEERCONF! See you in 2 weeks! Hi all, Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2021OctoberBeerConf Password: `--DRT-gcopt=fork:1` **What is Beefconf?** [Follow this link](https://wiki.dlang.org/Beerconf). **How do I join?** You'll need to have a [compatible browser](https://jitsi.github.io/handbook/docs/user-guide/supported-browsers) to connect to the meeting. Alternatively you can install jitsi-meet with [flatpak](https://flathub.org/apps/details/org.jitsi.jitsi-meet). **Wait, it's not Saturday?** Timezones are weird, right? **OK, so what do I do?** Join and [wear your Beerconf T-Shirt](https://www.zazzle.com/store/dlang_swag?rf=238129799288374326). See you all there!
Re: Beerconf October 2021
On Friday, 29 October 2021 at 02:54:13 UTC, Steven Schveighoffer wrote: On 10/18/21 9:44 AM, Steven Schveighoffer wrote: # BEERCONF! Just one month to go before the next [dconf online](http://dconf.org/2021/online/index.html), I hope everyone is excited! In the meantime, we will once again get together online to discuss all things D, and sample some tasty beverages. This month, it falls on October 30-31. If you need a costume for Sunday, I suggest a nice [T-shirt](https://www.zazzle.com/store/dlang_swag/products?cg=196874696466206954). Just a ping to everyone, this is happening in 2 days! See you then You missed a trick and forgot to call it Octoberfest. ;-)
Re: Beerconf September 2021
On Sunday, 26 September 2021 at 18:05:08 UTC, Brian wrote: On Saturday, 25 September 2021 at 07:14:58 UTC, Iain Buclaw wrote: **What is Beefconf?** What is Beefconf, indeed. Are we getting an additional online meetup this month? :) We'll also be starting up Beetconf as well. :-)
Re: Beerconf September 2021
On Saturday, 11 September 2021 at 16:51:20 UTC, Steven Schveighoffer wrote: # BEERCONF! Hi all, Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2021SeptemberBeerConf Password: `-preview=dtorfields` **What is Beefconf?** [Follow this link](https://wiki.dlang.org/Beerconf). **How do I join?** You'll need to have a [compatible browser](https://jitsi.github.io/handbook/docs/user-guide/supported-browsers) to connect to the meeting. Alternatively you can install jitsi-meet with [flatpak](https://flathub.org/apps/details/org.jitsi.jitsi-meet). **Wait, it's not Saturday?** Timezones are weird, right? **OK, so what do I do?** Join and [wear your Beerconf T-Shirt](https://www.zazzle.com/store/dlang_swag?rf=238129799288374326). See you all there!
Re: Beerconf August 2021
# BEERCONF! Hi all, Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2021AugustBeerConf Password: `gcopt=fork:1` **What is Beefconf?** [Follow this link](https://wiki.dlang.org/Beerconf). **Wait, it's not Saturday?** Timezones are weird, right? **OK, so what do I do?** Join and [wear your Beerconf T-Shirt](https://www.zazzle.com/store/dlang_swag?rf=238129799288374326). See you all there!
GCC 11.2 Released
Hi, GCC version 11.2 was released on the 28th. GCC 11.2 is a bug-fix release from the GCC 11 branch containing important fixes for regressions and serious bugs in GCC 11.1. In the D language front-end and standard library, there have been two ICE bug fixes, and and two code generation fixes in GDC itself. Other regression/bugs fixes were cherry-picked from upstream DMD for bugzilla issues 12504, 17857, 19234, 21742, 21898, 21927, 21939, 22005, 22006, and 22007. As usual, sources are available from any of the [GCC mirrors](https://gcc.gnu.org/mirrors.html), or you can clone the [git repository](git://gcc.gnu.org/git/gcc.git). Wait long enough, and it should be appearing in a Linux distribution near you. Regards Iain.
Re: Beerconf July 2021
On Sunday, 11 July 2021 at 14:01:43 UTC, Steven Schveighoffer
wrote:
# BEERCONF!
Hi all,
Beerconf is inviting you to a meeting.
Join the meeting: https://meet.jit.si/Dlang2021JulyBeerConf
Password: `import("stdlib.h");`
**What is Beefconf?** [Follow this
link](https://wiki.dlang.org/Beerconf).
**Wait, it's not Saturday?** [It is in
Auckland](https://www.timeanddate.com/worldclock/fullscreen.html?n=22).
**OK, so what do I do?** Join and [get yourself a Beerconf
T-Shirt](https://www.zazzle.com/store/dlang_swag?rf=238129799288374326).
See you all there!
Re: Release D 2.097.1
On Tuesday, 20 July 2021 at 10:21:48 UTC, Martin Nowak wrote: Glad to announce D 2.097.1, ♥ to the 9 contributors. http://dlang.org/download.html This point release fixes a few issues over 2.097.0, see the changelog for more details. http://dlang.org/changelog/2.097.1.html -Martin I hope you're ready for a 2.097.2 release in a day or two. :-)
Re: Beerconf July 2021
On Sunday, 11 July 2021 at 14:01:43 UTC, Steven Schveighoffer wrote: # BEERCONF! In 2 weeks we will have the 14th [mensual](https://www.merriam-webster.com/dictionary/mensual) online Beerconf on July 24-25! Just a forewarning, it was brought to my attention last month that for some people, Beerconf would fall on the Sunday/Monday 25-26th for them. Why? If you're living in Apia, Saturday 24th July would begin on Friday 23rd at 13:00 CEST, while in neighbouring Alofi, Sunday 25th ends on Monday 26th at 13:00 CEST. So this month as an experiment I'll be starting the Jitsi meeting at a time that suits people living on the edge of the positive side of UTC (mostly Auckland and East-coast Australia). If you are living in Europe or America, this would be Friday afternoon or evening for you. Depending on how it goes, either we'll see more of a spread out meet-up, or start being more centric around UTC. See you all next week!
Re: Beerconf June 2021
On Saturday, 12 June 2021 at 14:58:36 UTC, Steven Schveighoffer wrote: # BEERCONF Hi everyone! Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2021JuneBeerConf Password: `while (auto x = expression)` See you all there!
Re: GCC 11.1 Released
On Wednesday, 9 June 2021 at 07:15:40 UTC, Elronnd wrote: On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote: 2. The promise of dynamically generating D bindings from C headers never really materialized. Actual work of adding a GCC compiler switch to dump D code was [completed to around 95% of what was needed](https://github.com/D-Programming-GDC/gcc/compare/1cb2d1d5ce178cb68f0bd475299d2e0b25a4a756...ibuclaw/dumpspec), but then stalled on the just how this feature would integrate this into druntime. Could this also support c++? If so, that seems like it could potentially be a reason to continue development on it preferentially to importC. Calypso-ish :) Because it works on the debug info/generic tree level, all languages GCC supports can be used to emit D bindings for their code.
Re: From the D Blog: Driving with D
On Tuesday, 8 June 2021 at 09:08:20 UTC, Max Samukha wrote:
On Monday, 7 June 2021 at 10:38:08 UTC, Max Samukha wrote:
Would be great if you did. Not a blocker, though.
However, this is a major pain:
```d
struct FP {
}
alias parse = () {
FP[] parts;
parts ~= FP();
return parts;
};
immutable s = parse();
extern(C) int main() {
return 0;
}
```
avr-gdc -fno-druntime ctfe.d
ctfe.d:3:1: error: 'object.TypeInfo' cannot be used with
'-fno-rtti'
3 | struct FP {
| ^
ctfe.d:3:1: error: 'object.TypeInfo' could not be found, but is
implicitly used
3 | struct FP {
| ^
d21: internal compiler error: Segmentation fault
0x178ae29 internal_error(char const*, ...)
Thanks, that seems to be [this
issue](https://issues.dlang.org/show_bug.cgi?id=19234).
Testing backports of both now
([here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100935) and
[here](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100964)).
Re: From the D Blog: Driving with D
On Sunday, 6 June 2021 at 20:11:04 UTC, Max Samukha wrote:
On Sunday, 6 June 2021 at 18:57:06 UTC, Max Samukha wrote:
2) 'align' is mishandled
GCC's bugzilla won't let me register.
You'd have to use a non-gmail account IIRC, not sure if there's
any others that are in the "typically spam" blacklist.
align(4)
struct S {
ubyte[4] bytes;
}
static assert (S.alignof == 4); // fail, S.alignof == 1
It's not specific to AVR. Worked around by placing 'align'
inside the struct.
That sounds a lot like this issue:
https://issues.dlang.org/show_bug.cgi?id=17857
Can backport that for GCC-11.
Re: From the D Blog: Driving with D
On Friday, 4 June 2021 at 21:28:00 UTC, Max Samukha wrote:
On Friday, 4 June 2021 at 15:48:50 UTC, rikki cattermole wrote:
Does this form of foreach work?
foreach(i; 0 .. 10)
That does work.
This doesn't:
ubyte[] slice;
foreach (ubyte i; slice) {
}
Invalid bitcast
%17 = bitcast i16 %15 to i32
I guess the cause is the same - slice.length.sizeof == 4, while
slice.sizeof == 4, slice.ptr.sizeof == 2, and size_t.sizeof ==
2.
You should have better luck using gdc on avr.
https://explore.dgnu.org/z/bos5ee
Re: LWDR (Light Weight D Runtime) for Microcontrollers v0.2.3
On Monday, 31 May 2021 at 01:05:03 UTC, Dylan Graham wrote:
On Sunday, 30 May 2021 at 17:31:37 UTC, Dukc wrote:
On Sunday, 30 May 2021 at 14:28:25 UTC, Dylan Graham wrote:
It works by providing a series of barebones API hooks (alloc,
dealloc, assert, etc) (defined in `rtoslink.d`), which you
must implement and/or point to your RTOS implementation.
Quickly looking, the implementation looks very portable, save
for exceptions. with `rtoslink.d`, this will probably enable a
lot of stuff on any platform without DRuntime. Not just
microcontrollers. If I'm right, you just did a BIG service for
D on bare-metal.
Exceptions are a nightmare. It works for GDC with GCC code. My
codebase uses GCC for its C (ST toolchain), so I need to write
some code that can take LDC's exception handling and make it
compatible with how GCC operates. So, it looks like there will
be multiple exception handling implementations (LDC with GCC
backend, LDC with clang backend, GDC with GCC backend). I wish
D had something like Zig's error handling.
Otherwise, thank you! It was designed to be agnostic as much as
possible. I didn't know it'd help out for more than just
microcontrollers :)
Good to see this work come to fruition. First thing I stumbled
across was a
[mispelling](https://github.com/0dyl/LWDR/blob/eb5de110ba2cff4bd0e654e8a68b59fc5eb76157/source/rtoslink.d#L14) of one of the RTOS hooks.
Regarding exceptions, apart from one small detail I'd have
thought that GDC and LDC would be compatible, as both just use
libunwind. Said small detail are the name of the entry-points
for the "throw" and "personality" routines. Both of which can be
sorted out trivially with some stubs to forward from one to the
other.
```
extern(C) void _d_throw(Throwable o) { return _d_throw_common(o);
}
extern(C) void _d_throw_exception(Throwable o) { return
_d_throw_common(o); }
extern(C) void _d_throw_common(Throwable o)
{
pragma(inline, false);
// Implementation here: tail merging should take care of the
entrypoints.
}
```
Re: BeerConf May 2021
On Thursday, 27 May 2021 at 14:34:03 UTC, Steven Schveighoffer wrote: A reminder that this is 2 days away. See you then! -Steve Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2021MayBeerConf Password: `__traits(toType)` See you all there!
Dlang IRC has moved to Libera Chat
Hi all, For over 18 years, we have used Freenode as our home for the Dlang community on IRC. Recent events, however, have made it unclear whether we will be able to retain any presence on Freenode at all. So it has been decided, as of [2021/05/27](https://github.com/dlang/dlang.org/pull/3012), our official IRC presence will now be on [Libera Chat](https://libera.chat/), with [OFTC](https://www.oftc.net/) as a secondary home. The Freenode channel has now been marked as unofficial, and we invite everyone to join us in #d on Libera Chat. With that said, I am happy to announce that the Dlang project has been registered with Libera Chat. This grants us claim to the #d and #dlang related channels, as well as setting up dlang cloaks. If you are a contributor to any project under the umbrella of dlang (including gdc and ldc), and would like to request a cloak, then please reach out to us. The new channels on libera are: - `#d`: Dlang community channel - `#d-feed`: DFeed bot postings of all dlang-related posts, issues, and pull requests - `#d-gdc`: GDC development channel - `#dlang`: Dlang development channel See you all there! --- **THIS IS NOT A DISCUSSION THREAD** Please discuss the announcement in the [general forum thread](https://forum.dlang.org/post/ecmxtpulswayuzjrg...@forum.dlang.org).
Re: GCC 11.1 Released
On Thursday, 27 May 2021 at 14:14:40 UTC, WebFreak001 wrote: On Thursday, 27 May 2021 at 01:04:37 UTC, Iain Buclaw wrote: ... my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). ... TIL, sponsored! Well, I am speechless. I've had a few surprises in my inbox this morning in relation to that link.
GCC 11.1 Released
Hi, This year it's taken even longer than usual to get round to posting the formal announcement, but here it now is, and there has been a lot to sift through. As of last month (27th April), [GCC 11.1 has now been released](https://gcc.gnu.org/gcc-11/changes.html#d). For the D language front-end, there have been a significant number of changes, so it's probably best to start with the lowlights as they are comparatively small. --- Lowlights - 1. Contrary to the hopes of last years release announcement, this version still uses [D 2.076.1](https://dlang.org/changelog/2.076.1.html) as the baseline for D language support. Some significant blocking issues in upstream DMD meant that I could not commit to switching to self-hosted with full confidence, and said issues did not get resolved until after the feature window closed. 2. The promise of dynamically generating D bindings from C headers never really materialized. Actual work of adding a GCC compiler switch to dump D code was [completed to around 95% of what was needed](https://github.com/D-Programming-GDC/gcc/compare/1cb2d1d5ce178cb68f0bd475299d2e0b25a4a756...ibuclaw/dumpspec), but then stalled on the just how this feature would integrate this into druntime. Then there's been the announcement of importC, which seems like a good reason to change tack and instead put effort into getting importC to the state where it is fit for purpose. Perhaps this utility could be released anyway, as an alternative to the likes of DStep, except leverages gcc to parse the sources instead via `gcc file.c -fdump-d-spec=file.d` 3. Whilst [my little project site](https://gdcproject.org) did recent a styling revamp, very little was done in the way of documentation. Though soon I hope to get changelog entries published there at least. 4. The [compiler explorer site](https://explore.dgnu.org) has also been updated, though the running compilers were left at version GCC 9.1. --- Highlights -- 1. Instead of updating language version, efforts have been driven towards increasing cross-platform support, there have been a number of new additions: - FreeBSD - DragonFlyBSD - OpenBSD - OS X - MinGW OpenBSD, OS X and MinGW do not enable Phobos by default, and are to be considered experimental at this time, you can override the building of Phobos with the `--enable-libphobos` configure switch. OS X has been the most tested of the experimental configurations, and is working generally well on all versions between Darwin 10 and 19. 2. Testing infrastructure has been expanded, and it is no longer Ubuntu-centric. There are now the following new platforms under test: - [CirrusCI](https://cirrus-ci.com/build/6373685910044672) - x86_64-linux-gnu - x86_64-portbld-freebsd12.2 - x86_64-apple-darwin19 - [Buildkite](https://buildkite.com/d-programming-gdc/gcc/builds/285) - x86_64-alpine-linux-musl - x86_64-unknown-netbsd - amd64-unknown-openbsd6.9 For everything else under Buildkite, the two pre-existing agents have had a CPU upgrade, and a third agent has been added into the infrastructure that has reduced overall build times by more than half. The servers I'm using for buildkite are ridiculously cheap, however if you are interested in helping support the monthly costs, you can do so by making a donation to the [D Language Foundation](https://dlang.org/foundation/donate.html), approximations of costs into USD are up on my [Github Sponsor page](https://github.com/sponsors/ibuclaw/). --- **New features**: - A new bottom type `typeof(*null)` has been added to represent run-time errors and non-terminating functions. This also introduces a new standard alias for the type named `noreturn`, and is implicitly imported into every module. - [Printf-like and scanf-like](https://dlang.org/changelog/2.092.0.html#printfParams2) functions are now detected by prefixing them with pragma(printf) for printf-like functions or pragma(scanf) for scanf-like functions. - The __traits() expression now supports the extensions `isDeprecated`, `isDisabled`, `isFuture`, `isModule`, `isPackage`, `child`, `isReturnOnStack`, `isZeroInit`, `getTargetInfo`, `getLocation`, `hasPostblit`, `isCopyable`, `getVisibility`, and `totype`. - [An expression-based contract syntax](https://dlang.org/changelog/2.081.0.html#expression-based_contract_syntax) has been added to the language. - [Function literals can now return](https://dlang.org/changelog/2.086.0.html#funcliteralsbyref) a value by reference with the `ref` keyword. - [A new syntax is available](https://dlang.org/changelog/2.087.0.html#aliasdecly_func) to declare aliases to function types using the `alias` syntax based on the assignment operator. - [New types](https://dlang.org/changelog/2.096.0.html#complex_types) `__c_complex_float`, `__c_complex_double`, `__c_complex_real`, and `__c_wchar_t`
