Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve type aliases for records in output #3340

Merged
merged 8 commits into from
Feb 16, 2023

Conversation

jcollins-g
Copy link
Contributor

@jcollins-g jcollins-g commented Feb 16, 2023

Adds functionality to preserve the name of an alias when rendering typedefs referencing records, and a test. This builds on #3239 and implements the second half of this comment on #3122.

Doing this required or strongly suggested some refactoring. We now delegate ElementType construction into factories for UndefinedElementType and DefinedElementType, which may make it more clear where to put these in the future. As part of this did the TODO to wipe out support for old FunctionElementTypes that were backed by an Element since that was a simple delete. I also added some sample code to the experiments package so dartdocs containing records can be checked for bugs by human eyes, while moving out "experimental" examples for constructor tearoffs that no longer need to be there.

@jcollins-g jcollins-g changed the title Render typedef names for records when used Preserve type aliases for records in output Feb 16, 2023
@jcollins-g jcollins-g marked this pull request as ready for review February 16, 2023 17:10
Copy link
Member

@srawlins srawlins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!


expect(fFunc.modelType.returnType, isA<AliasedUndefinedElementType>());
expect(
(fFunc.modelType.returnType as AliasedUndefinedElementType)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be folded into the above expectation with having, I think.

isA<...>()
    .having((e) => e.typeAliasElement, 'typeAliasElement', equals(rTypedef.element))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, nice. Much better. Done.

@@ -1538,7 +1538,7 @@ void main() {
expect(
B.documentationAsHtml,
contains(
'<p>Extends class <a href="${htmlBasePlaceholder}ex/Apple-class.html">Apple</a>, use <a href="${htmlBasePlaceholder}ex/Apple/Apple.html">new Apple</a> or <a href="${htmlBasePlaceholder}ex/Apple/Apple.fromString.html">new Apple.fromString</a></p>'));
'<p>Extends class <a href="${htmlBasePlaceholder}ex/Apple-class.html">Apple</a>, use <a href="${htmlBasePlaceholder}ex/Apple/Apple.html">Apple.Apple</a> or <a href="${htmlBasePlaceholder}ex/Apple/Apple.fromString.html">Apple.fromString</a></p>'));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these should be changed to Apple.new instead of Apple.Apple since Apple.Apple is not recognized by the analyzer (and thus the IDE). I don't think we need to test that this syntax works.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good catch, yes this is a better choice.

@jcollins-g jcollins-g merged commit dba6f94 into dart-lang:master Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants