www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extern(C++) documentation missing

reply Manu <turkeyman gmail.com> writes:
Compare:
https://dlang.org/phobos/core_stdcpp_new_.html
and:
https://github.com/dlang/druntime/blob/master/src/core/stdcpp/new_.d

There's a lot of doco missing. The stuff wrapped in `extern(C++)`, and
also the bits in the `static if()` blocks.

Check out, https://dlang.org/phobos/core_stdcpp_array.html (and friends)
There's nothing there at all!

Anyone know what's the story here?
Hard to use a lib when the doco's empty.
Mar 03
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 3 March 2019 at 19:17:00 UTC, Manu wrote:
 Anyone know what's the story here?
ddoc is barely usable trash and the main site build process is broken af. My docs aren't perfect, but at least they're basically there. http://dpldocs.info/experimental-docs/core.stdcpp.html just fyi.
Mar 03
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Mar 3, 2019 at 11:35 AM Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 3 March 2019 at 19:17:00 UTC, Manu wrote:
 Anyone know what's the story here?
ddoc is barely usable trash and the main site build process is broken af. My docs aren't perfect, but at least they're basically there. http://dpldocs.info/experimental-docs/core.stdcpp.html just fyi.
Oh interesting. Yours has some rather different problems though, like `string_view` contains `u16string_view` and friends as members, but they're not :) So, assuming I want the official reference to be good, is this ddoc issues? Issues with the way I marked-up the declarations?
Mar 03
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 3 March 2019 at 19:57:06 UTC, Manu wrote:
 Oh interesting. Yours has some rather different problems 
 though, like `string_view` contains `u16string_view` and 
 friends as members, but they're not :)
Well, they are members of the module... though there totally was a bug in my parser. fixed http://dpldocs.info/experimental-docs/core.stdcpp.string_view.html if you refresh that now it looks reasonable to me. But, what is the actual rule with extern(C++) syntax? I know we have: extern(C++) extern(C++, Identifier.List) extern(C++, struct) extern(C++, class) extern(C++, "some_string") But, in your code, you use extern(C++, (An_Alias_To_A_String)) where is that defined in the spec? I see what it is supposed to do, and with those extra parens, it isn't hard to parse - I fixed my bug in 5 mins here - but I am thinking maybe the dmd version running for website doc gen also lacks support for parsing that and discarded the declaration too. I don't know the official website build process. I tried to understand it once and just ended up running in horror. But maybe the dmd there is just too old to support that particular syntax.
Mar 03
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Mar 3, 2019 at 12:30 PM Adam D. Ruppe via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 But, what is the actual rule with extern(C++) syntax? I know we
 have:
The parser allows: extern(C++) extern(C++, Identifier.List) extern(C++, struct) extern(C++, class) extern(C++, Expression[, Expression...]) Expression must be a compile-time evaluate-able string, otherwise compile error in semantic.
 But, in your code, you use

 extern(C++, (An_Alias_To_A_String))
Parens are just a hack to make it not caught by the Identifier case, it will be properly parsed an Expression.
 I don't know the official website build process. I tried to
 understand it once and just ended up running in horror. But maybe
 the dmd there is just too old to support that particular syntax.
Do you have reason to believe it wouldn't use the release DMD build to build the docs for each release?
Mar 03
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 3 March 2019 at 21:55:25 UTC, Manu wrote:
 Do you have reason to believe it wouldn't use the release DMD 
 build to build the docs for each release?
It always uses the latest version, only the ddox (don't confuse with ddoc) is built with a stable DUB + DMD version, s.t. dub is locked (and doesn't need to be built on every PR). Anyhow, I did a bump regardless: https://github.com/dlang/dlang.org/pull/2598
Mar 03
parent reply Manu <turkeyman gmail.com> writes:
On Sun, Mar 3, 2019 at 9:55 PM Seb via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 3 March 2019 at 21:55:25 UTC, Manu wrote:
 Do you have reason to believe it wouldn't use the release DMD
 build to build the docs for each release?
It always uses the latest version, only the ddox (don't confuse with ddoc) is built with a stable DUB + DMD version, s.t. dub is locked (and doesn't need to be built on every PR). Anyhow, I did a bump regardless: https://github.com/dlang/dlang.org/pull/2598
I doubt there was anything between 2.084 and 85 that would have affected it. I suspect it just doesn't work on any of this core.stdcpp code :/ Can/will it document inside a `static if`?
Mar 03
parent Seb <seb wilzba.ch> writes:
On Monday, 4 March 2019 at 06:41:17 UTC, Manu wrote:
 I doubt there was anything between 2.084 and 85 that would have 
 affected it.
 I suspect it just doesn't work on any of this core.stdcpp code 
 :/
 Can/will it document inside a `static if`?
Do you mean: --- version (Ddoc) { ... } else { ...} --- Yeah that would work. Though it would probably be less work to fix it for good by adjusting the ToDocBuf in doc.d: https://github.com/dlang/dmd/blob/master/src/dmd/doc.d
Mar 03
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 3 March 2019 at 19:57:06 UTC, Manu wrote:
 Issues with the way I marked-up the declarations?
Some of the modules though are missing ddoc comments though, like typeinfo.d
Mar 03