Can't read TreeNode.location from patch files

[sigmundch]

Many nodes contain a fileoffset but no file uri. TreeNode.location searches up the tree to find the first node with a file uri (typically a member, class, or library). How does this work when using patch files?
It appears as if we use the tree node from the original library for these elements, and the body and annotations from the patch file are attached.

This is causing problems in the lookup of the location of these nodes. The offset corresponds to the patch file, but we try to look for it in the original library source instead. As a result we commonly hit "out-of-range" errors when calling TreeNode.location.

Here is a repro:

• patch https://dart-review.googlesource.com/c/sdk/+/27404
• run ./tools/build.py -m release
• run sdk/bin/dart2js --use-kernel tests/language/aborting_switch_case_test.dart

You'll see this error:

The compiler crashed: RangeError (offset): Invalid value: Not in range 0..566, inclusive: 975
#0      RangeError.checkValueInInterval (dart:core/errors.dart:267)
#1      Source.getLocation (package:kernel/ast.dart:5693:16)
#2      Program.getLocation (package:kernel/ast.dart:5487:31)
#3      _getLocationInProgram (package:kernel/ast.dart:5808:20)
#4      Procedure._getLocationInEnclosingFile (package:kernel/ast.dart:1563:12)
#5      TreeNode._getLocationInEnclosingFile (package:kernel/ast.dart:169:20)
#6      TreeNode.location (package:kernel/ast.dart:165:12)
#7      computeSourceSpanFromTreeNode (sdk/pkg/compiler/lib/src/kernel/element_map.dart:491:18)
#8      KernelToElementMapBaseMixin.getConstantValue (sdk/pkg/compiler/lib/src/kernel/element_map_mixins.dart:330:9)
#9      KernelToElementMapBaseMixin.getMetadata.<anonymous closure> (pkg/compiler/lib/src/kernel/element_map_mixins.dart:343:20)
#10     List.forEach (dart:core-patch/dart:core/array.dart:79)
#11     KernelToElementMapBaseMixin.getMetadata (sdk/pkg/compiler/lib/src/kernel/element_map_mixins.dart:342:17)
...

The failure occurs when looking for the location of the @patch annotation in printToConsole.

[peter-ahe-google]

Siggi has a workaround for this, so I'm removing the P1 status. We probably want to extend the kernel format later, so I've marked this "front-end-cleanup".

[ghost]

I'm repeatedly running into this issue (working with FfiNative, touching patch files) and the only workaround I have is to modify the transformations to remove the fileOffset from the affected nodes.

Given this issue is nearing four years old it would be nice to see if we can put this on some kind of plan to fix.

[mraleph]

/cc @johnniwinther

[johnniwinther]

It is a known deficiency of the AST that it cannot hold file offsets for different files within the same member. The remedy is to set the file offsets to TreeNode.noOffset or to that of the enclosing member (which is what CFE currently does for annotations on patched members).

[ghost]

Do we by any chance have mechanisms for detecting when we're operating over the patch versions of a node in e.g. the transformations? (Something like TreeNode.isPatch()?)

[johnniwinther]

We don't.

[johnniwinther]

For class members you could use bool isPatch(Member member) => member.fileUri != member.enclosingClass!.fileUri;.

[johnniwinther]

With https://dart-review.googlesource.com/c/sdk/+/311660 ConstantExpression now have a valid file offset.