[Issue 14150] /library/ Documentation Pages be Brokened
https://issues.dlang.org/show_bug.cgi?id=14150 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Vladimir Panteleev --- https://github.com/D-Programming-Language/dlang.org/pull/901 --
[Issue 14275] Qualified package protection for aggregate member doesn't work
https://issues.dlang.org/show_bug.cgi?id=14275 --- Comment #2 from Dicebot --- https://github.com/D-Programming-Language/dmd/pull/4476 --
[Issue 14275] Qualified package protection for aggregate member doesn't work
https://issues.dlang.org/show_bug.cgi?id=14275 Dicebot changed: What|Removed |Added Keywords||pull --
[Issue 14275] Qualified package protection for aggregate member doesn't work
https://issues.dlang.org/show_bug.cgi?id=14275 --- Comment #1 from Dicebot --- Bug is in usage of this access.c function: 265 / 266 * Determine if scope sc has package level access to s. 267 */ 268 bool hasPackageAccess(Scope *sc, Dsymbol *s) It is getting called for aggregate symbol too, even if it is public itself, assuming package protection. PR incoming. --
[Issue 14275] New: Qualified package protection for aggregate member doesn't work
https://issues.dlang.org/show_bug.cgi?id=14275
Issue ID: 14275
Summary: Qualified package protection for aggregate member
doesn't work
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
>From http://forum.dlang.org/post/wvfytekpmzeegeuvn...@forum.dlang.org
module A.B.Foo;
import core.stdc.stdio : printf;
struct Foo {
package(A) void foo() {
printf("Hallo\n");
}
}
package(A) void bar() {
printf("Hallo\n");
}
and
module A.C.Bar;
import A.B.Foo;
void main() {
Foo f;
f.foo();
bar();
}
The call of bar() works, but f.foo() triggers the error:
Error: struct A.B.Foo.Foo member foo is not accessible
--
[Issue 11530] need gdb test suite
https://issues.dlang.org/show_bug.cgi?id=11530 Martin Nowak changed: What|Removed |Added Summary|need gdb dwarf test suite |need gdb test suite --
[Issue 14274] New: tools/update.sh must install and use dmd 2.066.1 if not present
https://issues.dlang.org/show_bug.cgi?id=14274 Issue ID: 14274 Summary: tools/update.sh must install and use dmd 2.066.1 if not present Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: and...@erdani.com Trying to install dmd HEAD on a fresh ubuntu machine now requires a preexisting installation of dmd 2.066.1. tools/update.sh should detect if dmd is missing and automatically clone it and use it (similar to dlang.org/posix.mak). --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #19 from Dicebot --- (In reply to Ali Cehreli from comment #18) > I think this boils down to whether an enum's conversion to its base type is > an implicit cast (an rvalue), versus the enum itself (an lvalue). (Steven > says it's the latter.) > > Also, does anyone know what bug fix this was originally about? Perhaps that > bug was invalid? > > Ali Kenji is likely to know but I will do the bisection if he won't chime in soon :) --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #18 from Ali Cehreli --- I think this boils down to whether an enum's conversion to its base type is an implicit cast (an rvalue), versus the enum itself (an lvalue). (Steven says it's the latter.) Also, does anyone know what bug fix this was originally about? Perhaps that bug was invalid? Ali --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #17 from Dicebot --- Also, please, can we discuss the final switch / enum operation issue somewhere else? It is unrelated and only makes more difficult to follow relevant discussion. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269
--- Comment #16 from Dicebot ---
(In reply to Kenji Hara from comment #8)
> (In reply to Dicebot from comment #7)
> > unless it compromises program correctness (memory corruption, wrong
> > codegen etc).
>
> In 2.066 and earlier, the program correctness had been compromised and
> generated wrong code. So the bug should be fixed immediately in the 2.067
> release.
>
> I'm not sure why you think the bug is trivial.
Slightly modified version of original snippet:
enum Bits: ulong
{
none = 0
}
void hasBit(ref ulong rBits,)
{
rBits = 424242;
}
void main()
{
Bits bits;
hasBit(bits);
assert(bits == 424242);
}
What in your opinion compromises program correctness here? This code works in
2.066 and works as intended by author, reinterpreting memory taken by `bits` as
ulong (as those are binary identical). There is not undefined behavior, no
memory corruption, no bug in application logic. Only issue is the fact that D
type system was not supposed to work in such permissive way.
--
[Issue 14273] New: Predicates for static assert pass depending on order of asserts
https://issues.dlang.org/show_bug.cgi?id=14273
Issue ID: 14273
Summary: Predicates for static assert pass depending on order
of asserts
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
template canBeAlias(T...)
if (T.length == 1)
{
enum canBeAlias = is(typeof({ alias _ = T[0]; }));
}
static assert(canBeAlias!(canBeAlias!canBeAlias));
//Error: static assert (!true) is false
static assert(!canBeAlias!true);
If we switch the order:
static assert(!canBeAlias!true);
//Error: static assert (canBeAlias!(true)) is false
static assert(canBeAlias!(canBeAlias!canBeAlias));
--
[Issue 13681] @safe empty writeln
https://issues.dlang.org/show_bug.cgi?id=13681 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e601077b8618c595fa51807a85c54f8c4e32ca9a make 0-arg writeln @trusted: Fix Issue 13681 https://github.com/D-Programming-Language/phobos/commit/38453e82adfdcba8d5d817fd8404acf8edeb04f3 Merge pull request #3046 from John-Colvin/patch-13 make 0-arg writeln @trusted: Fix Issue 13681 take 2 --
[Issue 13681] @safe empty writeln
https://issues.dlang.org/show_bug.cgi?id=13681 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14272] DMD segfault in in Dsymbol::checkDeprecated(Loc, Scope*) on possibly invalid code
https://issues.dlang.org/show_bug.cgi?id=14272 Nicolas Sicard changed: What|Removed |Added Keywords||ice --
[Issue 14272] New: DMD segfault in in Dsymbol::checkDeprecated(Loc, Scope*) on possibly invalid code
https://issues.dlang.org/show_bug.cgi?id=14272
Issue ID: 14272
Summary: DMD segfault in in Dsymbol::checkDeprecated(Loc,
Scope*) on possibly invalid code
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dran...@gmail.com
---
struct A(int tag)
{
enum int tag = tag;
}
alias A1 = A!1;
---
--
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #15 from monkeywork...@hotmail.com --- (In reply to Dicebot from comment #3) > It shouldn't compile but, same as with other such changes, it needs > deprecation stage. That would imply that deprecations are ever done in D ;-) How long has it been now since it was decided that delete will be deprecated? --
[Issue 14271] New: DMD 2.067-b4: strange behaviour of new package syntax
https://issues.dlang.org/show_bug.cgi?id=14271
Issue ID: 14271
Summary: DMD 2.067-b4: strange behaviour of new package syntax
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: rswhi...@gmail.com
Code:
module A.B.Foo;
import core.stdc.stdio : printf;
struct Foo {
package(A) void foo() {
printf("Hallo\n");
}
}
package(A) void bar() {
printf("Hallo\n");
}
and
module A.C.Bar;
import A.B.Foo;
void main() {
Foo f;
f.foo();
bar();
}
The call to bar works, but the call to foo returns the following error message:
Error: struct A.B.Foo.Foo member foo is not accessible
--
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 --- Comment #12 from Steven Schveighoffer --- (In reply to Denis Shelomovskij from comment #11) > > But htis issue even not about this. AA's key type is `const char[]` and > `char[]` is implicitly convertible to `const char[]` anyway. So this issue > is about error in type checking and error in error message. ) OK, I didn't notice that aspect, yes that is even more perplexing than the issue of requiring const. In fact, a library-based type would solve that too :) --
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 --- Comment #11 from Denis Shelomovskij --- (In reply to Steven Schveighoffer from comment #10) > (In reply to Denis Shelomovskij from comment #9) > > > I can't believe anyone can accept bahaviour shown in Comment 6. > > I agree with you, and I have argued as much in the NG. The compiler should > either enforce immutability, or not care. Enforcing const has all of the > annoyance, with none of the guarantee. But htis issue even not about this. AA's key type is `const char[]` and `char[]` is implicitly convertible to `const char[]` anyway. So this issue is about error in type checking and error in error message. ) --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #14 from Steven Schveighoffer --- (In reply to Ali Cehreli from comment #13) > If the implicitly-converted value is an rvalue (as it is), where is it > stored to take the reference of? No, an enum is a derivative. It's just like you can pass a class reference as Object without consequence. Where you run into issues is if you have a REFERENCE to a class reference. So the implicit casting is not because enum converts to long (for example), it's because enum IS a long. And in addition, enum does not allow you to really treat it any differently than the base type. You can't add any features that "wouldn't work" for a long, for instance. --
[Issue 12420] [AA] Can't set associative array with array as key value using key type
https://issues.dlang.org/show_bug.cgi?id=12420 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #10 from Steven Schveighoffer --- (In reply to Denis Shelomovskij from comment #9) > I can't believe anyone can accept bahaviour shown in Comment 6. I agree with you, and I have argued as much in the NG. The compiler should either enforce immutability, or not care. Enforcing const has all of the annoyance, with none of the guarantee. However, practicality dictates that we cannot force immutability on everyone who wants to use an AA. In particular, immutable classes are nearly useless. I would like to see AA's remove the const enforcement. I'm not sure how I feel about immutable enforcement, but it would be a nice option to add once AA's are fully library types. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #12 from Steven Schveighoffer --- (In reply to Jonathan M Davis from comment #10) > Personally, I think that all operations that the compiler can't guarantee > will result in a valid enum value for an enum type should result in the base > type of the enum rather than the enum type - without that, stuff like final > switch is completely broken - but there's definitely dissent on that, and > it's been argued about in the newsgroup. The OP's case has nothing to do with final switch. The reality is that people use enums for reasons other than final switch or even just individual values (e.g. bitfields). But I don't see how final switch can be "fixed", I can't imagine a case where it's worth not checking for the default case in a final switch. --
[Issue 14264] Destructor not called when struct is returned from a parenthesis-less function call
https://issues.dlang.org/show_bug.cgi?id=14264 --- Comment #8 from Ketmar Dark --- (In reply to Kenji Hara from comment #7) > If you consider to start contribution to the dmd codebase for the bugfix, > It's very glad to us. i'm slowly working on my "aliced" patchset, developing deeper understanding of codebase on my way. when i see the bug in DMD, it affects both DMD and Aliced, so i'm trying to at least localise it. writing my findings here, by the way, greatly helps, as usually someone more knowledgeable than me tells me which of my assumptions were correct and which were wrong. thank you and all other people for that. sadly, i don't want to use github, so i can't actively contribute. but i like to read your patches (and i usually incorporating most of them into Aliced almost immediately ;-), sometimes even a simple fix makes "aha! so *that* is the way it supposed to work!" --
[Issue 14267] [REG2.067beta2] ICE when determining if a function can be inlined
https://issues.dlang.org/show_bug.cgi?id=14267 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e5e7ddca3fd90a8fc473a594efd9204fc6818f73 fix Issue 14267 - ICE when determining if a function can be inlined https://github.com/D-Programming-Language/dmd/commit/ee24a3e7e7123925fa6d6f7569115ed2e1435718 Merge pull request #4471 from 9rnsr/fix14267 [REG2.067beta2] Issue 14267 - ICE when determining if a function can be inlined --
[Issue 14264] Destructor not called when struct is returned from a parenthesis-less function call
https://issues.dlang.org/show_bug.cgi?id=14264 --- Comment #7 from Kenji Hara --- (In reply to Ketmar Dark from comment #6) > > The wrong call order has been there before the my first contribution for dmd > > codebase. > > to be clear: i didn't mean that this was the code you wrote. what i mean is > that you have excellent and very deep understanding of compiler code, so you > can answer on such simple questions as mine in no time. > > so "i'm not Kenji" means that "i don't have Kenji's understanding of the > codebase". ;-) > > sorry if it looks like i'm blaiming you. it was the exactly opposite, i was > praising your knowledge and contributions. ;-) Don't worry, I'm precisely understanding your intention of the comment. I meant that I didn't notice the bug until now, and I'm not perfect. If you consider to start contribution to the dmd codebase for the bugfix, It's very glad to us. --
[Issue 14264] Destructor not called when struct is returned from a parenthesis-less function call
https://issues.dlang.org/show_bug.cgi?id=14264 --- Comment #6 from Ketmar Dark --- > The wrong call order has been there before the my first contribution for dmd > codebase. to be clear: i didn't mean that this was the code you wrote. what i mean is that you have excellent and very deep understanding of compiler code, so you can answer on such simple questions as mine in no time. so "i'm not Kenji" means that "i don't have Kenji's understanding of the codebase". ;-) sorry if it looks like i'm blaiming you. it was the exactly opposite, i was praising your knowledge and contributions. ;-) --
[Issue 9449] Static arrays of 128bit types segfault on initialization. Incorrect calling of memset128ii.
https://issues.dlang.org/show_bug.cgi?id=9449 Martin Nowak changed: What|Removed |Added Status|REOPENED|RESOLVED CC||c...@dawg.eu Resolution|--- |FIXED --- Comment #35 from Martin Nowak --- (In reply to Temtaime from comment #34) > Hi ! > I've hit this bug with GIT HEAD dmd and vibe.d built with win32driver. > > I've disassembled .exe and it crashes with movdqa, the address is misaligned. > I've changed movdqa opcode to movdqu in dmd's code and all works OK now. Works with 2.067.0-b4, closing this. Please open a new ticket if you have this problem on a win32 machine. --
[Issue 9397] Size error with struct with ctor and self-typed nested enum
https://issues.dlang.org/show_bug.cgi?id=9397 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 6766 *** --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #11 from bearophile_h...@eml.cc --- (In reply to Jonathan M Davis from comment #10) > Personally, I think that all operations that the compiler can't guarantee > will result in a valid enum value for an enum type should result in the base > type of the enum rather than the enum type - without that, stuff like final > switch is completely broken - but there's definitely dissent on that, and > it's been argued about in the newsgroup. I agree with Jonathan, of course. Fixing final switch is important. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #10 from Jonathan M Davis --- Personally, I think that all operations that the compiler can't guarantee will result in a valid enum value for an enum type should result in the base type of the enum rather than the enum type - without that, stuff like final switch is completely broken - but there's definitely dissent on that, and it's been argued about in the newsgroup. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #9 from Steven Schveighoffer --- So if we examine why we don't allow ref to implicitly convert, it mostly has to do with preventing one from replacing the data referred to with a value that's valid for the base type, but invalid for the derived type. This is especially important for classes and pointers, because the pointer means completely different things as a base or derived type. However, we have somewhat of a unique situation with enum: 1. An enum is GUARANTEED to be the same size as it's "base" type, and have the same representation. 2. An enum is GUARANTEED to behave exactly the same way in terms of operators as its base type. 3. An enum is frequently used as a simple typedef, allowing one to define a new type of "int" e.g. with extra static values. I think you can make cases either way. The deprecation of typedef has kind of forced people into using enum as a "poor man's typedef". But clearly, there is no inherent danger in allowing ref of base type to bind to an enum, as the compiler already cannot make any assumptions about enums that are different from the base type. I would tend to say we should revert the restriction, even though I see and somewhat agree with the reasoning behind it. It seems inconsistent to say "We allow you to do enumvar |= somelong" and still type it as the enum, but we can't allow you arbitrary access via long. I would love to see a mechanism to allow enums to be further classified. In other words, what is allowed with this enum type? How is it intended to be used? This would give more clarity to how enum types are supposed to be used, and how the compiler can restrict usage. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #8 from Kenji Hara --- (In reply to Dicebot from comment #7) > unless it compromises program correctness (memory corruption, wrong > codegen etc). In 2.066 and earlier, the program correctness had been compromised and generated wrong code. So the bug should be fixed immediately in the 2.067 release. I'm not sure why you think the bug is trivial. --
[Issue 14258] SIGSEGV in dpldocs
https://issues.dlang.org/show_bug.cgi?id=14258 --- Comment #10 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/cc8d8123ef0dff1705e729d1faad2b710639771f Merge pull request #925 from s-ludwig/master Issue 14258 - SIGSEGV in dpldocs --
[Issue 14258] SIGSEGV in dpldocs
https://issues.dlang.org/show_bug.cgi?id=14258 --- Comment #9 from Sönke Ludwig --- Hm, you are right of course, totally forgot about that. --
[Issue 14258] SIGSEGV in dpldocs
https://issues.dlang.org/show_bug.cgi?id=14258 --- Comment #8 from Vladimir Panteleev --- On Linux, what usually happens upon attempting to commit (write to) a page that has been overcommitted (COW of a zero page), when there are no free pages and no pages to swap or reclaim, the OOM killer is invoked and the most memory-hungry process dies with a SIGSEGV. --
[Issue 14258] SIGSEGV in dpldocs
https://issues.dlang.org/show_bug.cgi?id=14258 --- Comment #7 from Sönke Ludwig --- My systems all have limited swap space - what would the OS do when all that memory is filled with data (note that the array that is piled up is actually written to)? I've added the termination conditions now and will file a PR as soon as the new DDOX version is up on code.dlang.org. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #7 from Dicebot --- > "For the stability, we have to defer to fix bug by adding deprecation stage" Yes, unless it compromises program correctness (memory corruption, wrong codegen etc). It is a normal practice in majority of established languages I am aware of. There are several reasons for such conservative approach: 1) make possible to use critical fixes immediately without scheduling time for addressing minor ones 2) make possible to use new version even if dependencies have not been updated (and are out of your control) 3) give easy quick estimate of what full upgrade will take effort-wise It all evolves around the idea of introducing time gap when everyone becomes aware of the issue but is not yet forces to address it immediately to use the compiler. For example, our internal D codebase consists from dozens of different projects with independent maintainers and complicated dependency chains. Any breaking change means that upgrade effort needs to be done in sync between all those projects, taking away time from possibly urgent business matters (and it is almost impossible to find a single moment when none of projects has any urgent matters). Breaking fix needs to address a very serious problem to be viewed as worth such trouble among the developers. Adding deprecation stage allows everyone to switch to new compiler with minor effort and address all deprecation messages on per-project basis as schedule for this specific project allows. I foresee this becoming a major issue once our D2 usage leaves experimental stage - this is why I am starting to make so much fuss early. I am very sorry if this sounds overly demanding but current state of affairs is really problematic. --
[Issue 14258] SIGSEGV in dpldocs
https://issues.dlang.org/show_bug.cgi?id=14258 --- Comment #6 from Vladimir Panteleev --- Except for address space exhaustion, OutOfMemoryError will never realistically occur in any OS with overcommit. --
[Issue 14258] SIGSEGV in dpldocs
https://issues.dlang.org/show_bug.cgi?id=14258 --- Comment #5 from Sönke Ludwig --- The crash occurs because the proper termination conditions for recursive macro calls are not implemented. I'll do that. There could be an additional issue in the GC/array implementation, though, as I would have expected an OutOfMemoryError instead of a segmentation fault (except if the segfault is caused by a stack overflow). --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #6 from Kenji Hara --- (In reply to Dicebot from comment #5) > And this attitude needs to change if D wants to be > considered stable for production usage for wider audience. "For the stability, we have to defer to fix bug by adding deprecation stage"? Deferring bugfix will clearly make compiler unstable. It sounds unreasonable to me. --
[Issue 14235] [REG2.066] full-qualified template instantiation misses its error location
https://issues.dlang.org/show_bug.cgi?id=14235 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/643ca3f02c237631aa4415386e8abd253f4d66bf Merge pull request #4452 from 9rnsr/fix14235 [REG2.066] Issue 14235 - full-qualified template instantiation misses its error location --
[Issue 13116] Should not be able to return ref to 'this'
https://issues.dlang.org/show_bug.cgi?id=13116 --- Comment #10 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4d7040a5296a3a5e155b1dd37c0fbad480a2061b Merge pull request #4463 from MartinNowak/revert3761 Revert "Merge pull request #3761 from quickfur/issue13116" --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 github-bugzi...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 14232] redundant attribute 'const'
https://issues.dlang.org/show_bug.cgi?id=14232 --- Comment #20 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/53c5b59ca83e471fea6e4464862b39e62df0f335 Merge pull request #4458 from mihails-strasuns-sociomantic/redundant-attrib-deprec [REG] fix Issue 14232 : redundant attribute 'const' --
[Issue 14233] [REG2.067b2] Can't build Algebraic!(This[]) anymore
https://issues.dlang.org/show_bug.cgi?id=14233 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/35ccb6aa9360f3d8cd63cb31ea25e7a596546a96 Merge pull request #3030 from 9rnsr/fix14233 [REG2.067b2] Issue 14233 - Can't build Algebraic!(This[]) anymore --
[Issue 14198] [REG2.067a] Link failure with Variant
https://issues.dlang.org/show_bug.cgi?id=14198 --- Comment #11 from github-bugzi...@puremagic.com --- Commits pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/4dfde4caab8fb9e12c035784d5ddf33925ea3526 Merge pull request #3038 from WalterBright/fix14198 fix Issue 14198 - [REG2.067a] Link failure with Variant https://github.com/D-Programming-Language/phobos/commit/b2bbff77fa9eebb072d9c39ee505f9db4f24d997 Merge pull request #3044 from MartinNowak/fixup3038 fixup #3038 add reference to bugzilla issue 14198 --
[Issue 13390] [REG2.066] std.range.cycle ctor fails when empty input passed
https://issues.dlang.org/show_bug.cgi?id=13390 --- Comment #12 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e2d774fc85804ce1eabdaf5f526fb287a2d48417 Merge pull request #3001 from kuettler/fix13390 Fix Issue 13390 - Be explicit about non-empty input and fail early --
[Issue 14213] Strange deprecated message in std.typecons.Proxy with using method
https://issues.dlang.org/show_bug.cgi?id=14213 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to 2.067 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b8627ba4f639f57a079fbba2b93a913d91404f6b Merge pull request #3043 from 9rnsr/fix14213 [REG2.067a] Issue 14213 - Strange deprecated message in std.typecons.Proxy with using method --
[Issue 14206] cdouble is broken
https://issues.dlang.org/show_bug.cgi?id=14206 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/efabbd365e4b46337135240f18ad96fd6d78c921 std.math №3: conj for double and float Issue 14206 workaround --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #5 from Dicebot --- > It's quite normal It is common, not normal. And this attitude needs to change if D wants to be considered stable for production usage for wider audience. Fortunately, so far seem that Martin shares this opinion and we may get a more reasonable approach in this release. This fix breaks 100% working code with no preliminary deprecation warning. Change itself may be completely justified on its own but not justified enough to break things _immediately_. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #4 from Jonathan M Davis --- (In reply to Dicebot from comment #3) > It shouldn't compile but, same as with other such changes, it needs > deprecation stage. Deprecation is only done with feature changes. It's quite normal for "accepts-invalid" bugs to be fixed and just break existing code, because the code was considered broken to begin with. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 ncras...@gmail.com changed: What|Removed |Added CC||ncras...@gmail.com --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 Dicebot changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #3 from Dicebot --- It shouldn't compile but, same as with other such changes, it needs deprecation stage. --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 monkeywork...@hotmail.com changed: What|Removed |Added Summary|Enum is not implicitly |Enum is not implicitly |converted to base type |converted to base type when ||using ref --
[Issue 14269] Enum is not implicitly converted to base type when using ref
https://issues.dlang.org/show_bug.cgi?id=14269 --- Comment #2 from monkeywork...@hotmail.com --- According to Jonathan Davis it should not compile, as there are no implicit conversions with ref. It *is* a regression in behaviour, though. --
[Issue 14269] Enum is not implicitly converted to base type
https://issues.dlang.org/show_bug.cgi?id=14269 Orvid King changed: What|Removed |Added CC||blah38...@gmail.com --- Comment #1 from Orvid King --- I would argue that it shouldn't compile, but I'm a weird one. --
[Issue 14269] New: Enum is not implicitly converted to base type
https://issues.dlang.org/show_bug.cgi?id=14269
Issue ID: 14269
Summary: Enum is not implicitly converted to base type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
The following code compiles with 2.066.1 and lower but does not compile with
2.067 Beta 3.
enum Bits: ulong
{
none = 0
}
bool hasBit(ref ulong rBits, ulong rBit)
{
return cast(bool)(rBits & rBit);
}
void main()
{
Bits bits;
hasBit(bits, Bits.none);
}
--
