From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,bdebc54a485c13a4 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.236.170 with SMTP id uv10mr9533159pbc.4.1332785715465; Mon, 26 Mar 2012 11:15:15 -0700 (PDT) Path: z9ni4539pbe.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: My first compiler bug: work around or redesign? Date: Mon, 26 Mar 2012 18:15:14 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Injection-Date: Mon, 26 Mar 2012 18:15:14 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="12666"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18KyNTbM0uBj8llpJzepWli" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:QEre6Q3JkB7+czIIyZ+YeEVagdY= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2012-03-26T18:15:14+00:00 List-Id: Hello, On 2012-03-23, Natasha Kerensikova wrote: > I happen to have encountered my very first compiler bug, or at least > something that claims to be in the following message: There is a new development in the situation, and would love to have your collective opinion about what to do next. It turns out that simply replacing all occurrences of "in not null Element_Renderer" by "in Element_Renderer" is enough to make compilation succeed (and the binary does pass the Markdown test suite, except for the known little differences I detailed in my previous post). Thanks a lot to Georg Bauhaus for the Ada-95-ification patch, which contained a lot of "not null" removal. Combined with a look in gnat_to_gnu_entity source (barely enough to understand the assertion fails because of something about the type of an argument), it led me to try this. Here is the context I think relevant. The type involved is Element_Renderer, defined as: type Element_Renderer is access procedure (State : in out Renderer_State_Type; Actions : in Render_Action_Set; Parameters : in Parameter_Map; Contents : in String); where Renderer_State is an unconstrained limited private formal type, Render_Action_Set and Parameter_Map are definite normal types defined in a parent package. The type is used by the parser to retrieve renderer callback provided by the client. A null value is used as default to indicate no renderer (but NOT no rendering) thus disabling the language element. Somewhere in parser internals I use another kind of callbacks, that I call lexers (but I'm not completely sure I use the word with its correct meaning, though it does refer to code that find token start and end in a given String). These callbacks match the following type: type Element_Lexer is access procedure (State : in out Lexer_State_Type; Source : String; Position : in out Positive; Renderer : in not null Element_Renderer; Renderer_State : in out Renderer_State_Type; Render_Param : in out Parameter_Map); At this point, it does not make sense for Renderer to be null, because as explained above, a null value would have disabled the element and the Element_Lexer would never be called. So I added the "not null" constrained. I have to admit I don't really master everything about anonymous access types and stuff like that, I thought that "not null Element_Renderer" would be a subtype of Element_Renderer just like "Natural range 1 .. Natural'Last" would be a subtype of Natural. But maybe I'm creating an access type out of nowhere or something like that. So to make my code compile successfully, it's enough to remove the "not null" in Element_Lexer declaration and in all the matching procedure from Dressup.Parsers.Markdown. So now, the questions. Does it make sense to use "not null" in such a way? That is, if the bug did not exist, would my code be better off with it or without it? Is it really worth reporting? Thinking about it, I'm not even sure my code is actually legal: could "not null Element_Renderer" be illegal but previously interpreted correctly because of a fluke? Or should it be accepted? And assuming I should report it, how to so? AdaCore seemed the best starting point, but their website isn't exactly straightforward on how to be send bug reports. Is there anything better than http://libre.adacore.com/libre/contact/ ? Thanks for your insights, Natasha