[Issue 18921] make core.internal.hash cater to memberwise hash chaining
https://issues.dlang.org/show_bug.cgi?id=18921 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/ea2a844863bb00d7e9313f51ae19f6a31aa555e6 Fix Issue 18921 - make core.internal.hash cater to memberwise hash chaining https://github.com/dlang/druntime/commit/ba4c59799eeebc969ced95de34cd4203c8ec2254 Merge pull request #2198 from n8sh/core-hash-18921 Fix Issue 18921 - make core.internal.hash cater to memberwise hash chaining --
[Issue 18921] make core.internal.hash cater to memberwise hash chaining
https://issues.dlang.org/show_bug.cgi?id=18921 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19043] Incorrect mangling for extern(C++) const template parameter on windows
https://issues.dlang.org/show_bug.cgi?id=19043 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/09921ce45c1e4f12e5564b47579b2f052f86f76a Fix issue 19043 https://github.com/dlang/dmd/commit/3349c52b59fd9201fc49a6f2440311974c5dabc8 Merge pull request #8432 from thewilsonator/issue19043 Fix issue 19043 - Incorrect mangling for extern(C++) const template parameter on windows merged-on-behalf-of: Mathias LANG --
[Issue 19043] Incorrect mangling for extern(C++) const template parameter on windows
https://issues.dlang.org/show_bug.cgi?id=19043 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19014] Compiler imports symbols that aren't actually imported.
https://issues.dlang.org/show_bug.cgi?id=19014 --- Comment #6 from Mike Franklin --- This issue is currently blocking https://github.com/dlang/druntime/pull/ I don't want to close this until that change is possible. It's not currently possible because the compiler does not emit an error for the scenario in Comment #0. After the deprecation period has expired, we can emit a compiler error, and then we can continue with https://github.com/dlang/druntime/pull/ I don't want to close this until https://github.com/dlang/druntime/pull/ can be implemented. --
[Issue 13165] Using -profile does extra control flow analysis, leading to spurious statement is not reachable warning
https://issues.dlang.org/show_bug.cgi?id=13165
--- Comment #3 from Mathias LANG ---
Renamed the issue, as an extra case was reported here:
https://github.com/dlang/phobos/pull/6621#issuecomment-401980976
It seems the compiler is now able to propagate the fact that a function never
returns, e.g.:
```
struct S
{
@trusted void error(string msg)
{
throw new Exception("");
}
void fun2(){}
void fun1()
{
error("");
fun2;
}
}
```
Leads to a warning.
--
[Issue 13165] Using -profile does extra control flow analysis, leading to spurious statement is not reachable warning
https://issues.dlang.org/show_bug.cgi?id=13165 Mathias LANG changed: What|Removed |Added CC||pro.mathias.l...@gmail.com Summary|Spurious "Warning: |Using -profile does extra |statement is not reachable" |control flow analysis, |with -profile, If return|leading to spurious |statement exists in void|statement is not reachable |main() |warning --
[Issue 18250] deprecate + transition=complex should check whether the templates are instantiated from a deprecated scope
https://issues.dlang.org/show_bug.cgi?id=18250 greenify changed: What|Removed |Added Status|NEW |RESOLVED CC||greeen...@gmail.com Resolution|--- |FIXED --- Comment #1 from greenify --- Working since a while, but somehow this wasn't auto-closed. https://run.dlang.io/is/xEdylU --
[Issue 18251] deprecate + transition=complex shouldn't look at functions with non-matching if constraints
https://issues.dlang.org/show_bug.cgi?id=18251 greenify changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18251] deprecate + transition=complex shouldn't look at functions with non-matching if constraints
https://issues.dlang.org/show_bug.cgi?id=18251 greenify changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from greenify --- Fixed since a while, but somehow this wasn't auto-closed. https://run.dlang.io/is/IM7H7c --
[Issue 8172] OSX: symbols mangled on gdb,ggdb,cgdb,lldb but not on ubuntu; no line numbers on stacktraces
https://issues.dlang.org/show_bug.cgi?id=8172 greenify changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #15 from greenify --- With 2.081 (https://dlang.org/changelog/2.081.0.html), line numbers in stack traces finally come to OSX: https://dlang.org/changelog/2.081.0.html#backtrace_debug_info_macos On Linux they have been working for a while, but there were some issues with PIC which have been fixed in 2.081 too. --
[Issue 18542] DMD could generate better assembly for common range check idioms
https://issues.dlang.org/show_bug.cgi?id=18542 greenify changed: What|Removed |Added Keywords||performance CC||greeen...@gmail.com --
[Issue 14003] fork() on MacOS X 10.10.1 results in a core.exception.InvalidMemoryOperationError@(0)
https://issues.dlang.org/show_bug.cgi?id=14003 greenify changed: What|Removed |Added CC||chang...@gmail.com --- Comment #1 from greenify --- *** Issue 15511 has been marked as a duplicate of this issue. *** --
[Issue 15511] fork: Invalid memory operation
https://issues.dlang.org/show_bug.cgi?id=15511 greenify changed: What|Removed |Added Status|NEW |RESOLVED CC||greeen...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from greenify --- *** This issue has been marked as a duplicate of issue 14003 *** --
[Issue 18942] core.internal.hash can take advantage of alignment info on non-x86
https://issues.dlang.org/show_bug.cgi?id=18942 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17833] compiling dmd on x86 linux fails
https://issues.dlang.org/show_bug.cgi?id=17833 greenify changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #4 from greenify --- Hmm building DMD on Linux 32 works on our CIs (e.g. https://auto-tester.puremagic.com/platform-history.ghtml?projectid=1=Linux_32), so I'm not sure what this is related to. The dmd-cxx branch was just an experiment, but it was never fully finished. Do you still get a segfault when using AUTO_BOOTSTRAP=1? (since 2.081 at least 2.074 is required to build DMD) --
[Issue 18942] core.internal.hash can take advantage of alignment info on non-x86
https://issues.dlang.org/show_bug.cgi?id=18942 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/ff171a8d3febf19002ae0371eb76a46cd4b548f8 Fix Issue 18942 - core.internal.hash can take advantage of alignment info on non-x86 https://github.com/dlang/druntime/commit/892c79280d761bb6048fe5a16b389e4154bcfb38 Merge pull request #2209 from n8sh/core-hash-18942 Fix Issue 18942 - core.internal.hash can take advantage of alignment info on non-x86 merged-on-behalf-of: Sebastian Wilzbach --
[Issue 18623] Documented unittest should not allow private symbol access
https://issues.dlang.org/show_bug.cgi?id=18623 --- Comment #6 from greenify --- FWIW the tools extractor that is used by Phobos is now on dub: https://code.dlang.org/packages/dtools dub fetch dtools dub run dtools:tests_extractor --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 --- Comment #15 from Iain Buclaw --- Still reproducible on 2.081 release candidate (I've had to revert the commit again). --
[Issue 14739] Immutable alias to template triggers dmd assert
https://issues.dlang.org/show_bug.cgi?id=14739 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED CC||ibuc...@gdcproject.org Resolution|--- |FIXED --- Comment #5 from Iain Buclaw --- This seems to be fixed now, added the test case here to make sure it doesn't regress. https://github.com/dlang/dmd/pull/8428 --
[Issue 19024] [REG 2.081-beta] AssertError@dmd/dsymbolsem.d(4317): Assertion failure
https://issues.dlang.org/show_bug.cgi?id=19024 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Buclaw --- https://github.com/dlang/dmd/pull/8428 --
[Issue 18918] core.internal.hash should perform memberwise hashing of structs with references
https://issues.dlang.org/show_bug.cgi?id=18918 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/22a6f7fd5a107040d822c96a2e5725dadb4c1763 Fix Issue 18918 - core.internal.hash should perform memberwise hashing of structs with references https://github.com/dlang/druntime/commit/63efdeffb06b5656ff834aaf34e71d30bb989863 Merge pull request #2195 from n8sh/core-hash-18918 Fix Issue 18918 - core.internal.hash should perform memberwise hashing of structs with references merged-on-behalf-of: Sebastian Wilzbach --
[Issue 18918] core.internal.hash should perform memberwise hashing of structs with references
https://issues.dlang.org/show_bug.cgi?id=18918 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or neither are defined
https://issues.dlang.org/show_bug.cgi?id=17206 Nathan S. changed: What|Removed |Added CC||n8sh.second...@hotmail.com --- Comment #2 from Nathan S. --- Half of this is wrong. For a type to be usable as a key in an associative array it must be true that "a == b" implies "a.toHash() == b.toHash()", so when there is a non-default `==` there should also be a custom `toHash` to maintain this property. But the reverse is not true: defining a non-default `toHash` does not require a custom `opEquals`, because the default `==` is already the strictest possible condition that satisfies "a == a" (since structs can be relocated). --
[Issue 3844] Require opEquals/opCmp in a class the defines toHash
https://issues.dlang.org/show_bug.cgi?id=3844 Nathan S. changed: What|Removed |Added Status|NEW |RESOLVED CC||n8sh.second...@hotmail.com Resolution|--- |INVALID --
[Issue 16293] hashOf should be @nogc when it can be
https://issues.dlang.org/show_bug.cgi?id=16293 Nathan S. changed: What|Removed |Added Status|NEW |RESOLVED CC||n8sh.second...@hotmail.com Resolution|--- |DUPLICATE --- Comment #2 from Nathan S. --- This wasn't done before, because the CTFE path wasn't `@nogc`, but now it is. *** This issue has been marked as a duplicate of issue 19009 *** --
[Issue 19009] core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc`
https://issues.dlang.org/show_bug.cgi?id=19009 Nathan S. changed: What|Removed |Added CC||joeyemm...@yahoo.com --- Comment #3 from Nathan S. --- *** Issue 16293 has been marked as a duplicate of this issue. *** --
[Issue 18920] core.internal.hash of array of scalars should be `@safe`
https://issues.dlang.org/show_bug.cgi?id=18920 Nathan S. changed: What|Removed |Added CC||j...@jackstouffer.com --- Comment #3 from Nathan S. --- *** Issue 16518 has been marked as a duplicate of this issue. *** --
[Issue 16518] hashOf is @system for dynamic arrays
https://issues.dlang.org/show_bug.cgi?id=16518 Nathan S. changed: What|Removed |Added Status|NEW |RESOLVED CC||n8sh.second...@hotmail.com Resolution|--- |DUPLICATE --- Comment #1 from Nathan S. --- Fixed. *** This issue has been marked as a duplicate of issue 18920 *** --
[Issue 19049] New: object.hashOf - don't wrap a public function with an identical public function
https://issues.dlang.org/show_bug.cgi?id=19049
Issue ID: 19049
Summary: object.hashOf - don't wrap a public function with an
identical public function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: n8sh.second...@hotmail.com
This is hashOf in object.d:
```
size_t hashOf(T)(auto ref T arg, size_t seed = 0)
{
import core.internal.hash;
return core.internal.hash.hashOf(arg, seed);
}
```
This serves no purpose because `core.internal.hash.hashOf` is public and also
has an `auto ref` argument. So `core.internal.hash.hashOf` should either be
publicly imported or exposed through an alias.
This issue has synergy with PR https://github.com/dlang/druntime/pull/2238.
--
[Issue 19048] In core.internal.hash.hashOf reduce template bloat: remove `auto ref` where unneeded and add `const` where possible
https://issues.dlang.org/show_bug.cgi?id=19048 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2238 --
[Issue 19048] In core.internal.hash.hashOf reduce template bloat: remove `auto ref` where unneeded and add `const` where possible
https://issues.dlang.org/show_bug.cgi?id=19048 Nathan S. changed: What|Removed |Added Summary|In |In |core.internal.hash.hashOf |core.internal.hash.hashOf |to reduce template bloat|reduce template bloat: |remove `auto ref` when it's |remove `auto ref` where |not needed |unneeded and add `const` ||where possible --
[Issue 19048] New: In core.internal.hash.hashOf to reduce template bloat remove `auto ref` when it's not needed
https://issues.dlang.org/show_bug.cgi?id=19048 Issue ID: 19048 Summary: In core.internal.hash.hashOf to reduce template bloat remove `auto ref` when it's not needed Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com Reduce template proliferation by not using `auto ref` unnecessarily. Scalars, dynamic arrays, raw pointers, delegates, objects, and associative arrays don't need to be passed by reference. Additionally by adding `const` where we know it's legal we can cause IFTI to produce fewer distinct instantiations. For instance we can avoid having separate template instantiations for `hashOf(const int(1))` and `hashOf(int(1))`. --
[Issue 18332] rt.util.random.Rand48 remove unnecessary assert
https://issues.dlang.org/show_bug.cgi?id=18332 Nathan S. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan S. --- For some reason this didn't auto-close. --
[Issue 19014] Compiler imports symbols that aren't actually imported.
https://issues.dlang.org/show_bug.cgi?id=19014 --- Comment #5 from RazvanN --- (In reply to Mike Franklin from comment #4) > I don't want to close it until a test is added to the DMD test suite and it > passes. We can't do that until the deprecation period has expired. A compilable test with the REQUIRED_ARGS set to -de can be added in order to solve this. --
[Issue 19014] Compiler imports symbols that aren't actually imported.
https://issues.dlang.org/show_bug.cgi?id=19014 --- Comment #4 from Mike Franklin --- I don't want to close it until a test is added to the DMD test suite and it passes. We can't do that until the deprecation period has expired. --
[Issue 19014] Compiler imports symbols that aren't actually imported.
https://issues.dlang.org/show_bug.cgi?id=19014 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #3 from RazvanN --- (In reply to Mike Franklin from comment #2) > Compiling with head I get the following: > > Deprecation: module core.stdc.math is not accessible here, perhaps add > static import core.stdc.math; > > So, I believe this issue will be solved when the deprecation phase has > passed. So, can we close this? --
[Issue 19030] CTorFlow checking is too aggressive and only checks whether a this call is present
https://issues.dlang.org/show_bug.cgi?id=19030 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- Actually, this is not a bug, it's the intended behavior. It is specified in the spec that after a delegate constructor call all fields are considered constructed: https://github.com/dlang/dlang.org/blob/master/spec/struct.dd#L497 . --
[Issue 19046] OSX: bad value for core.stdc.time.CLOCKS_PER_SEC
https://issues.dlang.org/show_bug.cgi?id=19046 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/ac1bf3551f776dbdafb7a55737c7be8f070a7d5b fix Issue 19046 - OSX: bad value for core.stdc.time.CLOCKS_PER_SEC seems to have been switched from 100 to 1_000_000 with OSX 10.4/10.5 https://github.com/dlang/druntime/commit/0e775010184719af7bc263e7e08959afb233ad06 Merge pull request #2237 from rainers/issue19046 fix Issue 19046 - OSX: bad value for core.stdc.time.CLOCKS_PER_SEC merged-on-behalf-of: Jacob Carlborg --
[Issue 19046] OSX: bad value for core.stdc.time.CLOCKS_PER_SEC
https://issues.dlang.org/show_bug.cgi?id=19046 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19047] Undefined identifier caused by circular import and CTFE
https://issues.dlang.org/show_bug.cgi?id=19047 --- Comment #1 from Basile B. --- Add to this the quite unhelpful error message. Imagine the same problem drown in 5000 SLOCs. The only thing you see is that your declaration is here... --
[Issue 19047] New: Undefined identifier caused by circular import and CTFE
https://issues.dlang.org/show_bug.cgi?id=19047
Issue ID: 19047
Summary: Undefined identifier caused by circular import and
CTFE
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
3 modules are involved:
=== ast.d ===
module ast;
import symbol;
string astNodesClasses()
{
return "alias AstNodesSeq = AstNode;";
}
mixin(astNodesClasses());
alias AstNodes = AstNodesSeq;
string genVisitMethods(string statements)
{
return "void visit(" ~ AstNodes.stringof ~ "){}";
}
class AstNode{}
=== utils.d
module utils;
import ast, symbol;
class Foo
{
mixin(genVisitMethods(""));
}
=== symbol.d ===
module symbol;
import utils; // circular problem caused by this
compile with:
`dmd ast.d symbol.d utils.d -lib`
to get:
`ast.d(12): Error: undefined identifier AstNodesSeq
utils.d(8):called from here: genVisitMethods("")`
Now remove the import in symbol.d and try again, no problem, error is gone.
I think that there's should not be any circular issue.
In bigger project CTFE fails because of this (CTFE fails because of previous
error in genVisit... etc)
--
[Issue 19046] OSX: bad value for core.stdc.time.CLOCKS_PER_SEC
https://issues.dlang.org/show_bug.cgi?id=19046 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #1 from Rainer Schuetze --- https://github.com/dlang/druntime/pull/2237 --
[Issue 19046] OSX: bad value for core.stdc.time.CLOCKS_PER_SEC
https://issues.dlang.org/show_bug.cgi?id=19046 Rainer Schuetze changed: What|Removed |Added OS|Windows |Mac OS X Severity|enhancement |normal --
[Issue 19046] New: OSX: bad value for core.stdc.time.CLOCKS_PER_SEC
https://issues.dlang.org/show_bug.cgi?id=19046 Issue ID: 19046 Summary: OSX: bad value for core.stdc.time.CLOCKS_PER_SEC Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: r.sagita...@gmx.de CLOCKS_PER_SEC yields 1_000_000 nowadays on OSX. The definition in core.stdc.time sets it to 100, though. --
