Re: My first compiler bug: work around or redesign?

[Natasha Kerensikova <lithiumcat@gmail.com>]

Hello,

On 2012-03-23, Natasha Kerensikova <lithiumcat@gmail.com> 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