Exception running scripts that use macros that aren't inside a sub-folder of the project

[DanTup]

If I try to run a script that uses macros (using --enable-experiment=macros), it works fine if that file is inside a sub-folder of my project (for example bin, but it can be named anything). However if I move the script up to the root of the project (so it's not in a sub-folder), then it fails to run with the following:

(I've no idea where the a/b/c is coming from - my file is at C:\Users\danny\AppData\Local\Temp\dart-sdk-dap-testddefb7ae\appcb61c3a4\test_file.dart and importing C:\Users\danny\AppData\Local\Temp\dart-sdk-dap-testddefb7ae\appcb61c3a4\with_hello.dart which contains the macro impl)

Error: Exception when reading 'org-dartlang-macro:///a/b/c/.dart_tool/package_config.json': FileSystemException(uri=org-dartlang-macro:///a/b/c/.dart_tool/package_config.json; message=StandardFileSystem only supports file:* and data:* URIs)
../../runtime/vm/dart_api_impl.cc: 6212: error: An error occurred in the CFE while acking the most recent compilation results: Crash when compiling org-dartlang-macro:///a/b/c/main.dart:
Invalid argument(s): Exception when reading 'org-dartlang-macro:///a/b/c/.dart_tool/package_config.json': FileSystemException(uri=org-dartlang-macro:///a/b/c/.dart_tool/package_config.json; message=StandardFileSystem only supports file:* and data:* URIs)

#0      ProcessedOptions._findPackages.checkInDir (package:front_end/src/base/processed_options.dart:687:9)
<asynchronous suspension>
#1      ProcessedOptions._findPackages (package:front_end/src/base/processed_options.dart:692:22)
<asynchronous suspension>
#2      ProcessedOptions._getPackages (package:front_end/src/base/processed_options.dart:572:24)
<asynchronous suspension>
#3      ProcessedOptions.getUriTranslator (package:front_end/src/base/processed_options.dart:496:32)
<asynchronous suspension>
#4      generateKernelInternal.<anonymous closure> (package:front_end/src/kernel_generator_impl.dart:74:37)
<asynchronous suspension>
#5      withCrashReporting (package:front_end/src/fasta/crash.dart:133:12)
<asynchronous suspension>
#6      kernelForProgramInternal.<anonymous closure> (package:front_end/src/api_prototype/kernel_generator.dart:65:29)
<asynchronous suspension>
#7      CompilerContext.clear (package:front_end/src/fasta/compiler_context.dart:139:3)
<asynchronous suspension>
#8      kernelForProgramInternal (package:front_end/src/api_prototype/kernel_generator.dart:64:10)
<asynchronous suspension>
#9      _compileMacros (package:front_end/src/kernel_generator_impl.dart:359:7)
<asynchronous suspension>
#10     precompileMacros (package:front_end/src/kernel_generator_impl.dart:312:16)
<asynchronous suspension>
#11     IncrementalCompiler.computeDelta.<anonymous closure> (package:front_end/src/fasta/incremental_compiler.dart:345:15)
<asynchronous suspension>
#12     CompilerContext.clear (package:front_end/src/fasta/compiler_context.dart:139:3)
<asynchronous suspension>
#13     IncrementalCompiler.reject (package:vm/incremental_compiler.dart:194:5)
<asynchronous suspension>
#14     _processLoadRequest (file:///C:/b/s/w/ir/x/w/sdk/pkg/vm/bin/kernel_service.dart:852:11)
<asynchronous suspension>

version=3.4.0-edge.94e653fe0e26d5a4fd4b905517ec38d0b44d122e (main) (Tue Feb 27 08:07:00 2024 +0000) on "windows_x64"
pid=3936, thread=11364, isolate_group=main(0000016826AA9BA0), isolate=main(0000016826AB6320)
os=windows, arch=x64, comp=no, sim=no
isolate_instructions=7ff7f2b470c0, vm_instructions=7ff7f2b470d0
fp=324c8ff288, sp=324c8ff288, pc=7ff7f2d46982
  pc 0x00007ff7f2d46982 fp 0x000000324c8ff288 Dart_IsPrecompiledRuntime+0x215032
-- End of DumpStackTrace


Exited (-1073740791).

[davidmorgan]

Thanks!

Normally if you don't specify an explicit package_config.json the CFE goes looking for one. When it finds it, it uses that same one for the macro build.

What's happening is that because the script is in the wrong place it doesn't find package_config.json, which means the macro build goes looking for it again. But macros exist in a weird place, org-dartlang-macro:///a/b/c/, and searching for package_config.json there throws. (Yes, a/b/c is the hardcoded location where the internal macro files end up).

I'll see if I can fix this edge case :)