LLVM_ENABLE_RUNTIMES: Failed to parse {json_file}: {e}

[Meinersbur]

In certain situations when build the runtimes, the following soft error appears:

[ 56%/2.891s :: 4->31->45 (of 79)] Generating /home/meinersbur/build/llvm-project-flangrt/release_bootstrap/compile_commands.json
Failed to parse {json_file}: {e}
Failed to parse {json_file}: {e}

This happens during merging the stage1 compile_commands.json with the runtimes's compile_commands.json introduced in #116303. For instance, when one of the compile_commands.json is deleted.

I strongly suggest to not mess with the CMake-generated compile_commands.json.

First, the rule depends on its own output, potentially creating a dependency loop that will always re-run the command. Ninja seems to have a protection mechanism for the, but Make does not. When the command is run repeatedly, it will append compile_commands.json each time making the file grow and grow.

Second, compile_commands.json is created during the CMake configure phase, but the append rule runs at the build phase, and only when running the all target. That is, one gets inconcistent views of the file.

Third, the file may not exist for various reasons, for instance after make clean. It is only implemented for the Makefile and Ninja generator and will be missing for other generators. There might be more cases that I could not reproduce.

[jhuber6]

Removed the print in 2072ec1.

First, the rule depends on its own output, potentially creating a dependency loop that will always re-run the command. Ninja seems to have a protection mechanism for the, but Make does not. When the command is run repeatedly, it will append compile_commands.json each time making the file grow and grow.

The Python script sorts and strips duplicate entries, worst thing that happens is you waste some time.

Second, compile_commands.json is created during the CMake configure phase, but the append rule runs at the build phase, and only when running the all target. That is, one gets inconcistent views of the file.

I don't think it's that big of a deal, but if it's really problematic we could put this version somewhere else and let users control when to replace theirs. Frankly I got tired of manually doing this after having done it at least 50 times to be able to develop the runtimes projects.

Third, the file may not exist for various reasons, for instance after make clean. It is only implemented for the Makefile and Ninja generator and will be missing for other generators. There might be more cases that I could not reproduce.

This is why the commands have dependencies that simply TOUCH the file.

[jhuber6]

Should we keep this open now that the error is silent?