Thread overview
extern(C++) documentation missing
Mar 03
Manu
Mar 03
Manu
Mar 03
Manu
Mar 04
Seb
Mar 04
Manu
Mar 04
Seb
March 03
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.
March 03
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.
March 03
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?
March 03
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.
March 03
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
March 03
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?
March 04
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
March 03
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`?
March 04
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