Closed ReeceHumphreys closed 10 months ago
After thinking about it more, I don't see the value in having separate config for "reference directories" and "source directory". We don't need a distinction between source and reference files.
I think it would be easier for users and for us to just have a single config for search paths
(probably with a better name).
It stores a Vec<String>
and we pass those into slicec
as the reference files/directories.
After thinking about it more, I don't see the value in having separate config for "reference directories" and "source directory". We don't need a distinction between source and reference files.
Not sure, even if internally we use both for setting the reference paths passed to the compiler, conceptually there is a clear distinction. I think that there would be room for distinction of things that apply to files that are part of the project, and files that are just references.
After thinking about it more, I don't see the value in having separate config for "reference directories" and "source directory". We don't need a distinction between source and reference files.
Not sure, even if internally we use both for setting the reference paths passed to the compiler, conceptually there is a clear distinction. I think that there would be room for distinction of things that apply to files that are part of the project, and files that are just references.
When generating code, we need to distinguish between source files (for which we generate code) and reference files (for which we don't). Here, we don't generate any code, so what's the logic for this source vs reference distinction?
Instead of releasing last week, I think Joe and Jose were right that it could use a bit more testing. Was able to fix a few more bugs plus add support for reference files. The only thing I was not able to address was jumping to type alias definitions. This is going to end up requiring some updates to slicec.