[Issue 18984] New: Debugging stack struct's which are returned causes incorrect debuginfo.
https://issues.dlang.org/show_bug.cgi?id=18984 Issue ID: 18984 Summary: Debugging stack struct's which are returned causes incorrect debuginfo. Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: major Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Created attachment 1704 --> https://issues.dlang.org/attachment.cgi?id=1704=edit Test case >From the prior conversation: > Debugging issues: >Stack allocated struct won't show values correctly (repro project attached) >Supply metadata0.bin as commandline arg >Place watch at lines 91 and 119, step and watch the values of `Frame f` > and `Packet p` as they are populated with data >Notice that those stack structs do not appear to be changing, and show > rubbish values. You can see the actual value in the hidden return value __HID1/__HID2 (you can see the symbol in the disassembly). dmd seems to ignore RVO when emitting the debug info. --
[Issue 18983] New: DCompiler option seems to have disappeared from project settings
https://issues.dlang.org/show_bug.cgi?id=18983 Issue ID: 18983 Summary: DCompiler option seems to have disappeared from project settings Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Create a new project using the D/C++ project wizard. (close and reload the project solution to cause the project explorer to refresh) Project -> Properties -> General DCompiler selection is no longer in the menu, can't switch between DMD/LDC anymore --
[Issue 18982] New: Source files are invisible in the project explorer when creating a new project
https://issues.dlang.org/show_bug.cgi?id=18982 Issue ID: 18982 Summary: Source files are invisible in the project explorer when creating a new project Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: minor Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com I've been noticing an odd bug when creating a new project. Create new D/C++ project; note, can't see source file in the file tree Close and reload solution; source file appears in file tree Very odd little bug. Not serious, but might be confusing to new users. --
[Issue 18952] std.experimental.checkedint.Saturate prints integral promotion deprecation message
https://issues.dlang.org/show_bug.cgi?id=18952 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18952] std.experimental.checkedint.Saturate prints integral promotion deprecation message
https://issues.dlang.org/show_bug.cgi?id=18952 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/7a8ff39cbb0630547bfd85f939cd0207a09418b5 Fix Issue 18952 - std.experimental.checkedint.Saturate prints integral promotion deprecation message https://github.com/dlang/phobos/commit/15b682af36d39c8ddbd889dba98b694092a7c7ea Merge pull request #6549 from wilzbach/checked-doc Fix Issue 18952 - std.experimental.checkedint.Saturate prints integral promotion deprecation message merged-on-behalf-of: Nathan Sashihara --
[Issue 18981] New: SIGSEGV during backtrace when debug info is compressed
https://issues.dlang.org/show_bug.cgi?id=18981
Issue ID: 18981
Summary: SIGSEGV during backtrace when debug info is compressed
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: yshu...@gmail.com
To reproduce:
1) sample D code:
void main() {
throw new Exception("asdf");
}
2) compile it with debug info
3) compress the debug info with objcopy a.out --compress-debug-sections=zlib
4) run it
Expected:
Stack trace, or at least not crashing
Actual:
SIGSEGV
--
[Issue 18980] New: Typesafe variadic array functions cause memory corruption
https://issues.dlang.org/show_bug.cgi?id=18980
Issue ID: 18980
Summary: Typesafe variadic array functions cause memory
corruption
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: mrjn...@gmail.com
Created attachment 1703
--> https://issues.dlang.org/attachment.cgi?id=1703=edit
Reproduction code
I've attached a simple D program that builds a complex JSONValue using several
helper functions with signatures like
JSONValue or(JSONValue[] conditions...) {}
I've found that the resulting programs have (sometimes) subtle memory
corruption issues. To replicate, download the attached D file and compile &
run with:
dmd -run badness.d
dmd -O -inline -release -run badness.d
The issue manifests with optimizations on AND off, although generally
differently: sometimes with bad JSON output, other times with a memory
allocation failure.
My guess is that the arguments to these variadic array functions are being
stack allocated and passing out of scope. If you put `.dup` on the two lines
indicated in the source, the problem is resolved.
--
[Issue 18979] New: Template constructor bypasses private
https://issues.dlang.org/show_bug.cgi?id=18979
Issue ID: 18979
Summary: Template constructor bypasses private
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
The following compiles but shouldn't:
foo.d:
struct Foo {
private this(A)(A arg) { }
}
bar.d:
import foo;
void func() {
auto f = Foo(42);
}
--
[Issue 18978] New: Cannot create new projects in 0.47.0-beta1
https://issues.dlang.org/show_bug.cgi?id=18978 Issue ID: 18978 Summary: Cannot create new projects in 0.47.0-beta1 Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: regression Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: thomas.hedst...@mail.com (Fresh install of VS2017 Community) After attempting to create a new project in 0.47.0-beta1, this error pops up: --- Microsoft Visual Studio --- Error: this template attempted to load component assembly 'VisualDWizard, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c74ad3042b283f5c'. For more information on this problem and how to enable this template, please see documentation on Customizing Project Templates. Tested both project types available: "D/C++ Win32 Application" and "VisualD Win32 Application". Going back to 0.46.0 works, where more project types are also available. "LDC/GDC... etc". As an extra check... reinstalling 0.47.1-beta1 and the error is back. --
[Issue 18977] New: struct and class declarations are inconsistent about what happens when they're marked with immutable
https://issues.dlang.org/show_bug.cgi?id=18977
Issue ID: 18977
Summary: struct and class declarations are inconsistent about
what happens when they're marked with immutable
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
This code
immutable struct S {}
immutable class C {}
void main()
{
S s;
pragma(msg, typeof(s));
C c;
pragma(msg, typeof(c));
}
prints
immutable(S)
C
I find this very surprising. It is my understanding that marking a struct or
class as immutable only affects its members, not the type itself. The type
doesn't magically become immutable everywhere it's used - and having it be
magically immutable everywhere is going to be really confusing. I don't see how
anyone can expect to look at
S s;
and think anything other than s is mutable, so it strikes me as a terrible idea
to have it be immutable based on the fact that the struct declaration was
marked with immutable
So, I would strongly argue that this should be fixed so that s is not
implicitly immutable and acts more like what happens with the class case.
However, regardless of whether the struct variable should be implicitly
considered immutable or not, the fact that it is while the class variable is
not is inconsistent, which makes what's going on harder to understand and more
confusing.
So, either, we should fix it so that marking a struct declaration as immutable
has no effect on the mutability of any variables of that type (just its
members), or we should fix it so that marking a class declaration as immutable
makes all variables of that type immutable just like it currently does with
structs. I vote for making it so that variables are never implicitly immutable
based on the declaration of the types, but either way, it should be consistent.
--
[Issue 18593] std.datetime.stopwatch.benchmark shouldn't optimize away its functions
https://issues.dlang.org/show_bug.cgi?id=18593 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18593] std.datetime.stopwatch.benchmark shouldn't optimize away its functions
https://issues.dlang.org/show_bug.cgi?id=18593 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/25c3ef46aff92363f50e1f7dc74e62ed368d94c1 Fix Issue 18593 - std.datetime.stopwatch.benchmark shouldn't optimize away its functions --
[Issue 12507] SysTime.init.toString should not segfault
https://issues.dlang.org/show_bug.cgi?id=12507 Nathan S. changed: What|Removed |Added CC||n8sh.second...@hotmail.com --- Comment #11 from Nathan S. --- Pull request: https://github.com/dlang/phobos/pull/6581 I doubt it is of great interest to anyone precisely what is displayed by `SysTime.init.toString`, but it shouldn't cause a segfault, and fixing that is trivial. --
[Issue 18864] Building 64-bit dmd on Windows results in a binary that crashes
https://issues.dlang.org/show_bug.cgi?id=18864 --- Comment #9 from Atila Neves --- After some experiments, it seems that the release build of 64-bit dmd is the one with problems. The debug build seems to work ok. --
[Issue 18925] core.internal.hash auto-hash for structs of scalar fields should be `@safe`
https://issues.dlang.org/show_bug.cgi?id=18925 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/436a706ddf088bd751d2aad9bbddc2c803c5a4da Fix Issue 18925 - core.internal.hash auto-hash for structs of scalar fields should be `@safe` https://github.com/dlang/druntime/commit/4138cfd0ba9aba3a3ded99a459f8fd597a53501b Merge pull request #2200 from n8sh/core-hash-18925 Fix Issue 18925 - core.internal.hash auto-hash for structs of scalar fields should be `@safe` --
[Issue 12086] std.algorithm.remove + range of indices produces wrong results
https://issues.dlang.org/show_bug.cgi?id=12086 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/622c5d209820194651a8acb01fabc03041cd8e9e Fix Issue 12086 - std.algorithm.remove + range of indices produces wrong results https://github.com/dlang/phobos/commit/89c1f1af6f29500013c465cc53f12e1ec6221523 Merge pull request #6154 from wilzbach/fix-12086 Fix Issue 12086 - std.algorithm.remove + range of indices produces wrong results merged-on-behalf-of: Nathan Sashihara --
[Issue 11451] import statements don't work when compiling several files at once
https://issues.dlang.org/show_bug.cgi?id=11451 --- Comment #12 from Atila Neves --- I've edited the title because the more pressing concern is that 64-bit dmd on Windows currently (from version 2.080.0 at least) doesn't work. It crashes frequently and/or produces binaries that crash themselves. I've tried using digger, building it myself and even using different versions of host dmd to build it. It must be said that I am copying the built dmd.exe over the one from the installer. I'd create an alternate installer instead but installing the dependencies is non-trivial. This method has worked in the past. I've been racking my brain trying to figure out why dmd would crash itself this way and can't find a reason. I'm not sure why phobos or drumtime would be different given that the new dmd is built from the same tag and the only difference is that it's a 64-bit binary itself instead of 32-bit. --
[Issue 17167] dmd fails to write to file or create directory with more than 248 characters in the path
https://issues.dlang.org/show_bug.cgi?id=17167 Atila Neves changed: What|Removed |Added Severity|major |blocker --
[Issue 18864] Building 64-bit dmd on Windows results in a binary that crashes
https://issues.dlang.org/show_bug.cgi?id=18864 Atila Neves changed: What|Removed |Added Summary|Building 64-bit dmd on |Building 64-bit dmd on |Windows results in a debug |Windows results in a binary |build. The release build|that crashes |doesn't work. | --
[Issue 16088] Parse error for import expression in statement
https://issues.dlang.org/show_bug.cgi?id=16088 --- Comment #3 from RazvanN --- (In reply to timon.gehr from comment #2) > https://dlang.org/spec/grammar.html#ImportExpression You are are right. Thank you. PR: https://github.com/dlang/dmd/pull/8356 --
[Issue 18582] C++ namespace mangling from multiple modules doesn't use sequence ids
https://issues.dlang.org/show_bug.cgi?id=18582 --- Comment #2 from Markus --- (In reply to Mathias LANG from comment #1) > Oh I missed this when I opened 18922. It's fixed now, so marking this as > duplicate. > > *** This issue has been marked as a duplicate of issue 18922 *** You are awesome! Thanks a lot! --
[Issue 16088] Parse error for import expression in statement
https://issues.dlang.org/show_bug.cgi?id=16088 --- Comment #2 from timon.g...@gmx.ch --- https://dlang.org/spec/grammar.html#ImportExpression --
[Issue 15329] __traits(isPOD, S) incorrectly returns true for structs with disabled S.init
https://issues.dlang.org/show_bug.cgi?id=15329 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- I assume that instead of S7 you were referring to S. Why should it not compile? From the glossary [1] : "POD (Plain Old Data) Refers to a struct that contains no hidden members, does not have virtual functions, does not inherit, has no destructor, and can be initialized and copied via simple bit copies." If I'm not missing anything, S complies with all of the above. [1] https://dlang.org/glossary.html#pod --
[Issue 16118] ICE on double import erroneous file
https://issues.dlang.org/show_bug.cgi?id=16118 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- Cannot reproduce on latest master (DMD64 D Compiler v2.079.0) on ubuntu. Closing as WORKSFORME. Please reopen if ice is persistent. --
[Issue 16088] Parse error for import expression in statement
https://issues.dlang.org/show_bug.cgi?id=16088
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from RazvanN ---
Why should it parse? The grammar [1] shows that after the "import" keyword an
identifier is expected not '('. Maybe close as invalid?
[1] https://dlang.org/spec/grammar.html#ImportDeclaration
--
[Issue 12839] std.parallelism with nested functions and lambdas. Segfault
https://issues.dlang.org/show_bug.cgi?id=12839 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #7 from RazvanN --- All the examples in this bug report now compile successfully. However, Issue 16051 is still valid. Closing as fixed. --
[Issue 18974] ICE with mixin templates, inheritance and overloading
https://issues.dlang.org/show_bug.cgi?id=18974
Simen Kjaeraas changed:
What|Removed |Added
Keywords||ice
CC||simen.kja...@gmail.com
--- Comment #1 from Simen Kjaeraas ---
Further simplified:
template Mixin() {
void fun(const int) { }
}
class Foo {
mixin Mixin!();
mixin Mixin!();
}
class Bar : Foo {
override void fun(int) { } // Line 11
}
This gives a slightly different stack trace (top calls are still the same).
This difference is caused by templatization of Foo, and can be disregarded.
Changing the type on line 14 from A to const(A) removes the crash. Rewriting to
using a single invocation of Mixin with two function definitions inside gives
this message:
Error: function void foo.Bar.fun(A) does not override any function, did you
mean to override void foo.Foo!int.Foo.Mixin!(A, B).fun(const(A))?
--
[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 #13 from Basile B. ---
Other test case:
---
import std.datetime;
import std.typecons;
import std.variant;
Y a()
{
Y n = Y(Y[].init);
n.get!(X[]);
return n;
}
struct X
{
Y key;
}
struct Y
{
Algebraic!(Y[]) value_;
this(T)(T value)
{
value_ = value;
}
bool opEquals(T)(T rhs) const
{
static if(is(Unqual!T == Y))
{
return true;
}
else
{
return get!(T, No.x) == get!T;
}
}
T get(T, Flag!"x" x = Yes.x)() const
{
return this[""].get!(T, x);
}
Y opIndex(T)(T index) const
{
const X[] pairs;
if(pairs[0].key == index)
{
assert(0);
}
assert(0);
}
}
void main(){}
---
linker error without -allinst
--
