www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Bug with -D and static if

reply pragma <pragma_member pathlink.com> writes:
This one is really baffling.  It looks like some kind of template/static-if
resolution bug due to interaction with ddoc support (?!).

---------------------
/// comment
template foobar()
{
static if (true) const bool foobar=false;
}
----------------------

c:\>dmd -c bug.d -D
bug.d(4): Error: static if conditional cannot be at global scope

-----------------------
The conditions for creating this are pretty consise.  Consider the following
things that make the bug go away:
- Change the comment to '//' from '///'
- Don't compile with '-D'
- Change 'foobar=false' to 'gorf=false' (make the template resolve to a
namespace rather than a statement I suppose).

I have not tested this with other styles of ddoc comments.

Note: The above error message also does not return the correct file name in most
cases, although it does give the right line number.  If you are seeing this
error in your code, you'll have to manually trace back through your template
calls to find the offending ddoc comment (as removing the extra '/' functions as
a workaround).



- EricAnderton at yahoo
Jan 14 2006
next sibling parent pragma <pragma_member pathlink.com> writes:
[...]pretty consise.


Apparently, I kant speel rite.  Just be thankful that I didn't type this in on a
cellphone.


I have not tested this with other styles of ddoc comments.


The point to this addendum: I just tested this.  Other doc styles (like /** ...
*/) also cause the same problem.

- EricAnderton at yahoo
Jan 14 2006
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <dqbksg$be0$1 digitaldaemon.com>, pragma says...

This one is really baffling.  It looks like some kind of template/static-if
resolution bug due to interaction with ddoc support (?!).

---------------------
/// comment
template foobar()
{
static if (true) const bool foobar=false;
}
----------------------

c:\>dmd -c bug.d -D
bug.d(4): Error: static if conditional cannot be at global scope

-----------------------
The conditions for creating this are pretty consise.  Consider the following
things that make the bug go away:
- Change the comment to '//' from '///'
- Don't compile with '-D'
- Change 'foobar=false' to 'gorf=false' (make the template resolve to a
namespace rather than a statement I suppose).

I have not tested this with other styles of ddoc comments.

Note: The above error message also does not return the correct file name in most
cases, although it does give the right line number.  If you are seeing this
error in your code, you'll have to manually trace back through your template
calls to find the offending ddoc comment (as removing the extra '/' functions as
a workaround).



- EricAnderton at yahoo


That's at least two reports on this bug now. Would be nice to get that fixed,
along with the other DDoc issues. Perhaps you could post a list of all the
problems/concerns/enhancements you know about, Eric? I'd really like to start
using DDoc, but it just needs a little more attention first :)
Jan 14 2006
parent pragma <pragma_member pathlink.com> writes:
In article <dqbu63$i47$1 digitaldaemon.com>, Kris says...

That's at least two reports on this bug now. Would be nice to get that fixed,
along with the other DDoc issues. 


Yikes. I haven't ducked into the bugs board for months now, so I guess that's
why I missed it.  Of course, that does make some sense since it wasn't exactly
hard to trigger.


 Perhaps you could post a list of all the problems/concerns/enhancements you
know about, Eric? I'd really like to start using DDoc, but it just needs a
little more attention first :)


As for problems, the tool does a good job for what it was intended for: simple
HTML documentation - I only run into problems when I ask it to do more than
that.

The only major thing that could be added is to make the built-in ddoc macros
less hostile to building a proper cross-reference.  The macros would be easier
to use if they could be nested in a way that's condusive to markup (SECTION_H
and SECTION should be the same macro IMO).  Also, function signatures, when
emitted from ddoc, aren't broken down into their constitutent parts so one has
to *parse the ddoc output* in order to understand them programmatically ick.

Of course it would be *really* nice if DMD would just accept a DLL file to
process the digested parse-tree and comments on its behalf - then composing a
superior ddoc engine is no longer Walter's problem... just a thought.

Seeing as how I'm on a bugfix/documentation kick this month, I'll see about
starting a discussion (read: trouble) out in the main NG once I know what I'm
talking about.  I'm just thinking aloud here. :)

- EricAnderton at yahoo
Jan 14 2006