Schottkyc137 / ginko

A device-tree source parser, analyzer and language server.
MIT License
9 stars 4 forks source link

Include directive with angle brackets cause syntax errors #11

Open AmateurECE opened 3 months ago

AmateurECE commented 3 months ago

In the same vein as #10, #include directives with angle brackets appear to cause syntax errors, but these appear all over the kernel to refer to symbols commonly used in device tree bindings. This file:

/dts-v1/;

#include <dt-bindings/input/linux-event-codes.h>

/ {};

Produces this diagnostic:

Diagnostic { kind: Expected, span: Span { start: 2:9, end: 2:10 }, source: "inline source", message: "Expected string" }

If the included file exists at $PWD/dt-bindings/input/linux-event-codes.h, I can compile this device tree file using gcc -E -P -x assembler-with-cpp -I$PWD -o test.dtsi test.dts && dtc -o test.dtb test.dtsi.

This perhaps brings up a related question--how should users configure ginko_ls? Presumably, I as a user want to be able to inform ginko_ls about the "system include" paths on a per-project basis. For clangd, this can be done with a .clangd file.

Schottkyc137 commented 3 months ago

Thanks for your interest in this project!

in general, C-style preprocessor directives (such as #include or #define) are not supported at the moment. This is because initially, I only want to get the pure device-tree language correct and design a language server for that. But supporting such directives are definitely one of the next challenges I want to tackle. Given that this is just a hoby project and I have some other open-source stuff I want to attend, I cannot make any guarantees concerning timing though.

Concerning the related configuration question; currently I see two options: 1) Through the command line (i.e., ginko <files>): Just use options, i.e., ginko foo.dts -I/usr/lib/.... 2) When used within a language server. In this case, I would use the builtin options the language server protocol enables to pass configuration options.

But some configuration file might also be worth exploring, maybe also looking into the future to have more control over emitted diagnostics or lints.

I very much appreciate any help, but enabling C-style includes is certainly a pretty big change.