[Issue 24279] Conflicting constructors/functions due to default arguments should not compile
https://issues.dlang.org/show_bug.cgi?id=24279 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #1 from Adam D. Ruppe --- I think it has to do with overload resolution not considering the visibility --
[Issue 24279] New: Conflicting constructors/functions due to default arguments should not compile
https://issues.dlang.org/show_bug.cgi?id=24279
Issue ID: 24279
Summary: Conflicting constructors/functions due to default
arguments should not compile
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: huskyna...@protonmail.ch
When constructors or functions conflict due to having the same calling
signature, they should not be allowed to compile.
This is already the case in most scenarios, but when default arguments cause
conflict, the compiler does not catch this issue. Even more so, in the case of
constructors, visibility rules are ignored.
Example:
```d
module text;
import std.stdio;
class Text {
string text;
private this(string text) {
writeln("private");
}
this(string filename, string arg2 = ".txt") {
writeln("public");
}
}
```
```d
module app;
void main(){
Text t = new Text("file"); // writes "private"
}
```
Calling `new Text("test")` from anywhere will call the first constructor,
ignoring its `private` attribute.
If this is done with functions instead of constructors, the same thing will
happen with one exception: the compiler will state the function is not
accessible. (It will however try to resolve to the private function, ignoring
the accessible alternative)
1. This hints at issues with constructors ignoring visibility attributes!
2. The code should not compile when conflicts occur (even when this is due to
default values).
--
[Issue 14850] Concatenation of static arrays should have compile-time length
https://issues.dlang.org/show_bug.cgi?id=14850 --- Comment #4 from Nick Treleaven --- Also, concatenation of static arrays could be allowed with @nogc iff assigned to a static array. Currently that errors. --
[Issue 14850] Concatenation of static arrays should have compile-time length
https://issues.dlang.org/show_bug.cgi?id=14850 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Summary|VRP should work |Concatenation of static |consistently through all|arrays should have |array ops |compile-time length --- Comment #3 from Nick Treleaven --- This is the only remaining case, renamed issue: > 4) c = a[] ~ b[]; //No error until runtime Same goes for `c = a ~ b;`. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #20 from RazvanN --- (In reply to Andrej Mitrovic from comment #0) > extern(C) void fail(int[4] x); > extern(C) int[4] fail2(); > extern(C++) void fail3(int[4] x); > extern(C++) int[4] fail4(); > > These should fail since C/C++ compilers always pass arrays by pointer to > first element. The last 2 declarations fails in today's compiler. I guess we can do the same for the first 2. --
[Issue 3572] declaring pure function with void return type should be compile time error
https://issues.dlang.org/show_bug.cgi?id=3572
--- Comment #10 from Michal Minich ---
Agreed. even
pure void nothrow never() { assert(false); }
can throw Error, which is observable effect.
--
[Issue 3572] declaring pure function with void return type should be compile time error
https://issues.dlang.org/show_bug.cgi?id=3572
Dennis changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC||dkor...@live.nl
Resolution|--- |INVALID
--- Comment #9 from Dennis ---
(In reply to yebblies from comment #8)
> eg.
> pure void foo(string x)
> By definition calling foo does no observable work.
False.
```
pure void foo(string x) {
throw new Exception(x);
}
```
Here's a nothrow one:
```
pure nothrow void assertPositive(int x) {
assert(x > 0);
}
```
> While this might be WONTFIX or LATER like issue 3882, it is not invalid.
Until a case can be identified where there is actually "no observable work"
guaranteed, this is invalid.
(And even then, it's debatable whether "no observable work" is enough grounds
to make something not compile. `int x = 0; x += 0;` does nothing, but it does
and should compile.)
--
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #11 from anonymous4 --- (In reply to Victor Porton from comment #7) > By the way, we should raise the task to completely replace Ada. There should > be no unpredictable crashes. That's more or less the plan for Safe D. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #10 from anonymous4 --- Should be detectable by dscanner on syntax level: if rhs is a template named Scoped and lhs is not an `auto` declared variable. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #9 from anonymous4 --- (In reply to Victor Porton from comment #5) > If it requires compiler changes specifically for Scoped implementation, it > should be done, Scoped is a very important construct and deserves special > compiler support. Sounds like lint. There's https://github.com/dlang-community/D-Scanner I think it can be taught to detect such Scoped unwrapping. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #8 from Simen Kjaeraas --- There is no unpredictable crash in this case - the crash is perfectly predictable. And no, it's not like saying C does what it should - it's like saying Rust does what it should because you can do unsafe stuff in unsafe blocks. You're punching yourself in the face and telling the doctor it hurts when you do so. The solution is to stop punching yourself in the face. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #7 from Victor Porton --- It is the same as if you were to say: C does what it should do, it crashes programs. I utterly disagree. Crash on T x = Scoped!T(); is a BUG in reliability. Not a bug in the implementation, but a bug in reliability. These are two different kinds of bugs, but both categories are bugs. By the way, we should raise the task to completely replace Ada. There should be no unpredictable crashes. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #6 from Simen Kjaeraas --- Scoped!T is like goto - the default advice is "don't use it". When you're ready, you'll know. Scoped!T should probably be marked as dark magic in the documentation, because that's what it is. It's a useful tool, but you need to know what you're doing, and this should be properly conveyed by documentation. Beyond that, there is no bug here - the language is doing what it should. This is equivalent to you putting your finger in the circular saw and demanding it be replaced with a hand saw. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #5 from Victor Porton --- No, I propose to fix the bug, not to remove a feature. The measures of https://dlang.org/spec/memory-safe-d.html are not enough, because Scoped is a very special case and need to be done in some special way, to eliminate this blatant reliability BUG. If it requires compiler changes specifically for Scoped implementation, it should be done, Scoped is a very important construct and deserves special compiler support. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #4 from anonymous4 --- Safe D is an ongoing effort to fix such bugs, see https://dlang.org/spec/memory-safe-d.html Or do you propose to remove Scoped from phobos? --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 --- Comment #3 from Victor Porton --- This "by design" is very disgracing. Need to do something. If to make it more reliable it's needed compiler changes, a new compiler "directive" should be added. @safe being missing should make harmlessly looking seemingly good program crash without any warning in an unpredictable way! It is a reliability BUG, not just a misfeature. As it is a bug, fix it. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 anonymous4 changed: What|Removed |Added Keywords||safe Status|NEW |RESOLVED Hardware|x86_64 |All Resolution|--- |INVALID OS|Linux |All --- Comment #2 from anonymous4 --- He assigns scoped to SoundCard, and scoped gets deallocated before next statement. This is by design, mark main with @safe attribute to prevent this. --
[Issue 20137] A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Component|dmd |phobos --- Comment #1 from RazvanN --- I'm not sure this is a bug. Even if it is, it is not a dmd one. `scoped` is implemented as a template function that returns a `struct Scoped`. `struct Scoped` has an alias this to the class instance and it somehow gets messed up. I suspect this is due to an internal bug in scoped. --
[Issue 20137] New: A program crashes at runtime (should be compile error)
https://issues.dlang.org/show_bug.cgi?id=20137
Issue ID: 20137
Summary: A program crashes at runtime (should be compile error)
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: por...@narod.ru
The following program crashes at runtime. There should be instead a compile
error.
DMD64 D Compiler v2.087.1
///
import std.typecons;
class SoundCard {
void setDivider() { }
}
void main(string[] args) {
SoundCard sc = scoped!SoundCard();
sc.setDivider();
}
--
[Issue 6988] char a = 'ä'; should not compile
https://issues.dlang.org/show_bug.cgi?id=6988 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --
[Issue 14366] DMD should not compile SDC test0174.d
https://issues.dlang.org/show_bug.cgi?id=14366 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --
[Issue 14366] DMD should not compile SDC test0174.d
https://issues.dlang.org/show_bug.cgi?id=14366 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com --- (In reply to Shammah Chancellor from comment #2) What? No warning is printed. Why aren't warnings printed by default -- that seems bad. It's current dmd behavior. So this issue is a duplication of enhancement 14367. *** This issue has been marked as a duplicate of issue 14367 *** --
[Issue 14366] New: DMD should not compile SDC test0174.d
https://issues.dlang.org/show_bug.cgi?id=14366
Issue ID: 14366
Summary: DMD should not compile SDC test0174.d
Product: D
Version: unspecified
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: shammah.chancel...@gmail.com
```
../bin/sdc test0174.d
case 1:
^~~
test0174.d:9: error: Fallthrough is disabled, use goto case.
```
```test0174.d
//T compiles:no
//T has-passed:yes
// Must use goto case
void main() {
switch(0) {
case 0:
int i;
case 1:
default:
}
}
```
--
[Issue 14366] DMD should not compile SDC test0174.d
https://issues.dlang.org/show_bug.cgi?id=14366 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #1 from ag0ae...@gmail.com --- This is a warning at the moment. --
[Issue 14366] DMD should not compile SDC test0174.d
https://issues.dlang.org/show_bug.cgi?id=14366 --- Comment #2 from Shammah Chancellor shammah.chancel...@gmail.com --- What? No warning is printed. Why aren't warnings printed by default -- that seems bad. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #19 from Walter Bright bugzi...@digitalmars.com --- See: https://github.com/D-Programming-Language/dmd/pull/4129 for D1. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #18 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Dicebot from comment #16) I am not proposing to prohibit ref-static-arrays, it would have been too much of a breakage indeed. But situation with plain static array arguments does sound too error-prone and impractical too keep. Think about it that way - because of this issue you can't just take C header and tweak it until it compiles as D code - it can still segfault at runtime after. If we can supersede druntime's usage of extern(C) for name mangling, I think I'm OK with making any extern(C) function that accepts a non-ref static array an error. (In reply to Dicebot from comment #15) Are there any legit extern(C) declaration in druntime at all or everything needs to be updated? I'll do the PR. I think it's for historical reasons mainly -- the original version of phobos (before druntime) had C implementations of some things, so the compiler always hooked with C mangling. But I think this is a good question to ask the whole community. It could very well be that some people call the functions from C. However, I'm fairly certain most of the extern(C) declarations are simply for name mangling and getting around attribute requirements where needed. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Mike Parker aldac...@gmail.com changed: What|Removed |Added CC||aldac...@gmail.com --- Comment #14 from Mike Parker aldac...@gmail.com --- (In reply to Dicebot from comment #7) The fact that `ref` parameters are allowed for extern(C) functions is even more bizzare than the fact that static array arguments crash programs. Need to check if it works, I would have never guessed to even try it. This is documented. See the section Passing D Array Arguments to C Functions at http://dlang.org/interfaceToC.html. If anyone wants examples of existing code that will be broken by this, see Derelict. DerelictODE in particular, in which the matrix and vertex types are typedefed on the C side as fixed-size arrays and passed as such to all the functions that use them. Personally, I don't see the problem with prototyping such C functions with ref. I hope it *doesn't* change. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #15 from Dicebot pub...@dicebot.lv --- (In reply to Steven Schveighoffer from comment #13) This is abuse and needs to be fixed. We have pragma(mangle) to override mangling. I wasn't aware that we had a C mangling feature. We should change this ASAP, as I don't like the idea of specifying C functions for the sole purpose of escaping typechecking. If we fixed this, perhaps you have a better case for changing this. Are there any legit extern(C) declaration in druntime at all or everything needs to be updated? I'll do the PR. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Dicebot pub...@dicebot.lv changed: What|Removed |Added Priority|P1 |P2 Severity|regression |critical --- Comment #16 from Dicebot pub...@dicebot.lv --- (In reply to Mike Parker from comment #14) (In reply to Dicebot from comment #7) The fact that `ref` parameters are allowed for extern(C) functions is even more bizzare than the fact that static array arguments crash programs. Need to check if it works, I would have never guessed to even try it. This is documented. See the section Passing D Array Arguments to C Functions at http://dlang.org/interfaceToC.html. I don't think complementary articles can be considered part of main spec - need to copy that definitions to `extern(C)` spec itself or at least place a direct link there. If anyone wants examples of existing code that will be broken by this, see Derelict. DerelictODE in particular, in which the matrix and vertex types are typedefed on the C side as fixed-size arrays and passed as such to all the functions that use them. Personally, I don't see the problem with prototyping such C functions with ref. I hope it *doesn't* change. I am not proposing to prohibit ref-static-arrays, it would have been too much of a breakage indeed. But situation with plain static array arguments does sound too error-prone and impractical too keep. Think about it that way - because of this issue you can't just take C header and tweak it until it compiles as D code - it can still segfault at runtime after. I will lower importance/priority though because of mentioned workaround with `ref` that makes it possible to preserve API safety --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #17 from Mike Parker aldac...@gmail.com --- (In reply to Dicebot from comment #16) I am not proposing to prohibit ref-static-arrays, it would have been too much of a breakage indeed. But situation with plain static array arguments does sound too error-prone and impractical too keep. Think about it that way - because of this issue you can't just take C header and tweak it until it compiles as D code - it can still segfault at runtime after. Yes, I see. I got things mixed up. No argument there. That actually was a problem for me before I realized that ref worked. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Dicebot pub...@dicebot.lv changed: What|Removed |Added Keywords||industry Priority|P2 |P1 Status|RESOLVED|REOPENED CC||pub...@dicebot.lv Resolution|WONTFIX |--- Severity|normal |regression --- Comment #3 from Dicebot pub...@dicebot.lv --- Reopining it and marking as critical regression issue. Also with industry keyword. This is regression from D1 behaviour that makes all of our existing extern(C) bindings segfault when compiled with D2 compiler. Only workaroun possible to replace it with pointer arguments everywhere, losing important chunk of type safety in process. However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. Walter original reasoning about breaking original code is completely unapplicable here as any code that currently compiles with this pattern will segfault at runtime anyway. There can't be any legit working code out there to break. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #4 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Dicebot from comment #3) However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. Wouldn't ref work? It seems to work for me. -Steve --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #5 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Steven Schveighoffer from comment #4) (In reply to Dicebot from comment #3) However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. Wouldn't ref work? It seems to work for me. Sorry, I quoted the wrong part of your post, it should have been: (In reply to Dicebot from comment #3) This is regression from D1 behaviour that makes all of our existing extern(C) bindings segfault when compiled with D2 compiler. Only workaroun possible to replace it with pointer arguments everywhere, losing important chunk of type safety in process. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #6 from bearophile_h...@eml.cc --- (In reply to Dicebot from comment #3) However I don't like compilation failure here either. extern(C) functions must comply to C ABI and thus pass static arrays by pointer even if normal D functions do that by value. I think that a compilation failure is better because it avoids to introduce a special case in the D language. Special cases cause problems, even when they look a little handy. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #7 from Dicebot pub...@dicebot.lv --- The fact that `ref` parameters are allowed for extern(C) functions is even more bizzare than the fact that static array arguments crash programs. Need to check if it works, I would have never guessed to even try it. In general we have looks like C, works like C slogan. My point is that this is especially important with function _explicitly_ marked as should work like C - any mismatch between extern(C) ABI and real C ABI is an important bug. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #8 from Dicebot pub...@dicebot.lv --- (In reply to bearophile_hugs from comment #6) I think that a compilation failure is better because it avoids to introduce a special case in the D language. Special cases cause problems, even when they look a little handy. There is no special case here - extern(C) by definition must implement C ABI of argument passing. It is simply out of D language domain ones arguments are passed. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #9 from bearophile_h...@eml.cc --- (In reply to Dicebot from comment #8) There is no special case here - extern(C) by definition must implement C ABI of argument passing. It is simply out of D language domain ones arguments are passed. D fixed-size arrays are values. C language lacks those values, so I think D doesn't have a C ABI to respect. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #10 from Dicebot pub...@dicebot.lv --- C has static arrays. C allows passing static arrays as function arguments. HOW it is passing them is defined by ABI and D rules are irrelevant here. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #11 from Steven Schveighoffer schvei...@yahoo.com --- The issue here is -- we use the non-mangling feature of C calls to override type checking inside druntime. So even if something is extern(C) it can actually be implemented in D. That function may never need to be called or used in C code at all. Why shouldn't D support ref for C? All it is doing is auto-taking the address of the parameter, which maps perfectly to accepting a pointer or array argument. I think the important pieces of the C ABI to implement are where parameters go, and the lack of name mangling. Other than that, how to pass certain types is more fuzzy. As another example, on a 32-bit system, C's long is 32-bit. But D's long is 64 bit. What to do here? extern(C) foo(long x); Clearly, it's not too important the type of x, but how big it actually is. This leads one to simply type it as int instead, and move on. This hasn't really caused tremendous issues or difficulties. I think really the crux of the push for this bug is more that D2 behaves differently vs. D1 than D2 implements the C ABI incorrectly. Note, I remember the ref trick when we moved to passing static arrays by value, for the system call pipe. This takes an int[2]. To switch this to a pointer not only breaks existing code, but we lose the type requirement that it should be exactly 2 elements wide. The ref solution worked, so we employed it, and I think it was the right move. --
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
https://issues.dlang.org/show_bug.cgi?id=8887 --- Comment #12 from Dicebot pub...@dicebot.lv --- (In reply to Steven Schveighoffer from comment #11) The issue here is -- we use the non-mangling feature of C calls to override type checking inside druntime. So even if something is extern(C) it can actually be implemented in D. That function may never need to be called or used in C code at all. This is abuse and needs to be fixed. We have pragma(mangle) to override mangling. http://dlang.org/attribute.html#linkage is pretty clear on legitimate use cases this feature was designed for. Why shouldn't D support ref for C? All it is doing is auto-taking the address of the parameter, which maps perfectly to accepting a pointer or array argument. Exactly because it is special case - it takes a language feature that does not have clear mapping to C feature and makes use of ABI details to work it as-is. It is not bad on its own but quite puzzling. As another example, on a 32-bit system, C's long is 32-bit. But D's long is 64 bit. What to do here? extern(C) foo(long x); Ideally this should use C interpretation too but I recognize how it is totally impractical. This is not the case for static array arguments. Note, I remember the ref trick when we moved to passing static arrays by value, for the system call pipe. This takes an int[2]. To switch this to a pointer not only breaks existing code, but we lose the type requirement that it should be exactly 2 elements wide. The ref solution worked, so we employed it, and I think it was the right move. You call tweaking own code (that makes use of undefined language area) to address compiler regression a right move? --
[Issue 12924] deprecated(foo); and deprecated; should not compile
https://issues.dlang.org/show_bug.cgi?id=12924 --- 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/4b2578e208f2af9a02159fc2d8d87fb17b09005e fix Issue 12924 - deprecated(foo); and deprecated; should not compile 'DeclarationBlock' that follows 'Attribute' should be parsed by parseBlock. `PrefixAttribute` is used to check redundant/conflicting attributes over the mutual call between `parseDeclDefs` and `parseBlock`. https://github.com/D-Programming-Language/dmd/commit/77f4e95af6cf1fd2dd80902ec122a23f1358fd1f Merge pull request #3676 from 9rnsr/fix12924 [REG2.066a] Issue 12924 - deprecated(foo); and deprecated; should not compile --
[Issue 12924] deprecated(foo); and deprecated; should not compile
https://issues.dlang.org/show_bug.cgi?id=12924 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12924] deprecated(foo); and deprecated; should not compile
https://issues.dlang.org/show_bug.cgi?id=12924 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||accepts-invalid, pull Version|unspecified |D2 Severity|normal |regression --- Comment #1 from Kenji Hara k.hara...@gmail.com --- This is git-head regression caused by the parser improvement: https://github.com/D-Programming-Language/dmd/pull/2924 Compiler fix: https://github.com/D-Programming-Language/dmd/pull/3676 --
[Issue 12924] New: deprecated(foo); and deprecated; should not compile
https://issues.dlang.org/show_bug.cgi?id=12924
Issue ID: 12924
Summary: deprecated(foo); and deprecated; should not compile
Product: D
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: jmdavisp...@gmx.com
This code compiles with no errors or deprecation messages:
deprecated(Don't use me!);
void foo()
{
}
void main()
{
foo();
}
Of course, what it should be is
deprecated(Don't use me!)
void foo()
{
}
void main()
{
foo();
}
and that _will_ give a deprecation warning. However, I don't think that the
problem is that the first example doesn't give a deprecation warning. Rather,
it should be an error, as deprecated isn't a statement. It's an attribute.
Whether there is a message or not doesn't seem to affect anything, e.g.
deprecated;
void foo()
{
}
void main()
{
foo();
}
also compiles with no errors or deprecation warnings.
--
[Issue 12630] @nogc should recognize compile-time evaluation context
https://issues.dlang.org/show_bug.cgi?id=12630 --- 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/1cc42872f9e2489b8663c3d7d9e2bc7e422102b3 fix Issue 12630 - @nogc should recognize compile-time evaluation context https://github.com/D-Programming-Language/dmd/commit/e3afe41cf289d2cbbeccfdb18b49990ccdfe031e Merge pull request #3493 from 9rnsr/fix12630 Issue 12630 - @nogc should recognize compile-time evaluation context --
[Issue 12630] New: @nogc should recognize compile-time evaluation context
https://issues.dlang.org/show_bug.cgi?id=12630
Issue ID: 12630
Summary: @nogc should recognize compile-time evaluation context
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
This code should be compiled with -o-, but doesn't.
void main() @nogc
{
static const ex1 = new Exception(invalid);
//enum ex2 = new Exception(invalid);
static const arr1 = [[1,2], [3, 4]];
enum arr2 = [[1,2], [3, 4]];
static const aa1 = [1:1, 2:2];
enum aa2 = [1:1, 2:2];
static const v1 = aa1[1];
enum v2 = aa2[1];
Object o;
static const del1 = (delete o).sizeof;
enum del2 = (delete o).sizeof;
int[] a;
static const len1 = (a.length = 1).sizeof;
enum len2 = (a.length = 1).sizeof;
static const cata1 = (a ~= 1).sizeof;
enum cata2 = (a ~= 1).sizeof;
static const cat1 = (a ~ a).sizeof;
enum cat2 = (a ~ a).sizeof;
}
--
[Issue 12630] @nogc should recognize compile-time evaluation context
https://issues.dlang.org/show_bug.cgi?id=12630 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3493 --
[Issue 12525] New: Code takes longer than it should to compile
https://d.puremagic.com/issues/show_bug.cgi?id=12525
Summary: Code takes longer than it should to compile
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: michaelpm...@gmail.com
--- Comment #0 from Michael M michaelpm...@gmail.com 2014-04-05 08:29:57 PDT
---
Test case below
_
enum SIZE = 0x1;
struct a {
int member;
}
struct b {
a[SIZE] array;
}
void main(){}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12525] Code takes longer than it should to compile
https://d.puremagic.com/issues/show_bug.cgi?id=12525 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-04-05 17:30:56 CEST --- *** This issue has been marked as a duplicate of issue 12509 *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9773] ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773 --- Comment #5 from github-bugzi...@puremagic.com 2013-05-17 13:01:16 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fe00d71443844f0261e0dd39b9c97ed3172b8527 Merge pull request #1829 from 9rnsr/fix9773 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9773] ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773 --- Comment #4 from github-bugzi...@puremagic.com 2013-05-15 01:10:00 PDT --- Commit pushed to 2.063 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fe00d71443844f0261e0dd39b9c97ed3172b8527 Merge pull request #1829 from 9rnsr/fix9773 Issue 9773 - ref parameter with default string literal should not compile -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9773] ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773 --- Comment #3 from github-bugzi...@puremagic.com 2013-04-04 12:58:18 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/706b18758a63715aef4b1821e7b66b1d4e5ee467 fix Issue 9773 - ref parameter with default string literal should not compile https://github.com/D-Programming-Language/dmd/commit/630e484c7e20cb156bf71404a342a8b98459cfde Merge pull request #1829 from 9rnsr/fix9773 Issue 9773 - ref parameter with default string literal should not compile -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9773] ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9773] ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-04-03
00:10:22 PDT ---
(In reply to comment #0)
This should not compile.
void f( ref string a = )
{
a = crash and burn;
}
int main()
{
f(); // seg fault
return 0;
}
P.S. isn't there a way we can put string literals in some kind of ROM on
Windows? It's just insane that it doesn't crash on Windows (ancient problem, I
know):
import std.stdio;
void f(ref string a = )
{
a = crash and burn;
}
void main()
{
f();
writeln(); // 'crash and burn'
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9773] ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-04-02 19:33:46 PDT --- https://github.com/D-Programming-Language/dmd/pull/1829 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9773] New: ref parameter with default value should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=9773
Summary: ref parameter with default value should not compile
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: al...@ucora.com
--- Comment #0 from Rob T al...@ucora.com 2013-03-21 01:00:44 PDT ---
This should not compile.
void f( ref string a = )
{
a = crash and burn;
}
int main()
{
f(); // seg fault
return 0;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||yebbl...@gmail.com Version|2.036 |D2 Resolution|INVALID | Severity|normal |enhancement --- Comment #8 from yebblies yebbl...@gmail.com 2013-03-06 21:46:46 EST --- (In reply to comment #7) In current, we can declare a pure function which has weak purity. pure void foo(int* p, out string s, ref int[] arr); All results are returned through its parameters. So, returning void itself has no problem in pure functions. This would still be meaningful for strongly-pure or const-pure functions. eg. pure void foo(string x) By definition calling foo does no observable work. While this might be WONTFIX or LATER like issue 3882, it is not invalid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-03 15:53:14 PST --- (In reply to comment #3) (In reply to comment #2) ? Why would you allow out parameters in a pure function? This seems reasonable for simple value types (ints, floats, etc.), but when you start passing objects in, you start allowing the modification of whole object subgraphs from pure functions. This makes no sense. Why doesn't it make sense? Aren't you thinking of inout parameters? A pure function void foo(out A a); ought to be exactly the same as A foo(); together with an assignment. I'm not seeing anything impure in that. BTW, it works fine in CTFE. (CTFE isn't quite the same concept as pure, but it's close). Should we close this report then? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Kenji Hara k.hara...@gmail.com 2013-02-03 18:50:45 PST --- In current, we can declare a pure function which has weak purity. pure void foo(int* p, out string s, ref int[] arr); All results are returned through its parameters. So, returning void itself has no problem in pure functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=8887 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-11-04 16:32:34 PST --- Walter has rejected this. https://github.com/D-Programming-Language/dmd/pull/1215#issuecomment-9770031 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=8887 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from bearophile_h...@eml.cc 2012-11-04 16:48:28 PST --- From Walter: https://github.com/D-Programming-Language/dmd/pull/1215#issuecomment-9770031 This change breaks existing code, What existing code? (And the D1 code that relies on is now broken). requires an awkward workaround for existing uses, Even if they exist they are niche usages, right? It's better to keep the D semantics saner/cleaner. As Python Zen says, few special cases are not special enough to justify this hole in the D type system. In D it's important not just to fix holes in the design of C, but also holes coming from changes between D1 and D2. I think this type system hole was an oversight while D2 fixed-sized array semantics argument pass changed. and has only a marginal benefit. The benefit is helping all future C programmers that don't remember that D passes fixed-sized arrays by value, for years and years to come. From my experience I've seen that lot of people don't remember that. Those C programmers will write extern(C) and they will come in the D.learn group to ask why their code doesn't work. I will try to keep count how many such posts will appear in D.learn. One of the design rules of D is that D acts as C or it gives an error. In this case it silently passes wrong data to C functions, so here there's a breaking of the D design rules. So I think this hole should be fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8485] New: referencing a deprecated symbol should never compile
http://d.puremagic.com/issues/show_bug.cgi?id=8485
Summary: referencing a deprecated symbol should never compile
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2012-07-31 05:33:45 PDT ---
DMD 2.059 accepts the following code:
deprecated int x;
void main(){ static assert(!is(typeof(x))); }
It should be rejected, or symbol deprecation and the -d switch can change the
meaning of valid code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6988] char a = '�'; should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=6988 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-01 14:48:05 EST --- *** This issue has been marked as a duplicate of issue 6458 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 Trass3r mrmoc...@gmx.de changed: What|Removed |Added Keywords||accepts-invalid, diagnostic CC||mrmoc...@gmx.de Platform|x86 |All OS/Version|Windows |All Severity|enhancement |normal --- Comment #5 from Trass3r mrmoc...@gmx.de 2012-01-05 14:19:40 PST --- Also you shouldn't be able to throw away the result of a pure function. http://d.puremagic.com/issues/show_bug.cgi?id=7235 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6988] New: char[] chars = ['�','�','�']; should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=6988
Summary: char[] chars = ['�','�','�']; should not compile
Product: D
Version: unspecified
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@metalanguage.com
--- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2011-11-22
09:13:42 PST ---
unittest
{
char[] chars = ['�','�','�'];
assert(chars == ���);
}
The assertion fails for the obvious reason there's no room in chars for the
multibyte characters. The initialization should not compile because it attempts
to truncate wide characters into meaningless bytes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6988] char a = '�'; should not compile
http://d.puremagic.com/issues/show_bug.cgi?id=6988
Trass3r mrmoc...@gmx.de changed:
What|Removed |Added
Keywords||accepts-invalid, diagnostic
CC||mrmoc...@gmx.de
Summary|char[] chars = |char a = '�'; should not
|['�','�','�']; should not |compile
|compile |
--- Comment #1 from Trass3r mrmoc...@gmx.de 2011-11-22 12:19:23 PST ---
It's more general:
void main()
{
char a = '�'; // compiles fine
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 --- Comment #4 from David Simcha dsim...@yahoo.com 2010-02-17 18:38:36 PST --- (In reply to comment #3) Why doesn't it make sense? Aren't you thinking of inout parameters? A pure function void foo(out A a); ought to be exactly the same as A foo(); together with an assignment. I'm not seeing anything impure in that. BTW, it works fine in CTFE. (CTFE isn't quite the same concept as pure, but it's close). You're right, I did get confused between out and ref. Allowing out parameters in pure functions makes sense. I tend to forget how out parameters work because I almost never use them. I almost always just return a tuple or a struct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3572] New: declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 Summary: declaring pure function with void return type should be compile time error Product: D Version: 2.036 Platform: x86 OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: michal.min...@gmail.com --- Comment #0 from Michal Minich michal.min...@gmail.com 2009-12-04 02:37:33 PST --- In D specification is written: Pure functions are functions that produce the same result for the same arguments. To that end, a pure function has parameters that are all immutable or are implicitly convertible to immutable void function cannot produce any result, thus they are meaningless as pure functions. Also when all parameters are implicitly immutable, there is no possibility to modify out parameters. So the only way for function to produce result, is by returning it (and void has no value). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2009-12-04 12:01:56 PST --- (In reply to comment #0) In D specification is written: Pure functions are functions that produce the same result for the same arguments. To that end, a pure function has parameters that are all immutable or are implicitly convertible to immutable void function cannot produce any result, thus they are meaningless as pure functions. Also when all parameters are implicitly immutable, there is no possibility to modify out parameters. So the only way for function to produce result, is by returning it (and void has no value). I think the restriction on 'out' parameters will be removed. I don't think there's any reason for it. A void pure function that doesn't have any 'out' parameters does seem to be pretty useless (you can use it as a metaprogramming test that anything inside it is pure, but that's about all I can think of). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3572] declaring pure function with void return type should be compile time error
http://d.puremagic.com/issues/show_bug.cgi?id=3572 --- Comment #3 from Don clugd...@yahoo.com.au 2009-12-04 18:28:11 PST --- (In reply to comment #2) ? Why would you allow out parameters in a pure function? This seems reasonable for simple value types (ints, floats, etc.), but when you start passing objects in, you start allowing the modification of whole object subgraphs from pure functions. This makes no sense. Why doesn't it make sense? Aren't you thinking of inout parameters? A pure function void foo(out A a); ought to be exactly the same as A foo(); together with an assignment. I'm not seeing anything impure in that. BTW, it works fine in CTFE. (CTFE isn't quite the same concept as pure, but it's close). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: should not compile
On Sun, Mar 1, 2009 at 11:19 AM, M. Z. Hossain z_hoss...@icmail.net wrote:
This code should not compile without any complain.
class C {
this(int t) {;}
this() {;}
this() {;}
}
void main() {
new C(0);
}
OPTLINK (R) for Win32 Release 8.00.1
Copyright (C) Digital Mars 1989-2004 All rights reserved.
test2.obj(test2) Offset 002D6H Record Type 00C3
Error 1: Previous Definition Different : _D5test21C5_ctorMFZC5test21C
--- errorlevel 1
No, it should compile with a complaint, except the compiler should be
the one complaining, not the linker.
