Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix handling of warning attribute attached to type declarations #1977
The change looks obviously correct but the overall structure is a bit perplexing: among the many functions around this change that looks exactly the same, why is this one the only one protected in this way? It looks like either (1) the protection for other similar actions is done at a different level in the codebase, and your fix should go there as well or (2) this one is currently a special case because other
I agree. My impression is that (2) is more like it. I am looking into it and will revise the patch afterwards.
OK, so it was more like (1) after all. I moved the fix to
Entries in this hash table are inserted by the function
The registered callback initially amounts to a boolean
However, this assumption does not hold anymore if we respect warning attributes attached to the individual type declarations. For if one of them disables the warning in question (Warning 34), then
Instead of failing an assertion, we gracefully handle the case of a non-existing callback to account for this case.
More generally, it seems an approach where warnings are passed as arguments rather than handled indirectly via references would really simplify things. It will probably require a fair amount of refactoring, but I feel it would be worthwhile. I will look into it, but am interested if anyone has an opinion on this point.
The new patch still looks obviously correct to me.
I wondered if you couldn't change
I certainly agree. I would note that this part of the codebase is really @alainfrisch's private garden. (But presumably he would still be happy if it was all cleaned up when he comes back from vacation.)