[PATCH] D143704: [Flang] Part one of Feature List action

Thu Feb 16 06:55:38 PST 2023

schweitz added a comment.

In D143704#4130124 <https://reviews.llvm.org/D143704#4130124>, @jdoerfert wrote:

> In D143704#4130062 <https://reviews.llvm.org/D143704#4130062>, @clementval wrote:
>
>> Where is this coming from? Did I miss where this was discussed.
>
> It's discussed here, for now. :)
>
>> You will not be able to find all not implemented features by going on through the AST. Most of the not implemented message are triggered by lowering.
>
> Right. Let's take a step back.
> First, this allows us to identify (and count) features used by an app programmatically. This is in itself useful and we should not intertwine it with the (non-)implemented parts (see my comment from before).
> Next, we want to identify if a "feature" is implemented or not. This is arguably not a straight forward task and also not 100% tied to AST nodes, however, it would be a useful capability for the time being.
> One idea was to extend the `TODO` function to include some tie to a AST entity. That will work sometimes, and sometimes it won't. In either case it is unclear how we can continue lowering (or whatever stage the TODO is in).
> Thus, we might want to manually associate the existing `TODO`s with AST features in a map we maintain. So we run this counting scheme, then lookup each entity in the map, and provide feedback if it is supported, not supported, or partially supported (or unknown).
> All that said, let's separate the concerns into 1) listing of features, and 2) assigning implementation status. This patch does only the former and should be reviewed as such.

For some background context:

TODO is a macro. It had 2 purposes. 1. Developers: easy to grep for and find. 2. Developers and users: imposing a practice where flang would halt (semi-)meaningfully rather than generate garbage output for the user to wade through.

It has no association with the parse tree. (Flang doesn't have an AST to my knowledge.) The flang parser has its own diagnostics reporting system.

TODO is flexible enough to allow different diagnostic systems to be used, different sorts of fatal exits to report different information, etc.

However, it should be considered harmful to make the TODO macro always associate with some syntactic source artifact. It would also be unwise to redefine TODO from a halt semantics to a "just keep going and see what happens" semantics.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143704/new/

https://reviews.llvm.org/D143704