Ah, yes, I believe for .capnp files which were imported but not specified
explicitly on the command-line, the compiler tries to pass along only the
declarations that are referenced (transitively) from the main files. This
computation explicitly does not consider `nestedNodes` to count as a
reference, since otherwise everything would be referenced.

-Kenton

On Wed, Sep 7, 2016 at 9:31 AM, Andreas Stenius <[email protected]> wrote:

> David is perfectly right. I didn't fully realize what was wrong until
> halfway through writing my email. I've already adapted my compiler plugin
> to handle this scenario, so unless it is an unwanted laziness, there's
> nothing wrong. :)
>
>
>
> ons 7 sep. 2016 kl. 03:40 skrev David Renshaw <[email protected]>:
>
>> I believe Andreas's question can be illustrated with
>> c++/samples/addressbook.capnp.
>>
>> capnp compile -o - addressbook.capnp | capnp decode
>> /usr/local/include/capnp/schema.capnp CodeGeneratorRequest
>>
>> In the output, `nodes` contains
>>
>>     ( id = 13688829037717245569,
>>       displayName = "capnp/c++.capnp",
>>       displayNamePrefixLength = 10,
>>       scopeId = 0,
>>       nestedNodes = [
>>         ( name = "namespace",
>>           id = 13386661402618388268 ),
>>         ( name = "name",
>>           id = 17466269397259751886 ) ],
>>       annotations = [
>>         ( id = 13386661402618388268,
>>           value = (
>>             text = "capnp::annotations" ),
>>           brand = () ) ],
>>       file = void,
>>       isGeneric = false ),
>>
>> and
>>
>>     ( id = 13386661402618388268,
>>       displayName = "capnp/c++.capnp:namespace",
>>       displayNamePrefixLength = 16,
>>       scopeId = 13688829037717245569,
>>       nestedNodes = [],
>>       annotation = (
>>         type = (text = void),
>>         targetsFile = true,
>>         targetsConst = false,
>>         targetsEnum = false,
>>         targetsEnumerant = false,
>>         targetsStruct = false,
>>         targetsField = false,
>>         targetsUnion = false,
>>         targetsGroup = false,
>>         targetsInterface = false,
>>         targetsMethod = false,
>>         targetsParam = false,
>>         targetsAnnotation = false ),
>>       isGeneric = false ),
>>
>> but nothing for capnp/c++.capnp:name, i.e. id=17466269397259751886.
>>
>> So in some sense there is a dangling reference in `nestedNodes`.
>>
>> What's happening here, I think, is that `capnp compile` is being
>> (intentionally) lazy about which nodes it outputs. It doesn't include
>> the node for `c++.capnp:name` because that node is not needed to
>> compile `addressbook.capnp`.
>>
>>
>> - David
>>
>>
>>
>>
>> On Tue, Sep 6, 2016 at 9:02 PM, Kenton Varda <[email protected]> wrote:
>> > Hi Andreas,
>> >
>> > Sorry, I don't understand what you're describing. Could you maybe
>> provide a
>> > test case -- a simple capnp file that I can run through the compiler and
>> > then dump the CodeGeneratorRequest -- and then tell me exactly what is
>> > unexpected about the request?
>> >
>> > -Kenton
>> >
>> > On Mon, Sep 5, 2016 at 1:46 AM, Andreas Stenius <[email protected]> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Quick question, I'm looking at a bug I have in my Erlang capnp compiler
>> >> plugin, and have found the issue to stem from the fact that there is a
>> >> reference to a node id that isn't included in the global `nodes` list
>> of the
>> >> `CodeGeneratorRequest` struct, and wonder if this is intended.
>> >>
>> >> Looking at the compiled `schema.capnp`, it also includes nodes for
>> >> `c++.capnp` as it was imported in the schema file, and the `namespace`
>> >> attribute node is present in `nodes`, but the `name` attribute is not.
>> >>
>> >>
>> >> Some excerpts from a dumped code generator request for schema.capnp
>> (using
>> >> a rather dated 0.6-dev, but I got the samme issue with a newly built
>> >> version):
>> >>
>> >> ```
>> >> requestedFiles = [(id = 12195682960037147353, filename = schema.capnp,
>> >> imports = [(id = 13688829037717245569, name = /capnp/c++.capnp)])]
>> >> ```
>> >>
>> >> From the `nodes` array:
>> >>
>> >> ```
>> >>  (id = 13688829037717245569, displayName = capnp/c++.capnp,
>> >> displayNamePrefixLength = 10, scopeId = 0, nestedNodes = [(name =
>> namespace,
>> >> id = 13386661402618388268),
>> >>  (name = name, id = 17466269397259751886)], annotations = [(id =
>> >> 13386661402618388268, value = (text = <<99,97,112,110,...>>))], file =
>> >> void),
>> >> ```
>> >>
>> >> we see the node for the c++.capnp file, and have two nested nodes (name
>> >> and namespace). The namespace node is present in the list as well:
>> >>
>> >> ```
>> >>  (id = 13386661402618388268, displayName = capnp/c++.capnp:namespace,
>> >> displayNamePrefixLength = 16, scopeId = 13688829037717245569,
>> nestedNodes =
>> >> [], annotations = [], annotation = (type = (text = void),
>> >>  targetsFile = true, targetsConst = false, targetsEnum = false,
>> >> targetsEnumerant = false, targetsStruct = false, targetsField = false,
>> >> targetsUnion = false, targetsGroup = false, targetsInterface = false,
>> >> targetsMethod = false, targetsParam = false, targetsAnnotation =
>> false)),
>> >> ```
>> >>
>> >> while the name attribute node is not.. searching for
>> 17466269397259751886
>> >> gives just the one hit, in the nested nodes of the c++.capnp node.
>> >>
>> >> I realize this could be an optimization, that the node is not included
>> as
>> >> it isn't referenced directly in the schema file being compiled..
>> >>
>> >> Sorry if this has been covered already, my searches failed to reveal
>> them,
>> >> if that's the case..
>> >>
>> >> Cheers,
>> >> Andreas
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Cap'n Proto" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to [email protected].
>> >> Visit this group at https://groups.google.com/group/capnproto.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Cap'n Proto" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to [email protected].
>> > Visit this group at https://groups.google.com/group/capnproto.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Cap'n Proto" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> Visit this group at https://groups.google.com/group/capnproto.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Cap'n Proto" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> Visit this group at https://groups.google.com/group/capnproto.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.

Reply via email to