[Issue 6278] Regression(2.054 beta): 'in' contract inheritance doesn't work with safe code
http://d.puremagic.com/issues/show_bug.cgi?id=6278
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #8 from Walter Bright bugzi...@digitalmars.com 2012-02-01
00:03:28 PST ---
The concept here is that, if a base function and its override both have an IN
contract, then only one of them needs to succeed. This is done by generating:
void derived.in()
{
try
{
base.in();
}
catch ()
{
... body of derived.in() ...
}
}
So if base.in() doesn't throw, derived.in() need not be executed, and the
contract is valid. If base.in() throws, then derived.in()'s body is executed.
As you can see, it swallows any exception generated by the contract. Whether
this is correct or not is certainly debatable.
I think a reasonable solution which will target this particular thing would be
to mark that try/catch as being valid even in safe mode. That'll change it from
a regression to an enhancement request to figure out a better way, as at least
it'll work as documented.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6278] Regression(2.054 beta): 'in' contract inheritance doesn't work with safe code
http://d.puremagic.com/issues/show_bug.cgi?id=6278 yebblies yebbl...@gmail.com changed: What|Removed |Added Platform|Other |All --- Comment #9 from yebblies yebbl...@gmail.com 2012-02-01 19:18:47 EST --- The problem with just letting it catch all throwables in safe code is that it is _not_ safe, so until we have a better solution I think forcing the user to mark their function as @trusted is actually correct. Exceptions thrown in contracts are supposed to be recoverable, which makes AssertError (or any error) inappropriate. But if asserts inside contracts are changed to throw something else, called functions may still throw AssertErrors that were intended to be caught. On the other hand, an assert hit inside a contract could easily mean the program is in an invalid state, and completely break the guarantees of @safe. I think the best option is to make asserts in contracts throw something else, despite the downsides. I understand you would like to undo the regression, but I think re-opening this hole in @safe is much worse than the current state, especially considering how trivial the workaround is. If you know how you would like the solution to look I'm happy to implement it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6278] Regression(2.054 beta): 'in' contract inheritance doesn't work with safe code
http://d.puremagic.com/issues/show_bug.cgi?id=6278 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Severity|regression |normal --- Comment #12 from Walter Bright bugzi...@digitalmars.com 2012-02-01 00:56:01 PST --- The bug is now that the in contracts can swallow any Errors and leave the program in an invalid state. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 785] Make 'cent' and 'ucent' syntactically valid pending implementation
http://d.puremagic.com/issues/show_bug.cgi?id=785 --- Comment #20 from Andrei Alexandrescu and...@metalanguage.com 2012-02-01 00:58:00 PST --- Focus, that's what we lose. 1. There's no real request for cent and ucent. 2. This let's add a filler doing nothing, discuss it ad nauseam, and consider implement later is an utter waste of time. If someone really wants they can implement it, don't add this useless filler for hypothetical future-proof libraries that don't exist. This breaks a lot of good principles so badly it hurts. 3. We're better off implementing FixedInt!size for large integers of statically-allocated size. Granted, those don't benefit of all possible optimizations but there's more flexibility. Please close this and let's leave it closed. Thanks much. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 785] Make 'cent' and 'ucent' syntactically valid pending implementation
http://d.puremagic.com/issues/show_bug.cgi?id=785 --- Comment #21 from yebblies yebbl...@gmail.com 2012-02-01 20:12:24 EST --- With respect, Andrei, it's my time to waste. A lot more time has been wasted on arguing about it than the 5 minutes it took for me to make a patch that fixed it. 128 bit integer types have been considered possible enough for D that keywords were reserved for them. I fully intend to see them implemented if possible. It seems lately you're frustrated that development effort isn't always directed where you want it, but this is unavoidable in open source projects - people will work on what they want to work on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 785] Make 'cent' and 'ucent' syntactically valid pending implementation
http://d.puremagic.com/issues/show_bug.cgi?id=785 --- Comment #22 from Andrei Alexandrescu and...@metalanguage.com 2012-02-01 01:17:09 PST --- It's great you want to work on this. It's this particular patch that I have difficulty backing: it future proofs code that doesn't exist, for a feature that doesn't exist either, on account of an assumed need. No matter how I frame it it doesn't make any sense. No response needed - proceed as you wish. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5851] Ambiguous alias this accepted.
http://d.puremagic.com/issues/show_bug.cgi?id=5851 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|Other |All AssignedTo|nob...@puremagic.com|yebbl...@gmail.com OS/Version|Linux |All --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-01 20:35:31 EST --- https://github.com/D-Programming-Language/dmd/pull/676 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4041] Error with ref or auto ref return from opOpAssign
http://d.puremagic.com/issues/show_bug.cgi?id=4041 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Platform|x86 |All Version|2.041 |D2 Resolution||WORKSFORME OS/Version|Windows |All --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-01 21:10:52 EST --- I can't reproduce this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6504] Regression(2.041): str ~ [arr] allows string literal to be modified
http://d.puremagic.com/issues/show_bug.cgi?id=6504 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #3 from Don clugd...@yahoo.com.au 2012-02-01 02:21:04 PST --- (In reply to comment #2) I'm going to argue this is not a bug. While xxx is immutable, xxx~['c'] is mutable. Otherwise, it would be an error to use it to initialize x2. Hence, x2 can modify it. Since x2 is a reference to the initializer, not a copy of it, the initializer is modified. The spec says that string literals in the source code are immutable, not incidental string literals in the compiler that result from other operations. Reopened, because in every other respect, it behaves as an immutable string literal. On Linux, the test case causes a segfault -- it's an attempt to modify an read-only literal. On Windows, it's a secret global variable. You can even mark it as pure. I don't think we can afford to have something so simple causing undefined behaviour. Fixing this bug isn't a big deal, btw. Now that I've put an isCtfe flag in array literals, this case can go back to being an ArrayLiteral without hurting CTFE performance. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4149] refs displayed as pointers in gdb
http://d.puremagic.com/issues/show_bug.cgi?id=4149 --- Comment #14 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-02-01 02:22:04 PST --- (In reply to comment #13) It's unrelated to pull 526 which fixed #4180. I'm talking about the comment 2 by Brad: Depends on if gc implies c, c++, or 'as much as is supported in the built-in debug format without extension'. I'd argue for the last definition. Given that dwarf supports it without extension, I'd argue that it should use it. I'd argue that -g should be built-in + d extensions. Walter expressed he agree with this comment in comment 3. AFAIK this pull request works for -g instead of -gc, even when it uses standard DWARF features, which goes against that comment. In the bug 3389 that you just closed, Robert Clipsham makes what for me is a good point: -g not working is how it's meant to be, at least until gdb adds support for the D extensions to DWARF. I've hopefully fixed the remaining bugs with -gc (on linux at least). My solution to this would be to add in a -gd, and make -g an alias to -gc until better support for debug info is added to debuggers. This way users get working debug output with -g, and don't blame it on a buggy dmd :) At least this will be more familiar with people used to GCC command line arguments (which is probably 100% of the *nix world), where -g is the default for debug and you have, for example -ggdb for GDB extensions. AFAIK there is no clear direction about this. But maybe is a topic for another bug report, I think I'll reopen bug 3389 because the root issue in that bug is what's being discussed here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7416] 2.058 regression: fails to instantiate a constrained function template with a nested function
http://d.puremagic.com/issues/show_bug.cgi?id=7416 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7417] New: One-definition rule for version specification - allow version expressions
http://d.puremagic.com/issues/show_bug.cgi?id=7417
Summary: One-definition rule for version specification - allow
version expressions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2012-02-01 03:51:32 PST ---
This enhancement adds a new syntax for version specifications, which would
allow us to eliminate the bird's nest of version statements that occurs when
code has a complicated version dependency.
The new syntax makes version specifications look like boolean variable
declarations:
version identifier = expression;
It would become illegal to reference a version identifier which hasn't been
declared. The spec already says that version declarations may only occur at
module scope; this new form of version specification would additionally be
disallowed inside version blocks (this enforces the one-definition rule).
version identifier = extern;
means that the identifier is externally specified (either on the command line,
or as a compiler built-in).
version VersionIdentifier = VersionExpression;
extern version VersionIdentifier;
// means this version is set from command line, or is a compiler built-in
VersionExpression:
VersionExpression VersionExpression
VersionExpression || VersionExpression
!VersionExpression
( VersionExpression )
VersionIdentifier
true
false
extern
version(A)
{
version = AorNotB;
}
version(B)
{
}
else {
version = AorNotB;
}
becomes:
version AorNotB = A || !B;
Note that this is backwards-compatible, it doesn't collide with the existing
syntax. To get the full benefit from it, though, we would need to eventually
disallow existing version specifications from being inside version blocks.
version = XXX; outside of a version block would be the same as version XXX =
true; so most code would continue to work.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6681] bogus duplicate union initialization or overlapping initialization errors
http://d.puremagic.com/issues/show_bug.cgi?id=6681
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #2 from yebblies yebbl...@gmail.com 2012-02-01 22:58:33 EST ---
Ok, the first test case reduces to this:
struct V{
union {
double[2] cell;
double x;
}
static immutable V zero=V(0,1);
}
The problem being that the struct literal gets turned into:
this(a, b) { cell = 0; x = 1; }
ie. it passes the first argument to the first member, and the second argument
to the second.
This is sort of what I'd expect to happen, but the error message is completely
valid for what it's trying to do. If anyone has a better idea of how struct
literals should map to unions, please open another bug report about it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6681] struct constructor call is converted to struct literal that breaks union initialization
http://d.puremagic.com/issues/show_bug.cgi?id=6681
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Platform|Other |All
Summary|bogus duplicate union |struct constructor call is
|initialization or |converted to struct literal
|overlapping initialization |that breaks union
|errors |initialization
OS/Version|Mac OS X|All
--- Comment #3 from yebblies yebbl...@gmail.com 2012-02-01 23:10:11 EST ---
Got my test cases a little mixed up there, but it's still mostly valid.
All of the non-struct-literal struct construction seems to be converted into
struct literals. eg.
struct S
{
this(int a, int b) { this.a = b; this.b = a; }
union {
ulong g;
struct {int a, b; };
}
}
static immutable S s = S(0, 1);
Prints: (with a little extra debug output)
StructLiteralExp::semantic('S(0LU,1,0)')
S
Error: duplicate union initialization for a
Error: duplicate union initialization for b
As you can see, it make a struct literal with every field accounted for.
So this is a bug in the constfolding/ctfe code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 785] Make 'cent' and 'ucent' syntactically valid pending implementation
http://d.puremagic.com/issues/show_bug.cgi?id=785 --- Comment #23 from Stewart Gordon s...@iname.com 2012-02-01 04:21:17 PST --- (In reply to comment #20) 2. This let's add a filler doing nothing, discuss it ad nauseam, and consider implement later is an utter waste of time. If someone really wants they can implement it, don't add this useless filler for hypothetical future-proof libraries that don't exist. So you're waiting for somebody to write a library, built on my first point in comment 9, that doesn't compile because current DMD flags a syntax error? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3927] array.length++; is an error, but ++array.length compiles
http://d.puremagic.com/issues/show_bug.cgi?id=3927 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||diagnostic CC||clugd...@yahoo.com.au Summary|array.length++; is an error |array.length++; is an ||error, but ++array.length ||compiles --- Comment #1 from Don clugd...@yahoo.com.au 2012-02-01 04:27:31 PST --- ++array.length; compiles. The bizarre error is because of the lowering that the compiler uses internally. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2025] Inconsistent rules for instantiating templates with a tuple parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2025 --- Comment #7 from yebblies yebbl...@gmail.com 2012-02-01 23:32:47 EST --- (In reply to comment #6) What has a better match to do with anything? (int) matches the pattern (T) perfectly - no conversion, implicit or explicit. True, (T: int) is a more specialised match, inexact. more specialized == better match. That is how template type deduction works. but that doesn't magically render the match with (T) That's why I called it a hack. See issue 4953 for another case it causes problems. That's different - 5 is an int, so it doesn't exactly match the pattern (short x). I know it's different, I wrote the patch for it. The hack causes problems there too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 785] Make 'cent' and 'ucent' syntactically valid pending implementation
http://d.puremagic.com/issues/show_bug.cgi?id=785 --- Comment #24 from Stewart Gordon s...@iname.com 2012-02-01 04:36:09 PST --- Moreover, when we finally get the types, there will still be users on older compilers (DM or third-party, possibly commercial), even some on platforms for which an up-to-date compiler is not yet available, who can't compile other people's code because it uses syntax that is still illegal in the version they have. The sooner this issue is dealt with, the less risk of this happening. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 785] Make 'cent' and 'ucent' syntactically valid pending implementation
http://d.puremagic.com/issues/show_bug.cgi?id=785 --- Comment #25 from yebblies yebbl...@gmail.com 2012-02-01 23:44:50 EST --- (In reply to comment #24) Moreover, when we finally get the types, there will still be users on older compilers (DM or third-party, possibly commercial), even some on platforms for which an up-to-date compiler is not yet available, who can't compile other people's code because it uses syntax that is still illegal in the version they have. The sooner this issue is dealt with, the less risk of this happening. This is unlikely to ever be a problem. D2 compilers break enough code (wrong or not) between versions that using one a couple of releases old probably won't compile your code anyway. Of course, this will hopefully change in the future. The bigger issue that makes this less of a waste of time is that D compiler with different backends, or running on different backends, may choose not to implement cent/ucent, and if they do this in the parser then the code will be non-portable. The proposed patch is a much more correct solution to this problem. Regardless, there is a patch for this issue already out there which is waiting for review. I don't think discussing it further at this point will achieve anything. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2025] Inconsistent rules for instantiating templates with a tuple parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2025 --- Comment #9 from yebblies yebbl...@gmail.com 2012-02-01 23:55:06 EST --- (In reply to comment #8) (In reply to comment #7) more specialized == better match. That is how template type deduction works. But there's no (T : int) version of this template. It doesn't matter. The compiler does template argument deduction through a function called matchArg in template.c. It will generate one of the match levels (MATCHnomatch, MATCHconvert, MATCHconst, MATCHexact) based on what the template parameter, spectype, and argument are. matchArg does not know or care what the other overloads of the template are, or even what the other arguments are. For (T : int) to be preferred over (T), it must return a worse match level for the unspecialized parameter. Currently it will return MATCHconvert for these parameters, and return MATCHexact only when there is a (matching) spec type. Which leaves you with a non-exact match for (T) and (T...), even if it's the only overload. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6681] struct constructor call is converted to struct literal that breaks union initialization
http://d.puremagic.com/issues/show_bug.cgi?id=6681 --- Comment #5 from yebblies yebbl...@gmail.com 2012-02-02 00:02:06 EST --- (In reply to comment #4) Not exactly. It's a compiler structural problem: there's no way to specify a struct literal with missing fields. Struct static initializers can do it, but struct literals cannot. I think the solution is to merge struct literals with struct static initializers, as it says in a TODO in the code. One of the D1 cases seems to have the same problem with struct static initializers. Can't this be done by just nulling out the untouched fields in the Expressions array and ensuring at least one field gets initialized? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4241] duplicate union initialization error doesn't give a file location
http://d.puremagic.com/issues/show_bug.cgi?id=4241 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|Other |All Version|2.041 |D1 D2 OS/Version|Windows |All Severity|normal |critical --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 00:03:26 EST --- https://github.com/D-Programming-Language/dmd/pull/677 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4241] duplicate union initialization error doesn't give a file location
http://d.puremagic.com/issues/show_bug.cgi?id=4241 yebblies yebbl...@gmail.com changed: What|Removed |Added AssignedTo|nob...@puremagic.com|yebbl...@gmail.com --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-02 00:05:11 EST --- https://github.com/D-Programming-Language/dmd/pull/677 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2025] Inconsistent rules for instantiating templates with a tuple parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2025 --- Comment #10 from Stewart Gordon s...@iname.com 2012-02-01 05:27:34 PST --- (In reply to comment #9) For (T : int) to be preferred over (T), it must return a worse match level for the unspecialized parameter. Currently it will return MATCHconvert for these parameters, and return MATCHexact only when there is a (matching) spec type. So MATCHexact means the pattern can be matched only by this exact set of arguments, and MATCHconvert means this is one of various sets of arguments that can match this pattern. But then, surely, it would be rejecting the instantiation as ambiguous, not picking the (A...) overload. Really, it's a fundamental flaw in the compiler logic whereby it conflates two essentially orthogonal concepts: exactness and specialisation. A correct template instantiation algorithm would: - see which template patterns match the instantiation exactly - if none, see which template patterns match with implicit conversions - of all the matches, determine which is most specialised -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5684] Extremely show compile times with large tuples with -O -inline
http://d.puremagic.com/issues/show_bug.cgi?id=5684 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-02 01:26:32 EST --- *** This issue has been marked as a duplicate of issue 2396 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6643] Very slow compilation for large switch() using -O and -inline
http://d.puremagic.com/issues/show_bug.cgi?id=6643 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from yebblies yebbl...@gmail.com 2012-02-02 01:26:44 EST --- *** This issue has been marked as a duplicate of issue 2396 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2025] Inconsistent rules for instantiating templates with a tuple parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2025 --- Comment #12 from Stewart Gordon s...@iname.com 2012-02-01 06:39:13 PST --- (In reply to comment #11) No, MATCHconvert means 'match with implicit conversions'. These are the same match levels used for normal function argument matching. int is a type. T as a template parameter denotes exactly that - a type. So what implicit conversion is being performed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 783] Cannot use an array w/ const or variable index as new[] size argument.
http://d.puremagic.com/issues/show_bug.cgi?id=783 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Version|0.178 |D1 D2 AssignedTo|bugzi...@digitalmars.com|yebbl...@gmail.com --- Comment #4 from yebblies yebbl...@gmail.com 2012-02-02 01:44:15 EST --- https://github.com/D-Programming-Language/dmd/pull/679 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2025] Inconsistent rules for instantiating templates with a tuple parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2025 --- Comment #13 from yebblies yebbl...@gmail.com 2012-02-02 01:51:55 EST --- (In reply to comment #12) (In reply to comment #11) No, MATCHconvert means 'match with implicit conversions'. These are the same match levels used for normal function argument matching. int is a type. T as a template parameter denotes exactly that - a type. So what implicit conversion is being performed? None. That's why it's a hack to use it to represent deduced args with no spec type. That's why it causes problems... If you really want to understand how dmd does template deduction and overload matching have a poke around in template.c (deduceFunctionTemplateMatch and matchArgs) and mtype.c (callMatch). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6681] struct constructor call is converted to struct literal that breaks union initialization
http://d.puremagic.com/issues/show_bug.cgi?id=6681 --- Comment #6 from Don clugd...@yahoo.com.au 2012-02-01 07:13:36 PST --- (In reply to comment #5) (In reply to comment #4) Not exactly. It's a compiler structural problem: there's no way to specify a struct literal with missing fields. Struct static initializers can do it, but struct literals cannot. I think the solution is to merge struct literals with struct static initializers, as it says in a TODO in the code. One of the D1 cases seems to have the same problem with struct static initializers. Can't this be done by just nulling out the untouched fields in the Expressions array and ensuring at least one field gets initialized? Maybe. The order of fields in a struct is fixed, so in theory that ought to work. It's a while since I last looked at it, but I remember there were severe problems with anonymous unions nested inside anonymous unions. There's code elsewhere in the compiler which tries to identify fields based on their type + offset, but that cannot work. It appears to work at the moment, but only because it assumes when fields are initialized in order with no gaps. Still, I've fixed some of those compiler bugs recently, so maybe it's more possible now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1124] inconsistent: calls opCmp(typeof(this) o); but array.sort calls opCmp(Object o)
http://d.puremagic.com/issues/show_bug.cgi?id=1124 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||INVALID --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 02:14:51 EST --- As Stewart said, this is working as designed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1457] array extension member syntax confused with local member functions
http://d.puremagic.com/issues/show_bug.cgi?id=1457 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-02 02:18:48 EST --- *** This issue has been marked as a duplicate of issue 2344 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2344] Two wrong lookups for array functions
http://d.puremagic.com/issues/show_bug.cgi?id=2344 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||wbax...@gmail.com --- Comment #4 from yebblies yebbl...@gmail.com 2012-02-02 02:18:48 EST --- *** Issue 1457 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2307] (D1 only) Cannot use explicitly instantiated template function with array property syntax
http://d.puremagic.com/issues/show_bug.cgi?id=2307 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86 |All Version|2.018 |D1 Summary|Cannot use explicitly |(D1 only) Cannot use |instantiated template |explicitly instantiated |function with array |template function with |property syntax |array property syntax OS/Version|Windows |All --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 02:24:23 EST --- Works in D2 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2712] error with passing an array slot as another array length to new
http://d.puremagic.com/issues/show_bug.cgi?id=2712 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-02 02:28:52 EST --- *** This issue has been marked as a duplicate of issue 783 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 783] Cannot use an array w/ const or variable index as new[] size argument.
http://d.puremagic.com/issues/show_bug.cgi?id=783 --- Comment #5 from yebblies yebbl...@gmail.com 2012-02-02 02:28:52 EST --- *** Issue 2712 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3221] (D1 only) Can't use property syntax with ufcs
http://d.puremagic.com/issues/show_bug.cgi?id=3221 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||rejects-valid CC||yebbl...@gmail.com Version|2.032 |D1 Summary|Array extension methods |(D1 only) Can't use |require parentheses |property syntax with ufcs --- Comment #4 from yebblies yebbl...@gmail.com 2012-02-02 02:33:23 EST --- Works in D2 (2.058) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3626] alias this prevents appending to array
http://d.puremagic.com/issues/show_bug.cgi?id=3626 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Platform|Other |All Version|2.036 |D2 Resolution||FIXED OS/Version|Mac OS X|All --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 02:36:16 EST --- This works with the current compiler (2.058) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3501] (D1 only) is null comparison should be disallowed for fixed-size arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3501 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||accepts-invalid CC||yebbl...@gmail.com Platform|Other |All Version|2.036 |D1 Summary|is null comparison should |(D1 only) is null |be disallowed for |comparison should be |fixed-size arrays |disallowed for fixed-size ||arrays OS/Version|Windows |All --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 02:35:12 EST --- Fixed in D2 (2.058) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5718] Can't demangle symbol defined inside unittest block
http://d.puremagic.com/issues/show_bug.cgi?id=5718 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #5 from Kenji Hara k.hara...@gmail.com 2012-02-01 07:44:09 PST --- (In reply to comment #4) Ok, can you do a pull request for deprecating it, and then we can close this? Sorry, I had mistaken. std.traits.mangledName has an extra feature against the built-in mangleof property. It returns a pseudo mangled name from given template symbol. // from unittest assert(mangledName!mangledName == 3std6traits11mangledName); It is useful for getting unique string from template symbol, even if std.demangle.demangle() cannot demangle it. Therefore, now I cannot recommend to deprecate it. But we can fix the original issue. Please merge following pull: https://github.com/D-Programming-Language/phobos/pull/414 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3683] Linker error on certain array expressions when using -release and -inline
http://d.puremagic.com/issues/show_bug.cgi?id=3683 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 02:41:15 EST --- *** This issue has been marked as a duplicate of issue 5592 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5592] Previous definition different: __arrayExpSliceMulSliceAddass_d
http://d.puremagic.com/issues/show_bug.cgi?id=5592 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||eriatark...@gmail.com --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-02 02:41:15 EST --- *** Issue 3683 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=5570 Trass3r mrmoc...@gmx.de changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #5 from Trass3r mrmoc...@gmx.de 2012-02-01 17:08:14 CET --- So should we raise this to 'blocker'? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3812] Missing line number for implicit cast of variadic function to array
http://d.puremagic.com/issues/show_bug.cgi?id=3812 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||patch CC||yebbl...@gmail.com Platform|Other |All Version|2.038 |D1 D2 AssignedTo|nob...@puremagic.com|yebbl...@gmail.com OS/Version|Windows |All Severity|normal |critical --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 03:06:51 EST --- https://github.com/D-Programming-Language/dmd/pull/680 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3826] init of fixed sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3826 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Platform|x86 |All Version|2.040 |D1 D2 Resolution||FIXED OS/Version|Windows |All --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-02 03:11:46 EST --- This works as expected with the current compiler (2.058 1.072) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3927] array.length++; is an error, but ++array.length compiles
http://d.puremagic.com/issues/show_bug.cgi?id=3927 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86 |All Version|2.041 |D1 D2 AssignedTo|nob...@puremagic.com|yebbl...@gmail.com OS/Version|Windows |All --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 03:32:09 EST --- https://github.com/D-Programming-Language/dmd/pull/681 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6681] struct constructor call is converted to struct literal that breaks union initialization
http://d.puremagic.com/issues/show_bug.cgi?id=6681 --- Comment #7 from yebblies yebbl...@gmail.com 2012-02-02 03:38:36 EST --- Ok, I'll take a look at it tomorrow unless you want it. I know there are at least two places it checks for overlapping union initialization, one in expression.c and one somewhere in the glue, maybe e2ir? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3389] gdb: using -gc is mandatory but not well documented
http://d.puremagic.com/issues/show_bug.cgi?id=3389 --- Comment #4 from d...@dawgfoto.de 2012-02-01 11:27:20 PST --- Thats a wrong comparision because neither -g not -ggdb make the compiler fake C++ debug information as C. The -gc flag is a hack to masquerade as C which should not be the default if -g works for most platforms. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7418] New: Overloading doesn't work with aliases declared inside templates
http://d.puremagic.com/issues/show_bug.cgi?id=7418
Summary: Overloading doesn't work with aliases declared inside
templates
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: siegelords_ab...@yahoo.com
--- Comment #0 from siegelords_ab...@yahoo.com 2012-02-01 11:34:05 PST ---
void test(uint a)
{
}
void test(char[] a)
{
}
template _test1(T = void)
{
alias test _test1;
}
alias test _test2;
void main()
{
_test2(a.dup);
_test2(1U);
_test1!()(a.dup); // Error: cannot implicitly convert expression
(_adDupT(_D12TypeInfo_Aya6__initZ,cast(string)a)) of type char[] to uint
_test1!()(1U);
}
Note how the alias outside the template works fine, but the one inside the
alias only picks up the lexically first match. Note that this works fine in D1.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3389] gdb: using -gc is mandatory but not well documented
http://d.puremagic.com/issues/show_bug.cgi?id=3389 --- Comment #5 from d...@dawgfoto.de 2012-02-01 11:34:57 PST --- GDB already has D specific extensions (demangling and arrays). Using -g makes use of them, -gc does not. There won't be D specific DWARF extensions any time soon. What we wanted to add can be modeled by newer DWARF versions but adapting them would break older debuggers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7396] Indicate default alignment with 0.
http://d.puremagic.com/issues/show_bug.cgi?id=7396 --- Comment #21 from d...@dawgfoto.de 2012-02-01 11:42:18 PST --- I think it would also make sense to disallow any align(n) value greater than align(16) for 32bit, and possibly align(32) for 64bit platforms. Don't do that. GCC can provide arbitrary alignment even for stack values. Also your number is already too low, xsave needs 64-byte alignment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7419] New: [2.058/CTFE] Constructor of struct is overwritten inside a unittest with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7419
Summary: [2.058/CTFE] Constructor of struct is overwritten
inside a unittest with -inline
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: CTFE
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2012-02-01 11:48:03 PST ---
Test case:
-
struct X7419 {
double x;
this(double x) {
this.x = x;
}
}
unittest {
enum x = {
auto p = X7419(3);
return p.x;
}();
static assert(x == 3);
}
-
Compile with:
dmd -unittest -inline -c test7419.d
Gives the unexpected error:
test7419.d(12): Error: static assert (nan == 3) is false
The bug was introduced in commit 40160a53a0c72bfbad2e0ad36ec8f1ccbb76ce8d.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7420] New: Duplicate cannot be read at compile time error messages
http://d.puremagic.com/issues/show_bug.cgi?id=7420 Summary: Duplicate cannot be read at compile time error messages Product: D Version: D1 D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don clugd...@yahoo.com.au 2012-02-01 11:50:11 PST --- int x = 2; char[] y = abc.dup; static assert(x 4); static assert(y == abc); static assert(cast(ubyte[])y != null); static assert(y[0] == 1); static assert(y[0..1].length == 1); - BEFORE PATCH --- crash.d(405): Error: variable x cannot be read at compile time crash.d(405): Error: variable x cannot be read at compile time crash.d(405):while evaluating: static assert(x 4) crash.d(406): Error: variable y cannot be read at compile time crash.d(406): Error: variable y cannot be read at compile time crash.d(406):while evaluating: static assert(y == abc) crash.d(407): Error: variable y cannot be read at compile time crash.d(407): Error: variable y cannot be read at compile time crash.d(407):while evaluating: static assert(cast(ubyte[])y != null) crash.d(408): Error: variable y cannot be read at compile time crash.d(408): Error: variable y cannot be read at compile time crash.d(408):while evaluating: static assert(cast(int)y[0u] == 1) crash.d(409): Error: variable y cannot be read at compile time crash.d(409): Error: variable y cannot be read at compile time crash.d(409):while evaluating: static assert(y[0u..1u].length == 1u) AFTER PATCH --- crash.d(405): Error: variable x cannot be read at compile time crash.d(405):while evaluating: static assert(x 4) crash.d(406): Error: variable y cannot be read at compile time crash.d(406):while evaluating: static assert(y == abc) crash.d(407): Error: variable y cannot be read at compile time crash.d(407):while evaluating: static assert(cast(ubyte[])y != null) crash.d(408): Error: variable y cannot be read at compile time crash.d(408):while evaluating: static assert(cast(int)y[0u] == 1) crash.d(409): Error: variable y cannot be read at compile time crash.d(409):while evaluating: static assert(y[0u..1u].length == 1u) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7421] New: std.getopt does not work with shared strings
http://d.puremagic.com/issues/show_bug.cgi?id=7421
Summary: std.getopt does not work with shared strings
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: rob...@octarineparrot.com
--- Comment #0 from Robert Clipsham rob...@octarineparrot.com 2012-02-01
20:55:01 GMT ---
When using the following:
import std.getopt;
shared string foo;
void main(string[] args)
{
getopt(args, foo, foo);
}
Then using:
$ dmd test.d
$ ./test --foo=bar
std.conv.ConvException@/home/robert/.dvm/compilers/dmd-2.056/bin/../src/phobos/std/conv.d(1749):
Can't convert value `oo' of type string to type immutable(char)
./test(immutable(char) std.conv.toImpl!(immutable(char),
immutable(char)[]).toImpl(immutable(char)[])+0x43) [0x80671c3]
./test(immutable(char)
std.conv.to!(immutable(char)).to!(immutable(char)[]).to(immutable(char)[])+0xe)
[0x80670a2]
./test(void
std.getopt.handleOption!(shared(immutable(char)[])*).handleOption(immutable(char)[],
shared(immutable(char)[])*, ref immutable(char)[][], ref
std.getopt.configuration, bool)+0x393) [0x8066f13]
./test(void std.getopt.getoptImpl!(immutable(char)[],
shared(immutable(char)[])*).getoptImpl(ref immutable(char)[][], ref
std.getopt.configuration, immutable(char)[], shared(immutable(char)[])*)+0x90)
[0x8066b00]
./test(void std.getopt.getopt!(immutable(char)[],
shared(immutable(char)[])*).getopt(ref immutable(char)[][], immutable(char)[],
shared(immutable(char)[])*)+0x35) [0x8066a1d]
./test(_Dmain+0x1d) [0x80669e1]
./test(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x14)
[0x8069a90]
./test(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x1d) [0x8069735]
./test(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x37)
[0x8069ad7]
./test(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope void
delegate())+0x1d) [0x8069735]
./test(main+0x94) [0x80696e4]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x60c113]
Removing the shared qualifier removes the issue. Tested with dmd 2.056 and
dmd-master on Linux x86-32.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4729] std.algorithm: strange iota behaviour
http://d.puremagic.com/issues/show_bug.cgi?id=4729 Brad Anderson e...@gnuk.net changed: What|Removed |Added CC||e...@gnuk.net --- Comment #3 from Brad Anderson e...@gnuk.net 2012-02-01 13:21:38 PST --- 2.057 seems to handle this situation (trying to reduce an empty range but not offering a seed) by throwing an appropriate exception: object.Exception@C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(662): Cannot reduce an empty range w/o an explicit seed value. I believe this should be closed. Also, not sure why this is set as an optlink issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7419] [2.058/CTFE] Constructor of struct is overwritten inside a unittest with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7419
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
AssignedTo|nob...@puremagic.com|clugd...@yahoo.com.au
--- Comment #1 from Don clugd...@yahoo.com.au 2012-02-01 13:29:03 PST ---
It doesn't need unittest. The -inline seems to be necessary, I presume it's
creating a ref variable.
struct X7419 {
double x;
this(double x) {
this.x = x;
}
}
void bug7419() {
enum x = {
auto p = X7419(3);
return p.x;
}();
static assert(x == 3);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6504] Regression(2.041): str ~ [arr] allows string literal to be modified
http://d.puremagic.com/issues/show_bug.cgi?id=6504 --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-02-01 14:05:45 PST --- I found out it causes the seg fault after posting last night. I don't quite understand your suggestion. Do you have a fix that can be pulled? I did try just not constant folding string~['c'] and letting that be done at runtime, but that caused interpret3.d to fail, as it relies on the constant folder to do that. So I think that can work if you enhance CTFE to handle the string~['c'] case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 783] Cannot use an array w/ const or variable index as new[] size argument.
http://d.puremagic.com/issues/show_bug.cgi?id=783 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Keywords|patch |pull CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-02-01 14:13:40 PST --- Please use 'pull' keyword for ones with a pull request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5718] Can't demangle symbol defined inside unittest block
http://d.puremagic.com/issues/show_bug.cgi?id=5718 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-02-01 14:26:53 PST --- That pull fixes it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7002] std.path needs a isValidFilePath function
http://d.puremagic.com/issues/show_bug.cgi?id=7002
Lars T. Kyllingstad bugzi...@kyllingen.net changed:
What|Removed |Added
CC||bugzi...@kyllingen.net
--- Comment #10 from Lars T. Kyllingstad bugzi...@kyllingen.net 2012-02-01
14:27:36 PST ---
Sorry for coming late to the party, but I totally agree with Jonathan on this.
Such a function does not seem generic enough to warrant inclusion in the
standard library, and std.path already provides the building blocks making it a
one-liner:
bool isDefinitelyADir(string path)
{
return isValidPath(path) isDirSeparator(path[$-1]);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5718] Can't demangle symbol defined inside unittest block
http://d.puremagic.com/issues/show_bug.cgi?id=5718 --- Comment #7 from github-bugzi...@puremagic.com 2012-02-01 14:32:50 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/686f53f6d2d373ad13ea854b52e924fd7030422f Issue 5718 - Can't demangle symbol defined inside unittest block std.traits.mangledName should return valid mangled name against symbols in function. https://github.com/D-Programming-Language/phobos/commit/ac88792ea1a15a4815679359b69e731868db4391 Merge pull request #414 from 9rnsr/fix5718 Issue 5718 - Can't demangle symbol defined inside unittest block -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7001] std.path.baseName and isValidFilename wrong documentation
http://d.puremagic.com/issues/show_bug.cgi?id=7001 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Lars T. Kyllingstad bugzi...@kyllingen.net 2012-02-01 14:33:48 PST --- It seems the confusion has been cleared up, so I'm closing this. If anyone still disagrees, please reopen. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6068] std.path has some issues for Windows user
http://d.puremagic.com/issues/show_bug.cgi?id=6068 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@kyllingen.net Resolution||WONTFIX --- Comment #2 from Lars T. Kyllingstad bugzi...@kyllingen.net 2012-02-01 14:31:36 PST --- Marking this as won't fix, since the functions in question will soon be removed from Phobos. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6790] buildPath using std.path.curdir segfaults
http://d.puremagic.com/issues/show_bug.cgi?id=6790 --- Comment #6 from Lars T. Kyllingstad bugzi...@kyllingen.net 2012-02-01 14:41:35 PST --- Have you tried this with DMD 2.057, and if so, are you still experiencing the same problem? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7422] New: Regression(master): ICE with template function and if statement
http://d.puremagic.com/issues/show_bug.cgi?id=7422
Summary: Regression(master): ICE with template function and if
statement
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rob...@octarineparrot.com
--- Comment #0 from Robert Clipsham rob...@octarineparrot.com 2012-02-01
22:55:31 GMT ---
The following:
struct Logger {
static void info()() {
}
}
void view() {
if (Logger.info) {
}
}
ICEs with git master @ dc7916071b60739dcc8c09e43ff3da5218b42ff2, giving the
following error:
dmd: statement.c:2520: virtual Statement* IfStatement::semantic(Scope*):
Assertion `condition-type' failed.
Aborted
On linux x86_32. Note this still occurs if you make this into a valid test case
by overloading the info() method with one that returns bool.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7294] [Regression] No warning when escaping local reference type variables
http://d.puremagic.com/issues/show_bug.cgi?id=7294 --- Comment #1 from github-bugzi...@puremagic.com 2012-02-01 17:23:12 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/28324c5c1226571f2ee96eebee5fd3ad09ebe031 fix Issue 7294 - [Regression] No warning when escaping local reference type variables -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7294] [Regression] No warning when escaping local reference type variables
http://d.puremagic.com/issues/show_bug.cgi?id=7294 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 3686] common type of imaginary and non-imaginary should be complex
http://d.puremagic.com/issues/show_bug.cgi?id=3686 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords|patch | Version|2.038 |D2 --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 12:51:32 EST --- Imaginary and complex numbers are going away. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4031] Should be able to access const value-type globals from pure functions
http://d.puremagic.com/issues/show_bug.cgi?id=4031 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords|patch |pull Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from yebblies yebbl...@gmail.com 2012-02-02 12:54:48 EST --- This was fixed a while ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5481] Support deprecated(message)
http://d.puremagic.com/issues/show_bug.cgi?id=5481 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords|patch |pull --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-02 13:00:47 EST --- https://github.com/D-Programming-Language/dmd/pull/463 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3994] Wrong line numbers inside AA/Array initializers
http://d.puremagic.com/issues/show_bug.cgi?id=3994 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 13:58:42 EST --- Same issue - array initializers get the wrong locations assigned. *** This issue has been marked as a duplicate of issue 977 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 977] Wrong line number reported for a missing comma in an array initializer within a struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=977 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||cbkbbej...@mailinator.com Bug 977 depends on bug 3994, which changed state. Bug 3994 Summary: Wrong line numbers inside AA/Array initializers http://d.puremagic.com/issues/show_bug.cgi?id=3994 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 13:58:42 EST --- *** Issue 3994 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 977] Expressions inside a struct or array initializer get wrong line number
http://d.puremagic.com/issues/show_bug.cgi?id=977 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86 |All Version|1.006 |D1 D2 Summary|Wrong line number reported |Expressions inside a struct |for a missing comma in an |or array initializer get |array initializer within a |wrong line number |struct initializer | OS/Version|Windows |All Severity|minor |major --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 14:02:38 EST --- This happens because the parser scans across the whole initializer to determine if it's an expression or an initializer. Because it's already lexed the whole initializer, the lexer's loc points to the end, and this is what is assigned to each expression. Not sure how to solve this without re-lexing the initializer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3995] Can't access array/AA from function literal defined inside the array/AA's initializer
http://d.puremagic.com/issues/show_bug.cgi?id=3995 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|Other |All Version|1.050 |D1 D2 Blocks|340 | OS/Version|Windows |All Severity|normal |enhancement --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 14:07:15 EST --- This is working as intended. Variables are not added to the scope until after their initializers are processed, preventing garbage like this: int x = x; And other cases where this would make it possible to refer to uninitialized variables that, even when they have an initializer. A trivial workaround is the following: int delegate(int)[string] dgMap; auto tmp = [ ... delegate definitions referring to dgMap ... ]; dgMap = tmp; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||rsi...@gmail.com --- Comment #7 from yebblies yebbl...@gmail.com 2012-02-02 14:27:49 EST --- *** Issue 4298 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4426] assert(condition, string) fails in std.array.back
http://d.puremagic.com/issues/show_bug.cgi?id=4426 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||WORKSFORME --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 14:35:08 EST --- The workaround is gone from std.array.back. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
opDispatch returning this not working in a hierarchy
Hi,
I don't know if this is really a bug or some gotcha of the language that I
don't get. I'm sorry if it happens to be the later.
When I run this simple program
class DispatchBase
{
auto opDispatch( string m, Args... )( Args args )
{
writefln( Tried to call %s, m );
return this;
}
}
class DispatchDerived : DispatchBase
{
void printValue( T )( T value )
{
writefln( Value is %s, value );
}
}
void main()
{
DispatchBase base = new DispatchDerived();
base.items.printValue( true );
}
I receive this output
Tried to call items
Tried to call printValue
But what I was expecting is
Tried to call items
Value is true
After all, opDispatch returns 'this'. The interesting thing is that when I
move opDispatch up to DispatchDerived, everything works fine. It's like 'this'
inside opDispatch didn't recognize its real type when in a base class.
Hope you can help me.
Daniel
Re: opDispatch returning this not working in a hierarchy
On 2/1/2012 8:00 PM, Daniel L. Alves wrote: I don't know if this is really a bug or some gotcha of the language that I don't get. I'm sorry if it happens to be the later. This n.g. is mainly for bugzilla notifications. Questions like this should go into the digitalmars.D.learn n.g. But to answer your question, printValue is a template, and templates are not virtual. Also, DispatchBase.opDispatch knows nothing about DispatchDerived.
Re: opDispatch returning this not working in a hierarchy
There are some issues with mixing opDispatch and property syntax. Try:
base.items().printValue( true );
This list is not for posting bug reports, it's just for bugzilla issues.
Please post this kind of thing to d.learn or open a bug report at
http://d.puremagic.com/issues/
Daniel L. Alves daniel_lopes_al...@hotmail.com wrote in message
news:jgd1oj$2r04$1...@digitalmars.com...
Hi,
I don't know if this is really a bug or some gotcha of the language that I
don't get. I'm sorry if it happens to be the later.
When I run this simple program
class DispatchBase
{
auto opDispatch( string m, Args... )( Args args )
{
writefln( Tried to call %s, m );
return this;
}
}
class DispatchDerived : DispatchBase
{
void printValue( T )( T value )
{
writefln( Value is %s, value );
}
}
void main()
{
DispatchBase base = new DispatchDerived();
base.items.printValue( true );
}
I receive this output
Tried to call items
Tried to call printValue
But what I was expecting is
Tried to call items
Value is true
After all, opDispatch returns 'this'. The interesting thing is that when I
move opDispatch up to DispatchDerived, everything works fine. It's like
'this'
inside opDispatch didn't recognize its real type when in a base class.
Hope you can help me.
Daniel
[Issue 4397] const/CTFE does not work
http://d.puremagic.com/issues/show_bug.cgi?id=4397 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #13 from yebblies yebbl...@gmail.com 2012-02-02 15:32:18 EST --- *** This issue has been marked as a duplicate of issue 2526 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||s...@invisibleduck.org --- Comment #8 from yebblies yebbl...@gmail.com 2012-02-02 15:34:11 EST --- *** Issue 4881 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5367] Array of closures assign problem
http://d.puremagic.com/issues/show_bug.cgi?id=5367 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||WORKSFORME --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 15:37:29 EST --- Probably fixed with the other delegate conversion bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3389] gdb: using -gc is mandatory but not well documented
http://d.puremagic.com/issues/show_bug.cgi?id=3389 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||bra...@puremagic.com Resolution||WONTFIX --- Comment #6 from Brad Roberts bra...@puremagic.com 2012-02-01 20:54:51 PST --- The bottom line is that -g needs to 'just work' with the standard debuggers on the supported platforms. Assuming that -g works, -gc is a left over appendage. A whole lot of progress has been made in a number of commits over the last year. Some quick testing on linux shows that it works quite well with just -g now. With that in mind, I'm resolving this bug report as wontfix since -gc isn't mandatory any more. Chances are that there's more bugs left, so please feel encouraged to distill repro cases where -g doesn't just work, file them, and we'll work on them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4932] Add opUnary() address-of support
http://d.puremagic.com/issues/show_bug.cgi?id=4932 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com 2012-02-01 20:57:20 PST --- TDPL explicitly lists as an operator which cannot be overloaded. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4149] refs displayed as pointers in gdb
http://d.puremagic.com/issues/show_bug.cgi?id=4149 --- Comment #15 from Brad Roberts bra...@puremagic.com 2012-02-01 21:03:43 PST --- Please stop cluttering this bug report with discussion about the meaning of -g, that's a solved problem. This report is about preserving 'ref'ness through the backend and dwarf debug data. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4044] [Tracker] Bad debug information and DWARF errors
http://d.puremagic.com/issues/show_bug.cgi?id=4044 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bra...@puremagic.com Resolution||INVALID --- Comment #1 from Brad Roberts bra...@puremagic.com 2012-02-01 21:10:39 PST --- closing, we don't need a tracker to track other bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4044] [Tracker] Bad debug information and DWARF errors
http://d.puremagic.com/issues/show_bug.cgi?id=4044 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-02-01 21:19:37 PST --- (In reply to comment #1) closing, we don't need a tracker to track other bugs. I agree, that's what keywords are for. In this case, symdeb. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7416] 2.058 regression: fails to instantiate a constrained function template with a nested function
http://d.puremagic.com/issues/show_bug.cgi?id=7416 --- Comment #1 from github-bugzi...@puremagic.com 2012-02-01 21:20:39 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/960f6fd4404750ab2d637f66d63ff70c98f5b73c fix Issue 7416 - 2.058 regression: fails to instantiate a constrained function template with a nested function -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7416] 2.058 regression: fails to instantiate a constrained function template with a nested function
http://d.puremagic.com/issues/show_bug.cgi?id=7416 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 5448] Array of AAs literal doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=5448 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||pull CC||yebbl...@gmail.com Platform|x86 |All AssignedTo|nob...@puremagic.com|yebbl...@gmail.com OS/Version|Windows |All --- Comment #2 from yebblies yebbl...@gmail.com 2012-02-02 16:24:13 EST --- https://github.com/D-Programming-Language/dmd/pull/683 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7419] [2.058/CTFE] Constructor of struct is overwritten inside a unittest with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7419 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-02-01 21:24:53 PST --- Linky: https://github.com/D-Programming-Language/dmd/commit/40160a53a0c72bfbad2e0ad36ec8f1ccbb76ce8d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5498] wrong common type deduction for array of classes
http://d.puremagic.com/issues/show_bug.cgi?id=5498 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid CC||yebbl...@gmail.com Version|D2 |D1 D2 AssignedTo|nob...@puremagic.com|yebbl...@gmail.com Summary|array of elements of|wrong common type deduction |subtypes of a common|for array of classes |supertype | --- Comment #3 from yebblies yebbl...@gmail.com 2012-02-02 16:47:47 EST --- https://github.com/D-Programming-Language/dmd/pull/684 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7419] [2.058/CTFE] Constructor of struct is overwritten inside a unittest with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=7419 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-02-01 22:00:23 PST --- Looking at that git commit, if I add back in the following code that was elided: 3450a3451,3459 #if 1 if (op==TOKconstruct this-e1-op==TOKvar this-e2-op != TOKthis this-e2-op != TOKcomma ((VarExp*)this-e1)-var-storage_class STCref) wantRef = true; #endif then it works. Note that when -inline is used, the only function that gets inlined is the constructor call. Note the comment for the elision, saying it is to fix something with foreach, yet foreach is not in this example, I think the problem is in CTFE. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5567] arrays can't call aliased functions as member functions
http://d.puremagic.com/issues/show_bug.cgi?id=5567 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com 2012-02-02 17:23:39 EST --- The problem is not the alias, but the fact the alias is not at global scope. *** This issue has been marked as a duplicate of issue 4525 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4525] Regression(2.020) Array member call syntax can't find matches in current class
http://d.puremagic.com/issues/show_bug.cgi?id=4525 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #8 from yebblies yebbl...@gmail.com 2012-02-02 17:23:40 EST --- *** Issue 5567 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3742] Please add support for 'Lightweight Profiling' which adds a set of user-controlled counters to the AMD64 architecture
http://d.puremagic.com/issues/show_bug.cgi?id=3742 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Don clugd...@yahoo.com.au 2012-02-01 22:30:23 PST --- Invalid - processor specific, belongs in a library, too vague to be actionable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 660] Incorrect protection error message
http://d.puremagic.com/issues/show_bug.cgi?id=660
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #2 from Don clugd...@yahoo.com.au 2012-02-01 22:32:25 PST ---
This is actually a bit worse. If you swap the order of the private static
and public virtual foo, it compiles!
class A
{
private static void foo(int i) {}
public void foo() {}
}
class B
{
void bar(int x)
{
A.foo (x);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7423] New: Regression (2.057): Hex Literals are no longer treated as unsigned.
http://d.puremagic.com/issues/show_bug.cgi?id=7423
Summary: Regression (2.057): Hex Literals are no longer treated
as unsigned.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: flybo...@gmail.com
--- Comment #0 from Adam Wilson flybo...@gmail.com 2012-02-01 22:43:21 PST ---
I have taken this example code from druntime as that is what I was compiling
for testing the new DI generation code. The only way to get bitop.d to compile
using the GIT latest DMD was to add cast(uint) in front of every hex literal in
the popcnt() function.
//BROKEN popcnt function
int popcnt( uint x )
{
x = x - ((x1) 0x_);
x = ((x0x_)2) + (x0x_);
x += (x4);
x = 0x0F0F_0F0F;
x += (x8);
x = 0x00FF_00FF;
x += (x16);
x = 0x;
return x;
}
//FIXED popcnt function
int popcnt( uint x )
{
x = x - ((x1) cast(uint)0x_);
x = ((xcast(uint)0x_)2) + (xcast(uint)0x_);
x += (x4);
x = cast(uint)0x0F0F_0F0F;
x += (x8);
x = cast(uint)0x00FF_00FF;
x += (x16);
x = cast(uint)0x;
return x;
}
Here is the full error dump from DMD:
typeMerge() x 1 op 1431655765
001E1E04 type=null e1=001E1DBC e2=001E1DE0
001E1DBC type=uint e1=023E3244 e2=001E1D98
023E3244 var var=x type=uint
001E1D98 1 type=int
001E1DE0 1431655765 type=int
t1 = uint
t2 = int
assert cast.c(2082) t1-ty == t2-ty
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7423] Regression (2.057): Hex Literals are no longer treated as unsigned.
http://d.puremagic.com/issues/show_bug.cgi?id=7423 Adam Wilson flybo...@gmail.com changed: What|Removed |Added Priority|P2 |P1 CC||flybo...@gmail.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7423] Regression (2.057): Hex Literals are no longer treated as unsigned.
http://d.puremagic.com/issues/show_bug.cgi?id=7423 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|regression |normal --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-02-01 23:13:46 PST --- I don't think this was a regression. Recategorized. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
