[Issue 24602] Internal compiler error: failed to detect static initialization of associative array
https://issues.dlang.org/show_bug.cgi?id=24602 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #16592 "Fix Bugzilla 24602 - Internal compiler error: failed to detect static…" was merged into stable: - 17200412f5d1ebcf73fca199d86aaba1ced1bdfe by Dennis Korpel: Fix Bugzilla 24602 - Internal compiler error: failed to detect static initialization of associative array https://github.com/dlang/dmd/pull/16592 --
[Issue 24615] ImportC can't import Python 3.12 header
https://issues.dlang.org/show_bug.cgi?id=24615 Atila Neves changed: What|Removed |Added Keywords||ImportC --
[Issue 24615] New: ImportC can't import Python 3.12 header
https://issues.dlang.org/show_bug.cgi?id=24615 Issue ID: 24615 Summary: ImportC can't import Python 3.12 header Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: atila.ne...@gmail.com // foo.d import python; // python.c #include % dmd -c -P-I/usr/include/python3.12 foo.d In file included from : /usr/include/dlang/dmd/importc.h:101:8: warning: undefining "__has_feature" 101 | #undef __has_feature |^ /usr/include/dlang/dmd/importc.h:104:8: warning: undefining "__has_extension" 104 | #undef __has_extension |^~~ /usr/include/linux/types.h(12): Error: __int128 not supported /usr/include/linux/types.h(13): Error: unsigned __int128 not supported --
[Issue 24583] di generator emits return scope and scope return in wrong order
https://issues.dlang.org/show_bug.cgi?id=24583 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16595 "Fix bugzilla 24583 - di generator emits return scope and scope return…" fixing this issue: - Fix bugzilla 24583 - di generator emits return scope and scope return in wrong order https://github.com/dlang/dmd/pull/16595 --
[Issue 12885] const union wrongly converts implicitly to mutable
https://issues.dlang.org/show_bug.cgi?id=12885 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #9 from Dlang Bot --- @ntrel created dlang/dmd pull request #16594 "Fix Bugzilla 12885 - const union wrongly converts implicitly to mutable" fixing this issue: - Fix Bugzilla 12885 - const union wrongly converts implicitly to mutable https://github.com/dlang/dmd/pull/16594 --
[Issue 24602] Internal compiler error: failed to detect static initialization of associative array
https://issues.dlang.org/show_bug.cgi?id=24602 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16592 "Fix Bugzilla 24602 - Internal compiler error: failed to detect static…" fixing this issue: - Fix Bugzilla 24602 - Internal compiler error: failed to detect static initialization of associative array https://github.com/dlang/dmd/pull/16592 --
[Issue 24587] Allow negated qualifiers in cast expressions
https://issues.dlang.org/show_bug.cgi?id=24587 --- Comment #2 from Bolpat --- I just found out `cast(const)` not only adds `const` if it’s not present, it also removes any other qualifiers. (In reply to RazvanN from comment #1) > I don't find this very useful. Not an argument. > It seems that we are complicating the type > system only to obtain something that is actually more confusing. The type system remains unchanged. It only adds a concise syntax to cast away specific qualifiers without having to query the type. You can argue the syntax is confusing. I don’t think it is. > cast() is > used to drop all qualifiers whereas if you want to keep some of them you can > just cast to the appropriate combination of qualifiers (i.e. cast(const > shared)). Yes, but that’s not easy. One has to know which qualifiers are present. In a template-context, one has to tediously query them, and in a non-template context, one has to look them up and repeat them, and if they change, too bad, the cast now does something unintended. > That way [with `cast(Quals)`] you know exactly what the type is at the cast > site, > whereas introducing the possibility to negate a single qualifier makes it > ambiguous with regards to what the type at the cast site is. When is that a use-case? When is “I don’t care what qualifiers a type has, make it XYZ” a use case? The only one I see is when you want to extract information of what template instance or whatnot something is, and qualifiers are in the way. I.e. in an unevaluated context. Of course, if you have a `const shared LongAndComplicated!(Template!Instance) x`, it’s easy to write `cast(const)x`, but here I have to look up its type, see that it’s `const` and repeat(!) that qualifier. What I want is not repeat anything and express intent, i.e. the intent to remove `shared`. What did a `cast(const)` intend? Add `const`? Remove something else and retain `const`? Who knows. > Also, can you provide a concrete code example where this is useful? I can’t because I don’t work professionally with D. Any example I’d provide would be dismissed as “toy project example” anyways. > It seems > to me that this is a theoretical proposal without any actual practical > usefulness. Among the negated qualifier casts, most definitely `cast(!shared)` would be useful. If you `cast()`, you might end up casting away `const` and mutate stuff that you shouldn’t. For `cast(!shared)` on a `const shared` type object, I see two uses: 1. You intend to read, then you lock a mutex, `cast(!shared)` and do the read while being assured by the compiler you’re not mutating anything as `const` (or anything else) goes nowhere. Also, `const` member functions are used instead of non-`const` ones. 2. You intend to write, and because `cast(!shared)` leaves `const` intact, you’ll get a compile-error instead of UB if you accidentally write to something that’s `const`. I don’t know where in run-time code you want to override all qualifiers. In general, I’d assume you always want to add or remove specific ones. E.g. template code can’t really use `cast(const)` not because it adds `const` (that’s obvious), but because it removes `shared` when it’s present and does so “silently”. --
[Issue 21644] spam
https://issues.dlang.org/show_bug.cgi?id=21644 anonymous4 changed: What|Removed |Added URL|https://www.fieldengineer.c | |om/blogs| Summary|job search engines |spam --
[Issue 24588] spam
https://issues.dlang.org/show_bug.cgi?id=24588 anonymous4 changed: What|Removed |Added URL|http://www.veronapress.com/ | |contributed/you-can-now-buy | |-magic-mushrooms-online-100 | |-legal/article_40c42984-e7d | |4-11ee-b152-5778bdfa4e1d.ht | |ml | Summary|Buy Psilocybin Magic|spam |Mushrooms | --
[Issue 24605] spam
https://issues.dlang.org/show_bug.cgi?id=24605 anonymous4 changed: What|Removed |Added Keywords|accepts-invalid | URL|https://www.veronapress.com | |/contributed/disposable-car | |ts-the-5-best-brands-for-sa | |le/article_e95bfdee-f1c3-11 | |ee-8fe8-fb94a994b030.html | Summary|Disposable Carts|spam --
[Issue 23797] Improve type-testing `is` expressions
https://issues.dlang.org/show_bug.cgi?id=23797 --- Comment #1 from Bolpat --- As for the right-hand side of `is(Type == Keyword)` for function pointer and delegate types, it also makes sense to ask if they’re carrying attributes. The keyword attributes should be allowed, but I think also user-defined ones should be allowed. Also visibility can be allowed for any symbols. The same for the simplified `is …` syntax. `DG is @nogc` is clear to read. --
[Issue 24608] spam
https://issues.dlang.org/show_bug.cgi?id=24608 anonymous4 changed: What|Removed |Added Status|NEW |RESOLVED URL|https://www.themountainmail | |.com/contributed/article_58 | |eb12f8-e7c9-11ee-8f71-6be28 | |c8df8d4.html| Resolution|--- |MOVED Summary|Magic Mushrooms |spam --
[Issue 24611] Cannot explicitly instantiate template function with `auto ref`
https://issues.dlang.org/show_bug.cgi?id=24611 --- Comment #1 from Bolpat --- Grammar change needed for the suggested fix: ```diff TemplateArgument: Type + ref Type AssignExpression Symbol ``` --
[Issue 24614] Can’t throw in -betterC mode with -preview=dip1008 (@nogc Exceptions)
https://issues.dlang.org/show_bug.cgi?id=24614 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added Status|NEW |RESOLVED CC||alphaglosi...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from Richard (Rikki) Andrew Cattermole --- D classes depend upon druntime. Runtime exceptions ala ``Throwable`` hierarchy depend upon druntime. As of right now this is expected and correct behavior for runtime exceptions to not work in -betterC. There is a high desire to see some variant of value based sumtype returns in the language hooked into ``throw`` and ``catch`` that do not depend upon druntime, however that is not currently in the DIP queue due to a dependency upon sumtypes. --
[Issue 24614] New: Can’t throw in -betterC mode with -preview=dip1008 (@nogc Exceptions)
https://issues.dlang.org/show_bug.cgi?id=24614
Issue ID: 24614
Summary: Can’t throw in -betterC mode with -preview=dip1008
(@nogc Exceptions)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
Maybe this is invalid, but the Description section of DIP 1008 ("Exceptions and
@nogc") gives the impression that this should be possible.
Quote from DIP 1008:
> The issue is [exceptions being GC allocated] […] prevents building D programs
> that do not link in the GC runtime.
The prime example for D programs without GC runtime are `-betterC` programs.
That `-betterC` mode does not allow for Exceptions may be due to reasons other
than being unable to GC-allocate them, but maybe not, and therefore this bug
report.
--
[Issue 24607] __traits(isDeprecated, ...) result incorrect on an alias member
https://issues.dlang.org/show_bug.cgi?id=24607 Nick Treleaven changed: What|Removed |Added Summary|__traits(isDeprecated, ...) |__traits(isDeprecated, ...) | not working on a member|result incorrect on an ||alias member --
[Issue 24607] __traits(isDeprecated, ...) not working on a member
https://issues.dlang.org/show_bug.cgi?id=24607 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Severity|enhancement |normal --- Comment #1 from Nick Treleaven --- > pragma(msg, __traits(isDeprecated, A, "foo"))); The docs say it takes only one argument (like other trait docs), though actually the result is true if both A and "foo" are deprecated. https://dlang.org/spec/traits.html#isDeprecated > Should support checking on member > pragma(msg, __traits(isDeprecated, A.bar3)); That is actually the correct syntax, but the result is false when it should be true. (I am adding a member symbol example in this pull https://github.com/dlang/dlang.org/pull/3851). --
[Issue 17148] Copying from const(void)[] to void[] breaks immutable
https://issues.dlang.org/show_bug.cgi?id=17148 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16583 "Fix Bugzilla 17148 - Copying from const(void)[] to void[] breaks immu…" was merged into master: - e93d798c2bccffed4c66bd797e10e32cdab22d82 by Nick Treleaven: Fix Bugzilla 17148 - Copying from const(void)[] to void[] breaks immutable https://github.com/dlang/dmd/pull/16583 --
