[Issue 24129] ImportC: MS-Link cannot handle multiple COMDATs with the same name
https://issues.dlang.org/show_bug.cgi?id=24129 Lance Bachmeier changed: What|Removed |Added CC||la...@lancebachmeier.com --- Comment #6 from Lance Bachmeier --- This is marked RESOLVED FIXED but I get the same error message with DMD 2.108.0. --
[Issue 24488] contributor guide hard to find from home page
https://issues.dlang.org/show_bug.cgi?id=24488 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3802 "Add Contributing page" was merged into master: - 20d12f718990ce48265e33b026918abef36bcc76 by Nick Treleaven: Fix Bugzilla 24488 - contributor guide hard to find from home page Replace GitHub and Get Involved items under Community menu with Contributing page. Add link to bug reporting guidelines. Contributing: also list dlang-community and github PR guide. https://github.com/dlang/dlang.org/pull/3802 --
[Issue 24493] FreeBSD_14 version identifier missing
https://issues.dlang.org/show_bug.cgi?id=24493 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @jmdavis created dlang/dmd pull request #16368 "Fix bugzilla issue 24493: FreeBSD_14 version identifier missing" fixing this issue: - Fix bugzilla issue 24493: FreeBSD_14 version identifier missing Apparently, there were two problems that needed fixing. 1. The code for the FreeBSD_14 version identifier had not been added yet. 2. The build did nothing to detect the version of FreeBSD, which makes it very easy to build for the wrong version. The CI apparently sets the version - e.g. TARGET_FREEBSD13 - but unless one of those TARGET_FREEBSD* versions is set, the build defaults to FreeBSD 11, which isn't even supported any longer. So, this adds the code for the FreeBSD_14 identifier, and it makes it so that the build queries the OS version on FreeBSD if TARGET_FREEBSD* has not been set. So, anything that sets the TARGET_FREEBSD* version when building will control the target version as before, but if it's not set, then it will target whatever the current system is. https://github.com/dlang/dmd/pull/16368 --
[Issue 24472] __traits(fullyQualifedName) is undocumented in spec
https://issues.dlang.org/show_bug.cgi?id=24472 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3800 "Fix Bugzilla 24472 - __traits(fullyQualifedName) is undocumented in spec" was merged into master: - cb15125271d8e928492e5d1da7a65e355d278673 by Nick Treleaven: Fix Bugzilla 24472 - __traits(fullyQualifedName) is undocumented in spec https://github.com/dlang/dlang.org/pull/3800 --
[Issue 24491] New: Introduce `is` [keyword] expressions
https://issues.dlang.org/show_bug.cgi?id=24491 Issue ID: 24491 Summary: Introduce `is` [keyword] expressions Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: qs.il.paperi...@gmail.com Currently, `is` can be used in two ways: As a binary operator as in `lhs is rhs` or for type stuff as in `is(T == S)`. In the latter one, we can use `is(T == [keyword])`, where the keyword is `struct`, `class` and whatnot. These really feel wrong. A class type is not equal to `class`. Because `class` is a keyword, why not introduce `T is class`? Effectively, `is class`, `is interface`, `is struct`, `is union`, `is function`, `is delegate`, `is ref`, `is out`, `is in`, `is return`, `is enum`, `is alias`, `is static`, `is const`, `is immutable`, `is shared`, and probably more, could be seen more like a post-fix operator, but would still be parsed as a binary `is`. Some of them make sense for both types and objects, where for objects, they just test the type, similar to how `sizeof` works: E.g., if `T` is a template type parameter and `t` is of type `T`, `T is const` is a synonym for `is(T == const)`, and `t is const` becomes `is(typeof(t) == const)`. Some of these, IMO, make sense only for types (e.g. `is class`), and some require an object, e.g. `is scope` or the parameter storage class tests `is ref`, `is in`, `is out`, `is return`. Some take a symbol such as `is enum` and `is alias`. Some of these group together: Type category tests, type constructor tests, and parameter storage class tests. Each category could be allowed to be OR-connected: `T is (class|interface)`. For that, I’d allow parentheses around single-keyword tests as well, to aid CTFE code generation, not because I’d expect someone to actually write `T is (class)`. Thinking about it, for template parameters, instead of `template Templ(T) if (T is (class|interface))` why not put the constraint directly next to `T`? As in: `template Templ(class|interface T)`; at least for aggregate categories that makes sense. --
[Issue 24490] Disallow unescaped literal $ in a Interpolation Expression Sequence
https://issues.dlang.org/show_bug.cgi?id=24490 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 24490] New: Disallow unescaped literal $ in a Interpolation Expression Sequence
https://issues.dlang.org/show_bug.cgi?id=24490
Issue ID: 24490
Summary: Disallow unescaped literal $ in a Interpolation
Expression Sequence
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
On [Interpolation Expression Sequence](https://dlang.org/spec/istring.html) It
says:
“A $ followed by any character other than a left parenthesis is treated as a
literal $ in the expression, there is no need to escape it.”
That is a bad idea. Just make $ without a following parenthesis an error. A D
programmer can easily escape it. Also, the fact that it has to be escaped makes
sense.
There are two good reasons:
1. If the string literal is changed later so that the unescaped $ happens to be
followed by an opening parenthesis, behavior changes.
2. It closes the door to introduce other uses for $ in IES literals forever
(or: without breakage).
For example, variable shorthands: In a lot of scripting languages, "This is my
$i-th attempt" puts the value of the variable `i` into the string. The same
literal in D (prefixed with i as `i""`) is legal and changing its meaning
further into the future is a bad idea. It rather have no meaning at all and be
i"This is my \$i-th attempt", or i"This is my $(i)-th attempt", which is what
the user probably wanted anyway.
Introducing variable shorthands later won’t make i"This is my $(i)-th attempt"
invalid.
I’d also suggest to require $ to be escaped in interpolated token sequence
strings. A backslash isn’t a valid token anyways, so in an `iq` string, \$
would be a special token that is translated to literal `$`, while unescaped $
would (for the time being) only be valid if a parenthesis follows.
About interpolated WYSIWYG strings, I’d go the same route as C# with `{{`
meaning a single `{` in an `@` string: Even here, `$` should be escaped,
however, because the main point of WYSIWYGs is that backslashes need no
escaping, my suggestion would be to require that a `$` is followed by a
parenthesis or another `$`, and double `$` means a single `$` in the string.
--
[Issue 21854] @live breaks foreach over integers
https://issues.dlang.org/show_bug.cgi?id=21854 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dmd pull request #16367 "fix bugzilla Issue 21854 - @live breaks foreach over integers" was merged into master: - d32f565093a4ec9bc9a7b92b23416b0df586d353 by Walter Bright: fix bugzilla Issue 21854 - @live breaks foreach over integers https://github.com/dlang/dmd/pull/16367 --
[Issue 24415] Can't call public function preceded by private template overload
https://issues.dlang.org/show_bug.cgi?id=24415 --- Comment #6 from Dlang Bot --- dlang/phobos pull request #8924 "Work around bugzilla issue 24415 - only doesn't work with elements with a copy constructor." was merged into stable: - 66bbf4dae038879d1ff66af3b7ab25ea66c8320d by Jonathan M Davis: Work around bugzilla issue 24415 - only doesn't work with elements with a copy constructor. Since the compiler is treating the auto-generated copy-constructor for OnlyResult as private (thus rendering it useless outside of std.range.package), this commit adds an explicit one and makes it public. Once the dmd bug has been fixed, the explicit copy constructor should be removed. https://github.com/dlang/phobos/pull/8924 --
[Issue 24492] New: Opt-in support for pointer write barriers
https://issues.dlang.org/show_bug.cgi?id=24492 Issue ID: 24492 Summary: Opt-in support for pointer write barriers Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: n...@geany.org In Nov 2022, Walter seems to be OK with *opt-in* pointer write barriers: https://forum.dlang.org/post/tjseq5$sj5$1...@digitalmars.com Adam D. Ruppe: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_10_31.html#thoughts-on-pointer-barriers Ate Eskola also posted this idea today: https://forum.dlang.org/post/dtsdzwydtcjoanboh...@forum.dlang.org Write barriers can enable different GC strategies, but the idea is write barriers would not be on by default because they would slow down non-GC code. --
[Issue 24492] Opt-in support for pointer write barriers
https://issues.dlang.org/show_bug.cgi?id=24492 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --
[Issue 24491] Introduce `is` [keyword] expressions
https://issues.dlang.org/show_bug.cgi?id=24491 Bolpat changed: What|Removed |Added Priority|P1 |P4 CC||qs.il.paperi...@gmail.com --
[Issue 24493] New: FreeBSD_14 version identifier missing
https://issues.dlang.org/show_bug.cgi?id=24493
Issue ID: 24493
Summary: FreeBSD_14 version identifier missing
Product: D
Version: D2
Hardware: All
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
On FreeBSD 14, this program
---
void main()
{
version (FreeBSD_14) pragma(msg, "14");
else version (FreeBSD_13) pragma(msg, "13");
else version (FreeBSD_12) pragma(msg, "12");
else version (FreeBSD_11) pragma(msg, "11");
else version (FreeBSD_10) pragma(msg, "10");
else version (FreeBSD_9) pragma(msg, "9");
else version (FreeBSD_8) pragma(msg, "8");
else static assert(false, "Unsupported version of FreeBSD");
}
---
prints out 11, so FreeBSD_14 is not being defined correctly. Presumably, it
just hasn't been added yet.
--
[Issue 24494] New: std.mmfile should take into account 256kb mapping in Windows kernel
https://issues.dlang.org/show_bug.cgi?id=24494 Issue ID: 24494 Summary: std.mmfile should take into account 256kb mapping in Windows kernel Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com As of Windows Internals 5, the cache manager will memory map on first read in 256kb chunks from a file into itself. std.mmfile does not mention this, nor takes advantage of this information. Instead preferring smaller amounts. --
