[Class modifiers] dartdoc implementation

[itsjustkevin]

[srawlins]

There is real work to do here. If you take this table, we will basically have a getter on each ClassElement for each of the columns aside from Declaration, and will have to do the calculation to guess at what the Declaration was. Or perhaps ClassElement can have getters that do the logic like bool get isBase => isExtendableIn(myLibrary) && !isImplementableIn(myLibrary).

CC @kallentu @bwilkerson for any thoughts.

Or, if we're saying that developers don't want to know if a class is modified with base, but rather that they want to know if a class is extendable in/outside of it's library, maybe we present that.

[kallentu]

@srawlins What work is needed for this? I'm not sure what we're presenting.

[srawlins]

@jcollins-g may be planning to work on this.

I'm not sure what exactly we should present, or how. But one example is that we show the word 'abstract' in the breadcrumbs for an abstract class like List.

[jcollins-g]

@kallentu #3354 introduced some basic support that simply translates across the declaration. To complete this support we'll need to add handling for the inferred modifiers once this is added to the analyzer and published, so we're blocked on that bit. (We could of course do that here, too, but I think it's a bad idea to duplicate that functionality.)

[leafpetersen]

I said this in comments elsewhere, but to reiterate here. The core design principle of this feature is that users never need to reason about how modifiers combine. For example, if a class says "base", then it can be extended (anywhere). It would be extremely unfortunate if dartdoc broke this model by surfacing the transitive base requirements via syntax like sealed base, which would require users to do negative reasoning ("This class says base, but it can't be extended outside of the library because when you combine base with sealed it removes that ability").

[jcollins-g]

"Inferred modifiers" will not be displayed as though they were real class modifiers to avoid this confusion. There may be some other indication that a class supertype is base but not by pretending a sealed class is sealed base.

[jcollins-g]

This is now complete.