Bug 11823 – ddoc: built-in symbols with leading underscore should be specially parsed
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-12-26T05:03:00Z
Last change time
2014-02-02T15:43:00Z
Keywords
ddoc, pull
Assigned to
andrej.mitrovich
Creator
andrej.mitrovich
Comments
Comment #0 by andrej.mitrovich — 2013-12-26T05:03:14Z
http://dlang.org/phobos/std_exception.html#.assertNotThrown
string file The file where the error occurred. Defaults to _FILE__.
Note the "_FILE__" instead of "__FILE__". This is because ddoc has a special feature allowing you to avoid highlighting symbols in the output, e.g.:
-----
/// This function foo is named _foo
void foo() { }
-----
This will highlight the first foo word but not the second.
However, for __FILE__ and other built-in symbols beginning with an underscore ddoc should probably avoid interpreting the leading underscore as an attempt to de-emphasize the symbol, and instead just output these symbols as-is.
Comment #1 by andrej.mitrovich — 2014-01-30T02:21:15Z
I'm not sure this is the right approach. An alternative is to recognize __FILE__, etc., as special.
Comment #3 by andrej.mitrovich — 2014-01-30T23:56:50Z
(In reply to comment #2)
> I'm not sure this is the right approach. An alternative is to recognize
> __FILE__, etc., as special.
Well according to the spec compiler-reserved symbols start with double underscores, so I picked that approach. I guess we could instead implement an isBuiltinSymbol check?
Comment #4 by k.hara.pg — 2014-02-01T06:37:33Z
(In reply to comment #3)
> (In reply to comment #2)
> > I'm not sure this is the right approach. An alternative is to recognize
> > __FILE__, etc., as special.
>
> Well according to the spec compiler-reserved symbols start with double
> underscores, so I picked that approach. I guess we could instead implement an
> isBuiltinSymbol check?
Even if double-underscored symbols are reserved in language spec, users can use them in their own own responsibility. (currently dmd does not reject defining such names). Therefore I think isBuiltinSymbol check would be better, because it is more conservative way.
Comment #5 by github-bugzilla — 2014-02-02T14:11:24Z