Open jakemac53 opened 4 months ago
In phase 1+2 augmentation libraries the omitted types are generated as OmittedType1
, OmittedType2
, etc and replaced with the inferred type in phase 3 and merged augmentation libraries. I think we assert or throw if the type isn't inferred.
Ok, so you do expect to get the actual OmittedTypeAnnotation
back? I could just update the Code API docs to say that these are also valid.
The OmittedTypeAnnotation
is a valid value. We should though always be able to generate the actual type in phase 3 (we even have an assert for this).
Do you see this is in the merged augmentation library?
I haven't seen any actual issues with this to be clear, I was just surprised to see the actual type annotations. All Code
objects have a list of parts, which are documented as being only Identifier
, String
, and Code
. But it does make sense that these are allowed, so I will just update the docs that they can also be OmittedTypeAnnotation
s.
Fwiw I actually ran into this because of an extension I had written on code objects, to emit a debug string, which didn't handle OmittedTypeAnnotation objects, so it fell back on toString()
.
Today, it ends up putting the
OmittedTypeAnnotation
directly into the code.We could keep that, and possibly just change the
toString()
ofOmittedTypeAnnotation
, but that seems a bit weird.In https://dart-review.googlesource.com/c/sdk/+/365960/1 I tried to change the code object to just the string
<omitted>
, but that broke various tests - it looks like we are actually putting in the inferred type eventually through some magic smarts, at least in some scenarios. But, I don't really understand the mechanisms at play here.cc @johnniwinther