[Issue 17138] Warn about superfluous "with" statements

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17138

--- Comment #5 from Eyal  ---
Another case that is beneficial and should not be an error:

If the expression results in an object that scopes over the block and has a
destructor. 

Example:

with(someMutex.acquired) {

  // No use of any fields from the MutexAcquired object

} // dtor of MutexAcquired called here, releasing the mutex

So here you'd want no error either.

--

[Issue 17138] Warn about superfluous "with" statements

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17138

--- Comment #4 from Eyal  ---
Yes, that would be great.

--

[Issue 13186] core/sys/posix/sys/uio.d is not linked into the standard lib

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13186

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 13186] core/sys/posix/sys/uio.d is not linked into the standard lib

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13186

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/11ac522f4386fb02dbf0d601a1b36e3180c826bb
fix Issue 13186 - core/sys/posix/sys/uio.d is not linked into the standard lib

https://github.com/dlang/druntime/commit/2144f2f721bf3248350771e0ac89ee97ccc3ff63
Merge pull request #1827 from WalterBright/fix13186

fix Issue 13186 - core/sys/posix/sys/uio.d is not linked into the sta…

--

[Issue 17396] Add colorized syntax highlighting to error messages emitted by dmd

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17396

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6777

--

[Issue 13331] naked asm functions are broken when compiling with -profile

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13331

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/c6db9b7d55ea9b533d584cd1da7d4fdb873fccd8
fix Issue 13331 - naked asm functions are broken when compiling with -profile

https://github.com/dlang/dmd/commit/7162f2bc2e067894874e632cb51ead4900c70694
Merge pull request #6770 from WalterBright/fix13331

fix Issue 13331 - naked asm functions are broken when compiling with …
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 17289] With Xcode 8.3 linker, warnings of "pointer not aligned"

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17289

Zach the Mystic  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
   Severity|critical|regression

--- Comment #10 from Zach the Mystic  ---
I guess I'll reopen this issue to make the point, now that I have an ally.
Again, I believe this is in effect a horrible regression, and the fix should be
patched to the main website ASAP.

--

[Issue 16657] alias this interacts with generated opCmp and opEquals

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16657

--- Comment #3 from Andrei Alexandrescu  ---
It seems a case can be made for either behavior. 

* The "alias this" feature emulates subtyping of the kind typically achieved by
class inheritance. If that is the default behavior to emulate, the current
behavior is up to the task. Consider a moral equivalent:

class A {
int x;
this(int x) { this.x = x; }
override bool opEquals(Object rhs) { return x == (cast(A) rhs).x; }
}

class B : A {
this(int x, int y) { super(x); this.y = y; }
int y;
}

void main() {
assert(new A(1) == new B(1, 2)); // pass
}

This "slices" B for the purpose of comparison.

* Yes, "alias this" does emulate subtyping, but we have an autogenerated
opEquals for every struct. Why should there be the case that such generation
automatically disappears in the case "alias this" is used?

* Another argument for changing behaviors has to do with practicality. Even
though a subtyping-based argument can be created in favor of preserving
existing compatibility, a better argument is that in fact the _current_ OOP
behavior (illustrated by the example with classes above) is incorrect and
error-prone. There's good evidence for that (e.g.
http://stackoverflow.com/questions/12239344/why-should-i-not-use-equals-with-inheritance
of many examples). The theoretical underpinnings for correctly defining
comparison in conjunction with subtyping is bounded quantification
(https://en.wikipedia.org/wiki/Bounded_quantification).

The short of it all is the current behavior can and should be improved.
Changing behavior silently is not a good choice, so we should probably issue a
warning when the situation occurs. The warning can be extinguished by defining
opEquals explicitly. With time the warning becomes an error following a
schedule similar to deprecation.

--

[Issue 17289] With Xcode 8.3 linker, warnings of "pointer not aligned"

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17289

--- Comment #9 from Jon Degenhardt  ---
(In reply to Zach the Mystic from comment #8)
> I believe this counts as a regression and should be patched to the main
> website ASAP. It's fixed on master. But I believe anyone trying D on OSX for
> the first time from the website will have 1000 screens of linker errors when
> they try to compile anything. Horrible user experience.

I agree, the warnings are both alarming and a real nuisance. It would be worth
including this in a 2.074.1 patch release.

--

[Issue 17396] Add colorized syntax highlighting to error messages emitted by dmd

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17396

Walter Bright  changed:

   What|Removed |Added

Summary|Colorize error messages |Add colorized syntax
   |emitted by dmd  |highlighting to error
   ||messages emitted by dmd

--

[Issue 12273] 'dmd -color' flag to colorize error/warning messages

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12273

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17396

--

[Issue 17396] Colorize error messages emitted by dmd

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17396

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12273

--

[Issue 17396] New: Colorize error messages emitted by dmd

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17396

  Issue ID: 17396
   Summary: Colorize error messages emitted by dmd
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Some basic colorization has already been implemented as the solution to
https://issues.dlang.org/show_bug.cgi?id=12273

But we can go further with that by taking inspiration from Ddoc. In
verrorPrint(), the message string can be scanned for text enclosed by `...`.
This text can then be syntax color highlighted analogously to the way Ddoc does
it. This should nicely improve the look of error messages.

--

[Issue 16302] Add opStaticIndex that takes compile-time indices

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16302

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Yuxuan Shui from comment #6)
> I want to suggest we just reuse opIndex. If opIndex is defined as a
> template, the static semantic is used.

This is a good idea.

s[arg1, arg2] is lowered to opIndex(arg1, arg2)

the compiler could try opIndex!(arg1, arg2) if it applies, otherwise fall back
on the normal opIndex.

Where I am concerned is the case where runtime indexing accepts template
parameters. However, in those cases, the template parameters must all be types,
and implied via IFTI, meaning it has runtime parameters that match each type.

The static opIndex needs to have zero runtime parameters ALWAYS. I think it
still can work.

I'd like to continue having the slice usage that is so flexible in the current
implementation at compile-time as well.

--

[Issue 17156] Local function declaration not inferred to be static

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17156

--- Comment #3 from Walter Bright  ---
(In reply to Eyal from comment #2)
> I see, but this would not be a problem if function was automatically
> convertible to delegate (std.functional : toDelegate).
> 
> Is there any reason that you cannot hand over functions when delegates are
> expected?

Yes. The ABI of how functions and delegates are passed ensures one cannot be
treated as the other.

The compiler could, behind the curtain, generate a wrapper to do this (as you
suggest), but that has negative performance implications that users could find
very surprising because it would be hidden from them. I prefer the library
template solution for that reason.

--

[Issue 17138] Warn about superfluous "with" statements

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17138

--- Comment #3 from Walter Bright  ---
Are you suggesting:

---
struct S {
int field;
}

void foo(S s) {
with (s)  // no error
++field;

with (s)  // error
++s.field;
}
---

?

--

[Issue 16657] alias this interacts with generated opCmp and opEquals

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16657

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
Since the auto-generated opEquals() theoretically always exists, having it take
precedence makes it a problem to wrap other types and defer to it. But the
problem does come in when the auto-generated opEquals() would be non-trivial,
as in:

---
struct A {
int x;
bool opEquals(int y) { return y == x; }
}

struct C {
int a;
A b;
alias a this;
}

static assert(C(1, A(1)) != C(1, A(2)));
---

The current state of affairs is that you'll need to write an explicit
C.opEquals() if using an 'alias this' and do not wish the operation to be
forwarded to it, even if the other fields have non-trivial opEquals()
implementations.

I suspect that this is the best solution if only because it is easy to
understand. It doesn't have any special cases and exceptions.

--

[Issue 16551] Compile-time delegate parameters should allow "scope"

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16551

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Walter Bright  ---
(In reply to Eyal from comment #0)
> // Syntax error, why? :(
> // void foo(scope Foo1 x)() @nogc;

It's because 'scope' is not a type constructor, it is a storage class.

> alias Foo2 = scope void delegate() @nogc; // <-- this "scope" seems to be 
> completely ignored!

This is because 'scope' here applies to what the delegate does with its 'this'
pointer (aka 'context' pointer, 'frame' pointer, 'dynamic link' pointer). foo()
could still store the delegate into a global variable, hence allowing it to
escape and hence a closure is necessary.

Currently, the following compiles successfully:

---
alias Foo2 = void delegate() @nogc; // no 'scope' necessary here

void foo(scope Foo2 x) @nogc { }

void main() @nogc {
int x;
foo({x+=1;});
}
---

Turning on inlining should remove the overhead of making it a runtime
parameter.

Adding 'scope' as an allowed storage class for template alias parameters would
be a significant and complex extension, and would need a strong use case
rationale. This would need to have a DIP created for it.

--

[Issue 16053] SysTime.fromIsoExtString don't work if nanoseconds are presented

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16053

--- Comment #2 from Jonathan M Davis  ---
https://github.com/dlang/phobos/pull/5389

--

[Issue 16540] Attributes do not propagate correctly in lazy params

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16540

--- Comment #2 from Walter Bright  ---
Added test case to ensure it keeps working:

https://github.com/dlang/dmd/pull/6776

--

[Issue 16540] Attributes do not propagate correctly in lazy params

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16540

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Walter Bright  ---
This is working successfully in the current DMD version.

--

[Issue 16538] Parameter head-const-ness shouldn't matter but does

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16538

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Fixed by https://github.com/dlang/dmd/pull/6731

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17391] SECURITY: XSS through DDOC comments

2017-05-13 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17391

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/4d69c1abd487319f274b11a44b833e165c57946d
Fix Issue 17391 - SECURITY: XSS through DDOC comments

Add a documentation note about the security considerations of
embeddable HTML in DDoc.

https://github.com/dlang/dlang.org/commit/c1d57d6182e8f012122d44479f2168545af9470a
Merge pull request #1649 from CyberShadow/pull-20170510-220714

Fix Issue 17391 - SECURITY: XSS through DDOC comments
merged-on-behalf-of: Sebastian Wilzbach 

--