[Issue 982] Codeview: symbols of enum type are declared integer
https://issues.dlang.org/show_bug.cgi?id=982 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #10328 "fix Issue 4372, 982 - CodeView: type of enumerator values reduced to …" was merged into master: - f4e4b7e6ff66ec4d0d2774f309731c03392327cc by Rainer Schuetze: fix Issue 4372, 982 - CodeView: type of enumerator values reduced to base type in debug info write a forward reference to the enum definition, it is emitted elsewhere https://github.com/dlang/dmd/pull/10328 --
[Issue 4372] type of enumerator values reduced to base type in debug info
https://issues.dlang.org/show_bug.cgi?id=4372 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dlang Bot --- dlang/dmd pull request #10328 "fix Issue 4372, 982 - CodeView: type of enumerator values reduced to …" was merged into master: - f4e4b7e6ff66ec4d0d2774f309731c03392327cc by Rainer Schuetze: fix Issue 4372, 982 - CodeView: type of enumerator values reduced to base type in debug info write a forward reference to the enum definition, it is emitted elsewhere https://github.com/dlang/dmd/pull/10328 --
[Issue 19965] [DIP1000] Template allows to escape internal pointer
https://issues.dlang.org/show_bug.cgi?id=19965 --- Comment #2 from Mike Franklin --- The problem appears to be with `scope` inference. In `escape.d` there are many places where `STC.maybescope` is removed after it has been determined that `scope` cannot be inferred. There is even a function `notMaybeScope` to do this. I believe all that needs to be done is to call `notMaybeScope(v)` in the right place and for the right conditions so `scope` is no longer inferred for this scenario. --
[Issue 19731] auto struct methods whose address is taken don't test invariants
https://issues.dlang.org/show_bug.cgi?id=19731 Iain Buclaw changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ibuc...@gdcproject.org Resolution|FIXED |--- --- Comment #8 from Iain Buclaw --- Not fixed, as the bug still occurs if you compile the original test with -inline. --
[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.
https://issues.dlang.org/show_bug.cgi?id=17767 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Iain Buclaw --- Closing, as there's no issue here. --
[Issue 20153] New: extern for aliased template instantiation
https://issues.dlang.org/show_bug.cgi?id=20153
Issue ID: 20153
Summary: extern for aliased template instantiation
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: blac...@bk.ru
I want to export non-mangled instantiated through alias template function.
it can be useful for WASM, DLLs/SharedLibs and etc.
but alias for template instatiation is ignored.
pragma mangle to alias is ignored too.
---
void main() {}
export: // EXPORTed
extern (C): // NO MANGLE but IGNORED
public:
void fun( Char )( Char* ) { }
pragma (mangle, "func") // IGNORED
alias func = fun!char;
pragma( msg, func.mangleof );
pragma (mangle, "funw") // IGNORED
alias funw = fun!wchar;
pragma( msg, funw.mangleof );
OUTPUT ---
_D9onlineapp__T3funTaZQhUNaNbNiNfPaZv
_D9onlineapp__T3funTuZQhUNaNbNiNfPuZv
current workaround: wrap template funcs to non-template.
possible solution:
if "alias" locates in non-mangle block (extern(C) for example) then do not
mangle name and check that no others entities with same name exists in current
context.
OR/AND
make "pragma mangle" working for alias-es too.
--
[Issue 13582] Deprecated modules imported from other deprecated modules shouldn't be warned about
https://issues.dlang.org/show_bug.cgi?id=13582 --- Comment #2 from Dlang Bot --- @FeepingCreature updated dlang/dmd pull request #10336 "Fix issue 13582: Don't print deprecation when importing a deprecated module from another deprecated module." fixing this issue: - Fix issue 13582: don't print deprecation when importing a deprecated module from another deprecated module. https://github.com/dlang/dmd/pull/10336 --
[Issue 20152] numeric expression should not evaluate to const type
https://issues.dlang.org/show_bug.cgi?id=20152 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com Severity|regression |normal --- Comment #1 from ag0aep6g --- This is not a regression. Downgrading to "normal". Ultimately, this is probably an enhancement request, unless the spec states that the type should be `double`. --
[Issue 20152] New: numeric expression should not evaluate to const type
https://issues.dlang.org/show_bug.cgi?id=20152
Issue ID: 20152
Summary: numeric expression should not evaluate to const type
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ilyayaroshe...@gmail.com
void main()
{
const double a = 1, b = 2;
pragma(msg, typeof(a * b));
}
prints `const(double)`
expected result: `double`
--
[Issue 20151] particular directory layout causes DMD to crash with an access violation
https://issues.dlang.org/show_bug.cgi?id=20151 ag0aep6g changed: What|Removed |Added Keywords||ice CC||ag0ae...@gmail.com Hardware|x86_64 |All OS|Windows |All --- Comment #1 from ag0aep6g --- Also happens in linux and in wine (32 bit Windows DMD). --
[Issue 15651] filter: only parameters or stack based variables can be inout
https://issues.dlang.org/show_bug.cgi?id=15651 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer --- (In reply to Simen Kjaeraas from comment #1) > This issue is only partially fixable - filter() could use the solution > described in issue 13428 to turn inout(T) into const(T). This would lead to > fun() returning a const(D)[] result instead of inout(D)[], so it's not a > complete solution. It's fully fixable -- if we can create an filter of inout elements. As I mentioned in issue 9983, this simply involves allowing structs to declare inout members. In fact, we should allow inout to be used ANYWHERE, except global variables (as putting inout variables in global space can change the meaning from call to call). They will just be another type of immutable in functions which don't have inout parameters, or when used in structs outside of inout functions. (In reply to anonymous4 from comment #2) > See also workaround in issue 9983 This is not a valid workaround, as an inout filter would not be iterable. I actually thought that maybe with closures, we could make a "workaround" but it doesn't work because there's no way to return an inout from a function that has no inout parameters. Another stupid limitation that we should omit. I'd try my hand at an inout improvement DIP, but I feel it would likely be rejected on principle, since inout is so disfavored by leadership. --
[Issue 20151] particular directory layout causes DMD to crash with an access violation
https://issues.dlang.org/show_bug.cgi?id=20151 John Colvin changed: What|Removed |Added Hardware|All |x86_64 --
[Issue 20151] particular directory layout causes DMD to crash with an access violation
https://issues.dlang.org/show_bug.cgi?id=20151 John Colvin changed: What|Removed |Added Component|installer |dmd --
[Issue 17927] [scope] `scope inout` parameter value can be escaped via return
https://issues.dlang.org/show_bug.cgi?id=17927 Les De Ridder changed: What|Removed |Added CC||dl...@lesderid.net --
[Issue 19965] [DIP1000] Template allows to escape internal pointer
https://issues.dlang.org/show_bug.cgi?id=19965 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #1 from Mike Franklin --- If narrowed this issue down to this line in the DMD source code: https://github.com/dlang/dmd/blob/0459e34e20a0631a021550431dfe2411ebe16d3f/src/dmd/escape.d#L1465 When `Foo` is a template, `tf.isscope` is `true`, but when `Foo` is not a template `tf.isscope` is `false`. `isscope` is set to *true` at https://github.com/dlang/dmd/blob/0459e34e20a0631a021550431dfe2411ebe16d3f/src/dmd/semantic3.d#L1316 It is set to *true` because `funcdecl.vthis.storage_class` is `STC.maybescope`. That's as far as I got. --
[Issue 20151] New: particular directory layout causes DMD to crash with an access violation
https://issues.dlang.org/show_bug.cgi?id=20151 Issue ID: 20151 Summary: particular directory layout causes DMD to crash with an access violation Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: major Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com Confirmed in 2.086.1 and 2.088-beta.1 C:\test>tree /f Folder PATH listing for volume Windows Volume serial number is 547E-DA40 C:. │ c.d │ └───c └───b └───a a.d C:\test>type c.d import c.b.a.a; C:\test>type c\b\a\a.d C:\test>C:\Users\jcolvin_sym\dlang\dmd-2.088.0-beta.1\dmd2\windows\bin\dmd.exe c.d -o- --- ERROR: This is a compiler bug. Please report it via https://issues.dlang.org/enter_bug.cgi with, preferably, a reduced, reproducible example and the information below. DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the reduction. --- DMD v2.088.0-beta.1-dirty predefs DigitalMars Windows CRuntime_DigitalMars CppRuntime_DigitalMars LittleEndian D_Version2 all D_InlineAsm D_InlineAsm_X86 X86 Win32 assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat binary C:\Users\jcolvin_sym\dlang\dmd-2.088.0-beta.1\dmd2\windows\bin\dmd.exe version v2.088.0-beta.1-dirty configC:\Users\jcolvin_sym\dlang\dmd-2.088.0-beta.1\dmd2\windows\bin\sc.ini DFLAGS -IC:\Users\jcolvin_sym\dlang\dmd-2.088.0-beta.1\dmd2\windows\bin\..\..\src\phobos -IC:\Users\jcolvin_sym\dlang\dmd-2.088.0-beta.1\dmd2\windows\bin\..\..\src\druntime\import --- object.Error@(0): Access Violation 0x00489A8F 0x773D5EC9 in RtlAllocateHeap 0x0463C1F0 0x00750064 0x00650063 0x005C0064 0x1791B8D1 0x1600DE2D 0x0119251C --
[Issue 19175] @safe code can escape local array references
https://issues.dlang.org/show_bug.cgi?id=19175 --- Comment #9 from ag0aep6g --- (In reply to Mike Franklin from comment #8) > Works for me as in v2.087.1 Most of the test cases are correctly rejected now with -dip1000. But the one from comment #7 is still accepted. Moved to issue 20150. --
[Issue 20150] New: -dip1000 defeated by pure
https://issues.dlang.org/show_bug.cgi?id=20150
Issue ID: 20150
Summary: -dip1000 defeated by pure
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: safe
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
This is a spin-off from issue 19175.
int* escape(int* r) @safe pure
{
return r;
}
int* f() @safe
{
int x = 42;
return escape(); /* Should not compile. */
}
Tested with v2.087.0 and v2.088.0-beta.1-46-g0459e34e (current git master).
--
[Issue 1472] Be more clever about detecting assigment to non-l-values
https://issues.dlang.org/show_bug.cgi?id=1472 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --- Comment #4 from RazvanN --- The spec clearly states that "a variable or the result of the DotIdentifier grammatical construct . (left side may be missing) when the rightmost side of the dot is a variable, field (direct or static), function name, or invocation of a function that returns by reference" is an lvalue. Therefore: x.get_struct.i = 10; is fine and: x.get_struct.set_i(10); is also fine, because you are calling the function of a temporary. Closing as WONTFIX. --
[Issue 1430] CodeView: new dchar type not used
https://issues.dlang.org/show_bug.cgi?id=1430 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from RazvanN --- *** This issue has been marked as a duplicate of issue 1104 *** --
[Issue 1104] CodeView: char is marked 0x20 (T_UCHAR) instead of 0x10 (T_CHAR)
https://issues.dlang.org/show_bug.cgi?id=1104 --- Comment #12 from RazvanN --- *** Issue 1430 has been marked as a duplicate of this issue. *** --
