-
Notifications
You must be signed in to change notification settings - Fork 118
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
Nameless members on Flutter BlockBody docs #1367
Comments
I have some asserts now that catch this case in checked mode and they blow up here among many other places in flutter docs, for reasons I don't understand yet. |
Looks like a number of pages are affected by this. I just saw usability participant P3 go to a page that had half a dozen of these blank entries, and it looks embarrassing at best. :-) |
This isn't on the early adopter's milestones but is among the first issues I intend to address once those are knocked out. |
Started looking at this today and have a better idea what is going on here. There are apparently phantom elements in the analyzer tree generated under certain conditions which I'm still cataloging. One seems to be the use of assert in initializer lists, creating phantom FieldElements, and I've also seen it after the declaration of a private enum, creating a phantom TopLevelElement. These elements claim to be of type dynamic, with no name, and not synthetic. Phantom FieldElements generate the symptom you're seeing. I'll work a bit more on establishing the signature of this (fortunately, element.nameOffset seems to be useful), and file an analyzer bug. In the meantime, I can also build a warning into dartdoc for when it sees them, but suppress the documenting of these phantom fields. |
Learned more about why phantom elements are being generated; when actually generating docs, dartdoc is not obeying analysis options files. So, use of any language feature that requires an analysis option flag is likely to have poor dartdoc behavior (since the analyzer code it is depending on is misconfigured). This may well be why the asserts in initializer lists are triggering this bug. It seems likely that other language feature toggles are doing other subtly wrong things in dartdoc, too, so I'll try and get to the bottom of this. It might also explain a lot of |
This is going to be somewhat complicated. The modern analyzer generates new analysis contexts for every pubspec.yaml and .analysis_options file among other things in order to analyze code correctly. Dartdoc hardcodes one analysis context with the same options all the time, leading to this bug. I'm going to try to reuse the analyzer's ContextManager class to set up the analyzer in the same way the real one does to squish this and all similar bugs permanently. It already implements the necessary logic to be aware of all the option files, and, if I understand correctly, I really 'only' have to figure out how to glue it in here. |
Of course it is better to use shared mechanism for creating analysis contexts, that supports all features for processing options. Speaking specifically about using We should also move away from using |
dartdoc still uses |
flutter/engine#3575 causes further breakage in dartdoc for flutter because we aren't either using |
Some workarounds for this and flutter/flutter#9468 are coming up shortly that seem effective in solving both: forcing on enableAssertInitializer and manually reversing embedder links in dartdoc. PR coming up soon. |
Head now has a workaround for this. |
Check out the Properties section of:
https://docs.flutter.io/flutter/widgets/BlockBody-class.html
The text was updated successfully, but these errors were encountered: