[Issue 2469] ICE(cod1.c) arbitrary struct accepted as struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=2469 --- Comment #8 from Don 2009-08-08 22:21:44 PDT --- There's a patch for the original bug in bug 2702. It's unrelated to the ICE. (It's really annoying when new bugs are reported in the comments for existing bugs, it's not clear what to do with them). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2702] Struct initialisation silently inserts deadly casts
http://d.puremagic.com/issues/show_bug.cgi?id=2702 --- Comment #3 from Don 2009-08-08 22:19:09 PDT --- I have confirmed that after completely removing that section of code, the DMD test suite still passes all tests. I tried to construct a valid case which required that code, but was unable to find one -- it looks as though that code is ONLY creating bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231
--- Comment #12 from Tim M 2009-08-08 16:42:01 PDT
---
Adding the dot is so trivial and takes no time at all. I do believe that this
is indeed a bug anyway explanation of such:
This code will not compile:
class A
{
void func();
func getFunc()
{
return null;
}
}
void main()
{
}
You cannot return a 'func' as it is not a type. 'func' is actually an instance
of 'delegate' so it should have been declared as that.
class A
{
void func();
void getFunc()
{
new func();
}
}
void main()
{
}
Here 'getFunc' is declared as void but it doesn't compile either because this
time I am trying to new a 'func' which causes a compile error again because
'func' is not a type but an instance of delegate.
Whenever a peice of D code contains 2 identifiers next to each other like so:
AB XY
It can only mean either XY is an instance (whether that be value, ref, of
function returning) and AB is a type. Likewise I can't 'new' everything either.
The bug is simply that dmdfe wasn't attempting to find a type or instance with
the particular name but it was satisfied with the first symbol it found.
If this indeed hard to fixup now (and I would rather Walter focus on more
important issues) then adding a couple of dots is something I wouldn't mind to
do either (it would require a few bytes of code)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231 --- Comment #11 from Stewart Gordon 2009-08-08 16:07:09 PDT --- (In reply to comment #10) > (In reply to comment #9) > > Better beware of hijacking vulnerabilities. > > This is possibly valid, do you have an example that drives your point? I'm not sure if there are any in this particular instance, but it's something to be careful of whenever you try to resolve a symbol to a different scope depending on how it's being used. It may be the case that the worst that can happen here is that the class-level function conflicts with an opCall on the module-level class. While no call of the form Bar(...) is happening here, I can see it getting confusing if one does occur -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 --- Comment #4 from Bartosz Milewski 2009-08-08 15:20:08 PDT --- I simplified the example. It turns out that the destructor of a class object Counter is called. I have no idea what mechanism may call the destructor other than GC. A new file attached. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 --- Comment #3 from Bartosz Milewski 2009-08-08 15:18:14 PDT --- Created an attachment (id=440) --> (http://d.puremagic.com/issues/attachment.cgi?id=440) simplified case with a write in the destructor of Counter -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231 --- Comment #10 from Cristi Vlasceanu 2009-08-08 13:25:53 PDT --- (In reply to comment #9) > (In reply to comment #5) > > I think that marking the bug as invalid because of a limitation in the > > implementation is ridiculous. > > AIUI this isn't a limitation in the implementation, but a characteristic of > how > D is designed. > > > The fix (which I am applying to the my source tree at > > http://dnet.codeplex.com/) is very simple: continue the look up in enclosing > > scope. > > Better beware of hijacking vulnerabilities. This is possibly valid, do you have an example that drives your point? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright 2009-08-08 13:23:38 PDT --- compile with -gc and run under windbg, the windows debugger. Shows that it crashes because _cnt is null in the first line of release(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2476] std.stdio fails to compile
http://d.puremagic.com/issues/show_bug.cgi?id=2476 Brad Roberts changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||FIXED --- Comment #8 from Brad Roberts 2009-08-08 12:59:11 PDT --- dmd.conf was fixed to include druntime's path long ago. Marking resolved. Please reopen with a complete description of the current problem if there's anything left to do here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3231] Function declared to return a type with its same name doesn't compile
http://d.puremagic.com/issues/show_bug.cgi?id=3231 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment #9 from Stewart Gordon 2009-08-08 12:37:01 PDT --- (In reply to comment #5) > I think that marking the bug as invalid because of a limitation in the > implementation is ridiculous. AIUI this isn't a limitation in the implementation, but a characteristic of how D is designed. > The fix (which I am applying to the my source tree at > http://dnet.codeplex.com/) is very simple: continue the look up in enclosing > scope. Better beware of hijacking vulnerabilities. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] New: Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 Summary: Access Violation during reference counting Product: D Version: 2.032 Platform: x86 OS/Version: Windows Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bart...@relisoft.com RcName is a struct that does reference counting. When I store an instance of RcName in an object, everything seems to go fine, except that I get an access violation during the final destruction. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3237] Access Violation during reference counting
http://d.puremagic.com/issues/show_bug.cgi?id=3237 --- Comment #1 from Bartosz Milewski 2009-08-08 12:31:46 PDT --- Created an attachment (id=439) --> (http://d.puremagic.com/issues/attachment.cgi?id=439) test case for access violatin while reference counting -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2864] intra-module use of deprecated should be allowed
http://d.puremagic.com/issues/show_bug.cgi?id=2864 Stewart Gordon changed: What|Removed |Added CC||s...@iname.com --- Comment #2 from Stewart Gordon 2009-08-08 12:17:10 PDT --- The problems are: - even when developing your own library, you'll likely want reminding if you inadvertently use one of your own deprecated entities - when you're ready to release a stable version of your product, you ought to be able to just delete everything that's deprecated and be done with it Perhaps better would be some form of 'deprecatedly public' as I suggested once http://www.digitalmars.com/d/archives/digitalmars/D/Suggestion_More_deprecation_features_73796.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3236] New: Postblit called but no matching destructor
http://d.puremagic.com/issues/show_bug.cgi?id=3236 Summary: Postblit called but no matching destructor Product: D Version: 2.032 Platform: All OS/Version: Windows Status: NEW Keywords: wrong-code Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bart...@relisoft.com Created an attachment (id=438) --> (http://d.puremagic.com/issues/attachment.cgi?id=438) Test case for incorrect reference counting RcName is a struct that defines postblit, this(this), in order to implement reference counting. When I store the result of a call and then return it: RcName rc = create(); return rc; I get the right reference count. But if I return directly: return create(); postblit is called (increasing ref count), but the destructor is not, so I end up with ref count that is too big -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as "function" or "delegate"
http://d.puremagic.com/issues/show_bug.cgi?id=3235 Andrei Alexandrescu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #4 from Andrei Alexandrescu 2009-08-08 11:57:05 PDT --- (In reply to comment #2) > This is as designed. > > http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral > "If the keywords function or delegate are omitted, it defaults to being a > delegate." > > Having the type of a function/delegate literal depend on its contents like > this > makes it hard for someone reading the code to tell which it is. Since > function > pointers and delegates are not generally interchangeable, AISI it's desirable > to keep their literal notations distinct. I think type deduction should help here as much as anywhere else. If you do want a delegate, you can always use the delegate keyword. Plus, all algorithms in std.algorithm take an efficiency toll when used with literals. (Please do not mark this as resolved; I've discussed with Walter before posting it, and he suggested I do. In general, the spec of D2 is fluid enough to not be a strong reason for invalidating a bug report. Thanks.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as "function" or "delegate"
http://d.puremagic.com/issues/show_bug.cgi?id=3235 --- Comment #3 from Andrei Alexandrescu 2009-08-08 11:55:19 PDT --- (In reply to comment #2) > This is as designed. > > http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral > "If the keywords function or delegate are omitted, it defaults to being a > delegate." > > Having the type of a function/delegate literal depend on its contents like > this > makes it hard for someone reading the code to tell which it is. Since > function > pointers and delegates are not generally interchangeable, AISI it's desirable > to keep their literal notations distinct. I think type deduction should help here as much as anywhere else. If you do want a delegate, you can always use the delegate keyword. Plus, all algorithms in std.algorithm take an efficiency toll when used with literals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as "function" or "delegate"
http://d.puremagic.com/issues/show_bug.cgi?id=3235 Stewart Gordon changed: What|Removed |Added Status|NEW |RESOLVED CC||s...@iname.com Resolution||INVALID --- Comment #2 from Stewart Gordon 2009-08-08 11:14:14 PDT --- This is as designed. http://www.digitalmars.com/d/1.0/expression.html#FunctionLiteral "If the keywords function or delegate are omitted, it defaults to being a delegate." Having the type of a function/delegate literal depend on its contents like this makes it hard for someone reading the code to tell which it is. Since function pointers and delegates are not generally interchangeable, AISI it's desirable to keep their literal notations distinct. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1977] Relax warnings (D1)/errors (D2) for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 Andrei Alexandrescu changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #23 from Andrei Alexandrescu 2009-08-08 09:39:54 PDT --- (In reply to comment #22) > (In reply to comment #21) > > I'm only worrying about D2 where implicit narrowing conversions is part of the > spec. ulong%1000 should implicitly allowed when assigning to an integer. > Should > it be a distinct bugzilla entry? Range value propagation, which was implemented recently, should take care of this. It's among the simplest examples that should work with range value propagation. The compiler must infer that a % 1000 has range -999 through 999 and therefore should allow it to fit in a short or int. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1977] Relax warnings (D1)/errors (D2) for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 --- Comment #22 from Jason House 2009-08-08 09:17:31 PDT --- (In reply to comment #21) I'm only worrying about D2 where implicit narrowing conversions is part of the spec. ulong%1000 should implicitly allowed when assigning to an integer. Should it be a distinct bugzilla entry? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1977] Relax warnings (D1)/errors (D2) for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 Stewart Gordon changed: What|Removed |Added Version|2.012 |unspecified Summary|Relax warnings for implicit |Relax warnings (D1)/errors |narrowing conversions |(D2) for implicit narrowing |caused by promotions|conversions caused by ||promotions OS/Version|Linux |All --- Comment #21 from Stewart Gordon 2009-08-08 08:51:28 PDT --- (In reply to comment #20) > Here's a related issue: > > long a; > ... > int b = a % 1000; > > The sample above gives an error that it can't implicitly convert to int, even > though this us exactly the kind of thing implicit narrowing conversions should > handle. That's different, since it isn't due to promotions beyond the lowest common denominator of the operand types. The best way to deal with this is to spec that the type of a % expression (and similarly &) on integers is the smaller of the operands' types. There's no loss of significant digits this way, at least if they're both signed or both unsigned. But if one's signed and the other's unsigned, _then_ what should happen? If you're worried about breaking existing D1 code, this can still be achieved by doing this only to the base type and not the promoted type (using the terminology I introduced at http://www.digitalmars.com/d/archives/24706.html#N24797 ) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3235] Function literals must be deduced as "function" or "delegate"
http://d.puremagic.com/issues/show_bug.cgi?id=3235
--- Comment #1 from Andrei Alexandrescu 2009-08-08
07:17:17 PDT ---
(In reply to comment #0)
> Consider:
>
> void foo(alias pred)() {
> pragma(msg, pred.stringof);
> }
>
> unittest {
> foo!((i) { return i < 0; })();
> int z = 1;
> foo!((i) { return i < z; })();
> }
>
> void main(string[] args)
> {
> }
>
> This outputs:
>
> __funcliteral1(__T2)
> __dgliteral3(__T4)
>
> because the first literal does not have to be a delegate.
I meant that right now this outputs:
__dgliteral1(__T2)
__dgliteral3(__T4)
and it should output:
__funcliteral1(__T2)
__dgliteral3(__T4)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3235] New: Function literals must be deduced as "function" or "delegate"
http://d.puremagic.com/issues/show_bug.cgi?id=3235
Summary: Function literals must be deduced as "function" or
"delegate"
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@metalanguage.com
Consider:
void foo(alias pred)() {
pragma(msg, pred.stringof);
}
unittest {
foo!((i) { return i < 0; })();
int z = 1;
foo!((i) { return i < z; })();
}
void main(string[] args)
{
}
This outputs:
__funcliteral1(__T2)
__dgliteral3(__T4)
because the first literal does not have to be a delegate.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
