[Issue 18744] Class l-values can be implicitly converted to `Object` l-values, even in safe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18744

Stefan  changed:

   What|Removed |Added

 CC||kde...@vogtner.de

--

[Issue 18744] New: Class l-values can be implicitly converted to `Object` l-values, even in safe code

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18744

  Issue ID: 18744
   Summary: Class l-values can be implicitly converted to `Object`
l-values, even in safe code
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: accepts-invalid, safe
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@klickverbot.at

---
@safe:

class A { int* a; }
class B { long b; }

// Either of these shouldn't be allowed:
void boom1(ref A a, B b) { (cast(Object)a) = b; }
void boom2(ref A a, B b) { (true ? a : b) = b; }

int main() {
  A a = new A;
  B b = new B;
  boom1(a, b);
  boom2(a, b);
  return *a.a;
}
---

compiles fine on DMD 2.079, but covariance in l-values can't be allowed. This
is the same problem often illustrated using containers.

--

[Issue 18743] ConditionalExpression and AssignExpression should require parentheses

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18743

--- Comment #2 from David Nadlinger  ---
(Note that this _is_ part of the specification in form of the grammar.
Assignment is defined as 

AssignExpression:
ConditionalExpression
ConditionalExpression = AssignExpression
ConditionalExpression += AssignExpression
ConditionalExpression -= AssignExpression
ConditionalExpression *= AssignExpression
ConditionalExpression /= AssignExpression
ConditionalExpression %= AssignExpression
ConditionalExpression &= AssignExpression
ConditionalExpression |= AssignExpression
ConditionalExpression ^= AssignExpression
ConditionalExpression ~= AssignExpression
ConditionalExpression <<= AssignExpression
ConditionalExpression >>= AssignExpression
ConditionalExpression >>>= AssignExpression
ConditionalExpression ^^= AssignExpression

which unambiguously specifies the precedence.)

--

[Issue 18743] ConditionalExpression and AssignExpression should require parentheses

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18743

David Nadlinger  changed:

   What|Removed |Added

 CC||c...@klickverbot.at
   Hardware|x86_64  |All
Summary|Conditional expression  |ConditionalExpression and
   |(ternary operator) can  |AssignExpression should
   |evaluate the third  |require parentheses
   |expression even "If it is   |
   |true"   |
 OS|Linux   |All
   Severity|normal  |enhancement

--- Comment #1 from David Nadlinger  ---
This isn't a bug.

In D, ?: has higher precedence than =, so

true ? stt = "AA" : stt = "BB"

means

(true ? (stt = "AA") : stt) = "BB",

in line with C and other languages, but notably not C++.

The operator precedence should be documented somewhere, though; while there is
a table in TDPL (p. 61 ff.) and on the Wiki
(https://wiki.dlang.org/Operator_precedence), I can't seem to find it on
dlang.org/spec.

---

Changing this to an enhancement request, as we should really consider requiring
explicit parenthesization for this sort of error-prone code, similar to how we
disallow assignment expressions in if statements.

--

[Issue 18743] Conditional expression (ternary operator) can evaluate the third expression even "If it is true"

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18743

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18743] New: Conditional expression (ternary operator) can evaluate the third expression even "If it is true"

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18743

  Issue ID: 18743
   Summary: Conditional expression (ternary operator) can evaluate
the third expression even "If it is true"
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: acehr...@yahoo.com

string stt = "none";
true?writeln("AA"):writeln("BB");   ///Out:AA
true?stt="AA":stt="BB";-///Out:BB
writeln(stt); 

Copied from the forum discussion:

  https://forum.dlang.org/post/rjcjecmgrpeqbdrht...@forum.dlang.org

The behavior does not match the spec:

  https://dlang.org/spec/expression.html#conditional_expressions

Ali

--

[Issue 18742] New: std.regex: Using CodePointSet in AAs breaks if reference count changes

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18742

  Issue ID: 18742
   Summary: std.regex: Using CodePointSet in AAs breaks if
reference count changes
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: bootcamp
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: johannesp...@gmail.com

When storing a CodePointSet in an AA, the reference count member is included
when hashing, so two identical CodePointSets only differing in the reference
count are not considered as the same AA key. std.regex does actually put
CodePointSets into AAs, so this seems very fragile. As a solution, CodePointSet
should properly implement the toHash function.

Test case:
--
import std.uni, std.stdio;

void main()
{
int[CodepointSet] aa;
auto set = unicode.Nd;
aa[set] = 42;
writeln(aa[set]);
}
--
This is expected to print 42, but currently throws a RangeError instead.

--

[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18026

--- Comment #5 from JR  ---
(In reply to Seb from comment #4)
> JR: Cool! I can reproduce it on my machine too :)

[...]

> I will look at reducing this even further tomorrow.

Awesome, thanks!

--

[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18026

--- Comment #4 from Seb  ---
JR: Cool! I can reproduce it on my machine too :)

For reference, here's what's necessary for reproducing this without dub:

/home/seb/dlang/dmd/generated/linux/release/64/dmd -c -offoo.o -w -Isource/
source/kameloso/common.d source/kameloso/irc.d source/kameloso/ircdefs.d
source/kameloso/main.d source/kameloso/plugins/notes.d -vcolumns | head -n20

Program received signal SIGSEGV, Segmentation fault.
0x557f4187 in TemplateInstance::needsCodegen() ()
#0  0x557f4187 in TemplateInstance::needsCodegen() ()
#1  0x557f42c6 in TemplateInstance::needsCodegen() ()
#2  0x557f42c6 in TemplateInstance::needsCodegen() ()
#3  0x557f42c6 in TemplateInstance::needsCodegen() ()
#4  0x557f42c6 in TemplateInstance::needsCodegen() ()
#5  0x557f42c6 in TemplateInstance::needsCodegen() ()
#6  0x557f42c6 in TemplateInstance::needsCodegen() ()
#7  0x557f42c6 in TemplateInstance::needsCodegen() ()
#8  0x557f42c6 in TemplateInstance::needsCodegen() ()


I will look at reducing this even further tomorrow.

--

[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18026

--- Comment #3 from JR  ---
I reduced it to 58 lines using dustmite, which is incidentally amazing.

Under 2.079.0, it compiles in -debug mode but doesn't outside of it. 2.078.3
can however compile it in both. The code is nonsense, but it appears to trigger
the behaviour.

> $ git clone https://github.com/zorael/kameloso -b 2.079-overflow
> $ cd kameloso
> $ dub build -b debug  # works
> 
> $ dub build -b plain
> /usr/bin/dmd failed with exit code -11.
> 
> $ gdb --batch -ex "run" --args dmd source/kameloso/*.d 
> source/kameloso/plugins/*.d
> Program received signal SIGSEGV, Segmentation fault.
> 0x55825982 in TemplateInstance::needsCodegen() ()

I tested it on Travis and CircleCI. Both run 2.079.0, and Travis could not
reproduce the segfault. CircleCI however could! Please see
https://circleci.com/gh/zorael/kameloso/151.

Again, this seems to only affect 2.079.0, and only on *some* distributions.
Unless your linux installation sees the behaviour, I imagine the only way to
observe it is to download a Manjaro .iso and run it in a virtual machine.
Apologies.

I wish I could produce something more tangible but this is how ephemeral the
issue is.

--

[Issue 18471] std.experimental.checkedint.Checked doesn't check on assignment or construction

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18471

petrug  changed:

   What|Removed |Added

 CC||petru.guri...@gmail.com
   Assignee|nob...@puremagic.com|petru.guri...@gmail.com

--