[Issue 15476] New: DDOC_UNDEFINED_MACRO is undocumented

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15476

  Issue ID: 15476
   Summary: DDOC_UNDEFINED_MACRO is undocumented
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: destructiona...@gmail.com

http://dlang.org/spec/ddoc.html

"If the macro name is undefined, the replacement text has no characters in it."

Not true.

--

[Issue 15477] New: Forward reference error corner case with base class and template specialization arguments

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15477

  Issue ID: 15477
   Summary: Forward reference error corner case with base class
and template specialization arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: syniu...@gmail.com

Related to issue 12152, there are still bogus forward reference errors.

class QObjectPrivate : QObjectData
{
struct Sender
{
void *sender;
int signal;
int ref_;
}
}

class QObjectData
{
uint o;
QTypeInfo!uint ti;
}

struct QTypeInfo(T : uint)
{
immutable string info = "a";
}

struct QTypeInfo(T : QObjectPrivate.Sender)
{
immutable string info = "b";
}
-
Error: class main.QObjectPrivate is forward referenced when looking for
'Sender'

The order of declaration matters, if the base class QObjectData is declared
before QObjectPrivate then it compiles fine. So the workaround is simple if you
can just modify the code, but this happens with Qt5 mapped by Calypso where
this isn't an option.

What happens is:
1/ ClassDeclaration::semantic() on QObjectPrivate tries to run semantic() on
the base class QObjectData
2/ semantic() on QObjectData calls semantic() on the template instance
QTypeInfo!uint
3/ TemplateInstance::findTempDecl() attempts to semantic() the specialization
arguments of all the QTypeInfo overloads

But for the QObjectPrivate.Sender one, ClassDeclaration::search("Sender") fails
because the ClassDeclaration for QObjectPrivate doesn't have a symtab yet.

Moving the fix for issue 12152
(https://github.com/D-Programming-Language/dmd/pull/4469) to before
semantic'ing the base classes seems to fix it.


However this may not be the right way to see it.
ClassDeclaration::search("Sender") fails also because ->scope was set to NULL
at the beginning of ClassDeclaration::semantic on QObjectPrivate so search()
doesn't call semantic(). I haven't tested but that second call should work and
populate the symtab if it doesn't re-go through semantic() on the base class
(but at this point ->scope is also null for QObjectData so it won't). Anyway
simply moving the symtab populating seems like the simplest fix.

--

[Issue 14804] Comparing two Nullables does not check if either is null

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14804

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
I was about to propose a PR that changes the behavior of Nullable but actually
I think your report is invalid:

1/ it only throws in asseert mode, which allows to detect a wrong usage when
testing the software and maybe to add some isNull() before comparing if
necessary.

2/ if a custom opEquals() is added, even if it works fine, it becomes quite
unclear how opCmp() should behave then.

see the changes:

https://github.com/BBasile/phobos/commit/f458ad1318e5536c91882c02397df262961c63a2#diff-4e008aedb3026d4a84f58323e53bf017R1930

so I suggest you to close.

--

[Issue 15464] Template parameter-dependent attributes

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15464

--- Comment #7 from Andrei Alexandrescu  ---
Thanks Daniel for the work and Kenji for the analysis!

There are similarities between this situation and:

static if (condition1)
void func(T)() if (condition2);

condition1 cannot use T because it hasn't "appeared" syntactically yet. Of
course, technically it's possible to make that work but it's not natural.

Somewhat similarly, for template functions it stands to reason that prefix
attributes apply to the template symbol, whereas postfix attributes apply to
the instantiation. Then:

* Attributes of the template propagate to the instantiation

* If there's a conflict between the template and instantiation attributes,
that's an error.

Sounds reasonable?

--

[Issue 15473] New: C++ mangling problem

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15473

  Issue ID: 15473
   Summary: C++ mangling problem
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

C++ produces this symbol:
?asAssocArray@Variant@ep@@QEBA?AU?$SharedMap@U?$AVLTree@UVariant@ep@@U12@U?$Compare@UVariant@ep@@@2@@ep@@@2@XZ

D produces this symbol:
?asAssocArray@Variant@ep@@QEBA?AU?$SharedMap@U?$AVLTree@UVariant@ep@@0U?$Compare@UVariant@ep@@@2@@ep@@@2@XZ


The difference is that little 'U12@' vs '0'. The MS linker de-mangles both
symbols to read identical, so I don't know what it means.


The C declaration:

namespace ep {
struct Variant
{
  ep::SharedMap> asAssocArray() const;
};
} // namespace


The D declaration:

extern (C++, ep) {
struct Variant
{
  SharedMap!(AVLTree!(Variant, Variant, Compare!Variant)) asAssocArray() const;
}
}


All those things are extern(C++, ep), and they work properly on their own.

--

[Issue 15473] C++ mangling problem

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15473

--- Comment #1 from Manu  ---
On a tangent, I'm having a lot of trouble with the fact that MSVC mangles
classes differently than struct's... I feel like I need a way to control which
to choose on the D side. UDA perhaps?

--

[Issue 15474] New: Ddoc - defining an empty macro at the end of a Macros section does not work

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15474

  Issue ID: 15474
   Summary: Ddoc - defining an empty macro at the end of a Macros
section does not work
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: destructiona...@gmail.com

/**
Test

test2

test3

Macros:
DDOC=$(BODY)
DDOC_BLANKLINE=
*/
module t2;



Generates:


Test

test2


test3




Those blank lines are still there. Swap the order of definition of those two
macros:


/**
Test

test2

test3

Macros:
DDOC_BLANKLINE=
DDOC=$(BODY)
*/
module t2;



Hey, look, blank line = nothing respected now!


Test

test2


test3





Notice that there isn't one between test2 and test3 anymore.

--

[Issue 15475] New: Ddoc code sample with unbalanced paren comes out as macro

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15475

  Issue ID: 15475
   Summary: Ddoc code sample with unbalanced paren comes out as
macro
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: destructiona...@gmail.com

/**
---
// code sample with unbalanced (
---
*/
module t2;


Spits out:


// code sample with unbalanced $(LPAREN)



in the final code.

--

[Issue 15474] Ddoc - defining an empty macro at the end of a Macros section does not work

2015-12-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15474

Adam D. Ruppe  changed:

   What|Removed |Added

   Severity|enhancement |minor

--