[Issue 13912] Offer to 'import missing packages' like C# and Java
https://issues.dlang.org/show_bug.cgi?id=13912 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #5 from Jacob Carlborg d...@me.com --- In Eclipse, the IDE will automatically add missing imports if autocomplete is used to select a symbol. --
[Issue 14675] New: template specialization for T: T* and T: T[] has issues with IFTI
https://issues.dlang.org/show_bug.cgi?id=14675
Issue ID: 14675
Summary: template specialization for T: T* and T: T[] has
issues with IFTI
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: spec
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
Some background:
http://forum.dlang.org/post/rvflnpxwzetpcphwx...@forum.dlang.org
When a specialization of the form:
void foo(T : T*)(T* t)
void foo(T : T[])(T[] t)
exists in a function template, it cannot be matched for IFTI, only explicit
instantiation:
int i;
foo(i); // error
foo!(int *)(i); // ok
However, this will match both calls:
void foo(T : U*, U)(T t)
void foo(T : U[], U)(T t)
The docs say that parameters involved with specialization cannot be used for
IFTI, but that simply isn't the case for almost all specializations (2 examples
are the secondary forms above). Just these 2 as far as I can tell don't work.
First, their existence is redundant. The secondary forms are superior in almost
every way.
Second, they are confusing. A T is specialized as a T*? But then it's not?
Third, if they must exist, I think they should be usable with IFTI. There
doesn't seem to be any reasonable explanation as to why these particular
templates cannot be used for IFTI.
As an example of why this is important, consider the following:
void foo(T)(T t) { /* impl 1 */}
void foo(T:T*)(T* t) { /* impl 2 */}
int i;
foo(i); // calls impl 1
foo!(typeof(i))(i) // calls impl 2
This makes absolutely no sense, and seems extremely error prone.
Valid resolutions here:
1. Deprecate. This would break some code, but the ability to use the second
form at least gives a path forward.
2. Allow IFTI. At least this would not break code (at least not *reasonable*
code), but could potentially change code paths. It's possible someone has
exploited this confusing behavior to have two code paths for calling a function
with the same parameters. I don't think we should support this though.
--
[Issue 14666] [REG2.061] Bogus forward reference error
https://issues.dlang.org/show_bug.cgi?id=14666 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86 |All OS|Mac OS X|All --- Comment #5 from Kenji Hara k.hara...@gmail.com --- (In reply to deadalnix from comment #4) Sorry for the missing filenames, here they are: [snip] Thanks! https://github.com/D-Programming-Language/dmd/pull/4735 --
[Issue 14672] [REG2.067.0] Internal error: e2ir.c 4620 when copying array of derived class to an array of base class
https://issues.dlang.org/show_bug.cgi?id=14672 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --
[Issue 14672] [REG2.067.0] Internal error: e2ir.c 4620 when copying array of derived class to an array of base class
https://issues.dlang.org/show_bug.cgi?id=14672 --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4736 --
[Issue 13912] Offer to 'import missing packages' like C# and Java
https://issues.dlang.org/show_bug.cgi?id=13912 --- Comment #4 from Manu turkey...@gmail.com --- (In reply to Rainer Schuetze from comment #3) Let's see if Mono-D can do it, we might then be able to do it, too ;-) More seriously, with the current rush to use selective local imports, a little more interaction might be necessary to select where to put that import. Also, adding to existing imports might be desirable... Yeah you're right, it's a lot more comprehensive than C# :) I can imagine some nice solutions, but yeah, quite a few details. There are 4 states I can imagine, global/local (ie, import placed in local function) and whole-module/single-symbol. There would want to be logic such that single-symbol imports would be appended to a comma separated list of other symbols that may already be import from the same module. The 4 states that the user may select may be a little awkward for ui :) --
[Issue 14674] Importing std.stdio causes another module to become undefined
https://issues.dlang.org/show_bug.cgi?id=14674 --- Comment #4 from Kenji Hara k.hara...@gmail.com --- (In reply to sigsve from comment #2) Undefined symbols for architecture x86_64: _D5Stack12__ModuleInfoZ, referenced from: _D4Main12__ModuleInfoZ in Main.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) It says a ModuleInfo symbol of Stack module is missing. (In reply to sigsve from comment #3) Sorry, I though DMD compiled and linked Stack.d automagically(Which it seems to have done, when I do not import std.stdio) If you don't list a module file in dmd command line, the symbols in it are compiled (== semantic analysis done) but those code won't be output to any object files. When you don't add `import std.stdio;` in Stack.d, today's dmd fortunately determines the ModuleInfo object of Stack module is unnecessary, so the build will succeed. However it's just undocumented behavior, and might be changed in the future. So I'd recommend to compile and link Stack.d always when you import it from other modules. --
[Issue 14677] New: cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677
Issue ID: 14677
Summary: cast correctness not checked inside is(typeof())
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
```
void main()
{
void* x;
// Error: e2ir: cannot cast x of type void* to type int[30]
auto y = cast (int[30]) x;
// But this passes
static assert (is(typeof({ auto y = cast(int[30])x; })));
}
```
Looks like correctness of cast is checked after normal semantic phase and thus
ignored by `is(typeof())`
--
[Issue 13816] [REG2.066.0] The compiler crashes with recursive tuple expansion
https://issues.dlang.org/show_bug.cgi?id=13816
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||ice
Hardware|x86_64 |All
Summary|The compiler crashes with |[REG2.066.0] The compiler
|getProtection trait |crashes with recursive
||tuple expansion
OS|Mac OS X|All
Severity|blocker |regression
--- Comment #1 from Kenji Hara k.hara...@gmail.com ---
It's a regression from 2.066.0.
Reduced test case:
alias TypeTuple(T...) = T;
template ItemProperty()
{
static if (true)
{
alias ItemProperty = TypeTuple!(ItemProperty!()); // line 14
}
}
void main()
{
alias items = ItemProperty!(); // line 19
enum num = items.length;// line 21
}
Until 2.065, the code had printed:
test.d(14): Error: alias test.ItemProperty!().ItemProperty recursive alias
declaration
test.d(19): Error: template instance test.ItemProperty!() error instantiating
But since 2.066, line 19 makes no error, and line 21 will crash the compiler.
--
[Issue 13816] [REG2.066.0] The compiler crashes with recursive tuple expansion
https://issues.dlang.org/show_bug.cgi?id=13816 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4738 --
[Issue 14678] New: Bogus cannot create a struct until its size is determined error
https://issues.dlang.org/show_bug.cgi?id=14678
Issue ID: 14678
Summary: Bogus cannot create a struct until its size is
determined error
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: deadal...@gmail.com
See sample code:
enum AstTypeKind {
Foo,
Bar,
}
struct AstType {
mixin TypeMixin!(AstTypeKind, Payload);
this(AstTypeKind) {
}
import othermodule;
}
alias ParamAstType = AstType.ParamType;
union Payload {
ParamAstType* params;
}
template TypeMixin(K, Payload) {
Payload payload;
alias ParamType = PackedType!(typeof(this));
struct PackedType(T, U...) {
Payload payload;
auto getType() {
return T(AstTypeKind.Foo);
}
}
}
Other module can be an empty file. What is in it doesn't matter, the import
being there is the only thing that does matter.
Line 32: Error: cannot create a struct until its size is determined
Line 25: Error: template instance type.AstType.TypeMixin!(AstTypeKind,
Payload).PackedType!(AstType) error instantiating
--
[Issue 14666] [REG2.061] Bogus forward reference error
https://issues.dlang.org/show_bug.cgi?id=14666 --- Comment #6 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/0504d664beacd11ec5d0e8afaf209357f2d0f9de fix Issue 14666 - Bogus forward reference error https://github.com/D-Programming-Language/dmd/commit/640c0e189eeb04daea64257d7de1e4acd2df562e Merge pull request #4735 from 9rnsr/fix14666 [REG2.061] Issue 14666 - Bogus forward reference error --
[Issue 10223] Variant[] within Variant[] can be accessed, but not assigned to
https://issues.dlang.org/show_bug.cgi?id=10223 --- Comment #1 from Wyatt wyatt@gmail.com --- An NG post reminded me of this, so I just tested it on 2.067.1 and the output is rather different: wyatt@Yue ~/tmp/d $ rdmd ./issue10223.d bar Segmentation fault wyatt@Yue ~/tmp/d $ Okay, so it compiles now, but still doesn't work. We don't get nice things on Linux, so I tried it on my Windows workstation over lunch and found it's just been turned from a disappointment at compile time to a knife in the back at runtime: [0s] jwe29@PC91534 ~/tmp $ rdmd ./issue10223.d object.Error@(0): Access Violation 0x0042B626 0x00405141 0x00404667 0x004073D2 0x004021B1 0x0040B5E6 0x0040B5BB 0x0040B4D3 0x0040750B 0x7480337A in BaseThreadInitThunk 0x76F28FE2 in RtlInitializeExceptionChain 0x76F28FB5 in RtlInitializeExceptionChain === Bypassed === std.variant.VariantException@std\variant.d(1445): Variant: attempting to use incompatible types immutable(char)[] and std.variant.VariantN!20u.VariantN 0x004050E6 0x00404667 0x004073D2 0x004021B1 0x0040B5E6 0x0040B5BB 0x0040B4D3 0x0040750B 0x7480337A in BaseThreadInitThunk 0x76F28FE2 in RtlInitializeExceptionChain 0x76F28FB5 in RtlInitializeExceptionChain object.Error@(0): Access Violation 0x0042B626 0x00405141 0x00404667 0x004073D2 0x004021B1 0x0040B5E6 0x0040B5BB 0x0040B4D3 0x0040750B 0x7480337A in BaseThreadInitThunk 0x76F28FE2 in RtlInitializeExceptionChain 0x76F28FB5 in RtlInitializeExceptionChain === ~Bypassed === bar [2s] jwe29@PC91534 ~/tmp $ --
[Issue 14676] Calling the constructor of the parent class of an anonymous class
https://issues.dlang.org/show_bug.cgi?id=14676 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |WONTFIX --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Just add a constructor to your nested class, as per your SO question: http://stackoverflow.com/a/30758896/21501 If still you think this is a language addition worth considering, please submit a DIP: http://wiki.dlang.org/DIPs --
[Issue 14679] Parse uninstantiated generic artifacts lazily
https://issues.dlang.org/show_bug.cgi?id=14679
deadalnix deadal...@gmail.com changed:
What|Removed |Added
CC||deadal...@gmail.com
--- Comment #1 from deadalnix deadal...@gmail.com ---
void foo()() {
return };
}
It is not as simple as you think it is (but probably doable).
--
[Issue 14678] Bogus cannot create a struct until its size is determined error
https://issues.dlang.org/show_bug.cgi?id=14678 --- Comment #2 from deadalnix deadal...@gmail.com --- How the hell do you find these duplicates that fast ? --
[Issue 14678] Bogus cannot create a struct until its size is determined error
https://issues.dlang.org/show_bug.cgi?id=14678 --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com --- I do a regression test and find which pull request fixes the testcase. TrenD ( http://digger.k3.1azy.net/trend/ ) has all D builds cached, so the regression test runs quickly. --
[Issue 14678] Bogus cannot create a struct until its size is determined error
https://issues.dlang.org/show_bug.cgi?id=14678 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Good news! This issue is duplicate of Issue 6766, which has been fixed in HEAD. *** This issue has been marked as a duplicate of issue 6766 *** --
[Issue 6766] Forward reference error for default struct/class arguments
https://issues.dlang.org/show_bug.cgi?id=6766 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||deadal...@gmail.com --- Comment #7 from Vladimir Panteleev thecybersha...@gmail.com --- *** Issue 14678 has been marked as a duplicate of this issue. *** --
[Issue 14596] Error: e2ir: cannot cast malloc(42u) of type void* to type char[]
https://issues.dlang.org/show_bug.cgi?id=14596 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- *** Issue 14677 has been marked as a duplicate of this issue. *** --
[Issue 14677] cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||thecybersha...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- *** This issue has been marked as a duplicate of issue 14596 *** --
[Issue 14661] Error executing command build: Unknown dependency: ddox when building website
https://issues.dlang.org/show_bug.cgi?id=14661 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14680] New: Investigate the use of .di files for Phobos
https://issues.dlang.org/show_bug.cgi?id=14680 Issue ID: 14680 Summary: Investigate the use of .di files for Phobos Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: and...@erdani.com Using .di files has been attempted last time many years ago for Phobos and showed no improvements in compile times. Back then Phobos was much smaller and .di generation much less reliable than today. We should investigate now whether distributing Phobos importables as .di files instead of .d files would be beneficial. Now we have pragma(inline) which allows us to place in the .di files the functions we want to always inline, or to make available for CTFE. Among the advantages of .di files - they'd be devoid of unittests and comments, which tend to be massive in Phobos, --
[Issue 14679] New: Parse uninstantiated generic artifacts lazily
https://issues.dlang.org/show_bug.cgi?id=14679 Issue ID: 14679 Summary: Parse uninstantiated generic artifacts lazily Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: and...@erdani.com Unused generics (generic functions, classes, structs, templates, and mixins) need initially to be parsed only as balanced curlies - not even tokenized. They get tokenized, parsed, and semantically analyzed only upon first use. This allows libraries (such as Phobos itself) to provide functionality in templates at virtually no cost to their users. --
[Issue 14679] Parse uninstantiated generic artifacts lazily
https://issues.dlang.org/show_bug.cgi?id=14679 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- AFAIK the most expensive part of tokenization is identifier lookup (converting an identifier string into a number or pointer). --
[Issue 14675] template specialization for T: T* and T: T[] has issues with IFTI
https://issues.dlang.org/show_bug.cgi?id=14675
--- Comment #1 from Kenji Hara k.hara...@gmail.com ---
Personally I call the things `T : T*` self-dependent or self-specialized
template parameter.
I agree that is one of a strange feature in D. I guess it would be a syntax to
declare a type parameter with specialization at once.
// C++
template typename T class C;
template typename T class CT* { ... }
// Equivalent D code
class C(T : T*) { ... }
It takes one place in template parameter list. When a template argument is
_explicitly given_ on the position, it will deduce the parameter T, by matching
the argument to the form `T*`.
That's the point. Even if you explicitly give template argument, T is always
deduced.
On the other hand, IFTI deduces T from the function argument types before
testing the specialization. After the T determined, specialization test always
fail because T won't match to T*.
Therefore, we cannot make possible using it along with IFTI.
--
[Issue 14682] [REG2.037] Incorrect interpretation of ~ []
https://issues.dlang.org/show_bug.cgi?id=14682 --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- import std.stdio; Sorry, that's not actually needed. --
[Issue 14677] cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- If you wish, you can reopen with the intent of someone making a pull request which explicitly adds your test case to the DMD test suite. --
[Issue 14682] [REG2.037] Incorrect interpretation of ~ []
https://issues.dlang.org/show_bug.cgi?id=14682 --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- Introduced in https://github.com/D-Programming-Language/dmd/commit/6d41b09283040707dd0a6c0cf119de25c4b664b2 --
[Issue 14677] cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #5 from Kenji Hara k.hara...@gmail.com --- (In reply to Dicebot from comment #2) My report is about checking cast correctness at e2ir stage which makes illegal casts accepted inside is(typeof()) Very recently, full detection of invalid casts was added into front end (if I don't mistake somethingn) by the PR: https://github.com/D-Programming-Language/dmd/pull/4691 So now, they can be tested by using is(typeof()) idiom. --
[Issue 14677] cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677 --- Comment #6 from Dicebot pub...@dicebot.lv --- got it, thanks --
[Issue 14682] New: [REG2.037] Incorrect interpretation of ~ []
https://issues.dlang.org/show_bug.cgi?id=14682
Issue ID: 14682
Summary: [REG2.037] Incorrect interpretation of ~ []
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
// test.d //
import std.stdio;
void main()
{
auto foo = [foo] ~ [];
assert(foo.length == 1);
}
For some reason, DMD interprets `~[]` as `~[]`.
--
[Issue 14681] Add a way to specify a file import's contents on the command line
https://issues.dlang.org/show_bug.cgi?id=14681 --- Comment #1 from yebblies yebbl...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4740 --
[Issue 14677] cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677 --- Comment #2 from Dicebot pub...@dicebot.lv --- Vladimir, sorry, but this doesn't look like duplicate to me. Your linked issue was about rejecting legitimate cast. My report is about checking cast correctness at e2ir stage which makes illegal casts accepted inside is(typeof()) --
[Issue 14677] cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677 --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com --- Well, this bug is fixed in HEAD, and the pull request which fixed your bug was trying to fix issue 14596. Both are fixed by the check added in DMDFE. --
[Issue 14679] Parse uninstantiated generic artifacts lazily
https://issues.dlang.org/show_bug.cgi?id=14679 --- Comment #3 from Andrei Alexandrescu and...@erdani.com --- Yah, the alternate grammar needs to recognize comments, string literals, and newlines (for line counting purposes). One nice thing about not doing tokenization is a lot of memory is saved. --
[Issue 14681] New: Add a way to specify a file import's contents on the command line
https://issues.dlang.org/show_bug.cgi?id=14681 Issue ID: 14681 Summary: Add a way to specify a file import's contents on the command line Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: yebbl...@gmail.com C/C++ compilers generally have the ability to set preprocessor symbols from the command line. While dmd's -version=ident covers most use cases, it is sometimes useful to set the symbol to a specific value and access this inside the program. eg -DVERSION=3 With DMD this can be done by creating a file and using -J/import(), but there is no way to set the value directly on the command line. My proposed syntax to extend -J/import() to allow setting a value: dmd -J:key=value main.d Then in the program the import() syntax is used to retrieve the value: static assert(import(:key) == value); The ':' prefix allows the compiler to tell apart import paths and key/value pairs. --
[Issue 14676] New: Calling the constructor of the parent class of an anonymous class
https://issues.dlang.org/show_bug.cgi?id=14676
Issue ID: 14676
Summary: Calling the constructor of the parent class of an
anonymous class
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: sigurdbergsv...@gmail.com
As an enhancement; the ability to call the constructor of the parent class when
creating an anonymous class.
class A {
this(int param) {
}
}
A anonymous = new class A(12) {}
^ ^
--
