-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[dart:js_interop] Unhelpful error message about what types are allowed when trying to use static interop #54320
Comments
You're right that In terms of reporting, it's a bit complex to do better. Currently, we report the error on the node in which the error occurred in (the call to
We may be able to do better by rewording the error to explicitly refer to either the return type or the parameter type to which it corresponds. For parameters, we can't use the name because of issue #2, but we may be able to use the position in the type to make it easier e.g. |
Thanks @srujzs , it would be great to resolve this because currently I get this error quite often and need to binary-search the file to find the problematic line. Btw, what is the location |
I think there's something off about the location information or the way it's displayed. Here's where we report the info:
node is a StaticInvocation that comes from here:
|
Interesting, the Error reporting from the CFE (and similarly from dart2js) starts with offsets and converts them to line/column positions if the source-file contents are available during that step of the compilation process. That also is necessary to display context with the error message (e.g. the text snippet with an underlined squiggle line). The setup may depend on what compiler is being invoked in order to run the JSInterop transformer. @annagrin - what are the commands you use to compile |
@srujzs @sigmundch I build using dart build+build_web_compilers with dart2js. I do not see those errors on VSCode as they only show during the actual build and not in the analyzer. You can try it out by running Actually, other CFE errors report twice and the second report has the same problem, for example, if I make a syntax error:
Btw looks like the first error is reported by the built value generator, before the actual build (to generate classes and serializers we use in network comunications), and the second one by the actual build with dart2js. |
I believe the byte offset printing comes from here. |
Yes Dart2JS will emit this offset format when the CFE does not register the source code for a file. Normally the CFE will call a hook in Dart2JS with the URI and the associated source code: We have a flag to disable registering those URIs (to save memory by not having all the source code in memory) but that should be disabled by default. So I would guess that the CFE is filtering out the source bytes for that package for some reason... perhaps if its bundled as part of the SDK. |
This seems to be directly related to the use of the For example, take this program: repro.dart: import 'dart:js_interop';
main() {
((a, int b) {}).toJS;
} The reported error changes depending on how we invoke dart2js:
In constast:
Note that our alternative approach with
@srujzs - I agree. In terms of error reporting, I think we can be more precise and guide users a bit better (as you suggest, at least by pointing them to the right argument/return type depending on the scenario.) |
@biggs0125 - I looked more closely at the discrepancy, and it's sort of by accident that this works with bazel-paths. Our recent changes to the caching logic made it so that we don't prime the cache until after we are done with the CFE phase (in load-kernel). However, here the diagnostic is being produced before that point in time, during a transformer that is running in the middle of the CFE phase. Some options to consider: Re (d), I wonder if other regular CFE diagnostics are broken too, if they are not, then this may be a specific issue of how transformers are directing diagnostics directly through dart2js and not through the CFE. If however we are using the same diagnostics, it's possible that regular CFE errors are also impaired. In that case, we should probably look into (b). |
I am migrating DWDS injected client code to
package:web
. I've encountered a cryptic error message on one of the changes:Old code
New code
Expected
Some information on error location and nature, and ideally on how to fix it.
Actual
(note that line 8916 does not exist
client.dart
)The text was updated successfully, but these errors were encountered: