-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finalize 'active' configuration subset split #234
Finalize 'active' configuration subset split #234
Conversation
42a6bf5
to
3beb92b
Compare
* Changes - Move missing 'input' configuration parameters to the ~CurrentConf~ - Added documentation for most of the configuration variables like ~git.url~, ~doc.item~, ~<module>.always~, module search logic - Add tests for the CLI parser. - Add ~[FileIndex]~ implementation for the ~ConfigRef~ to avoid constantly writing ~conf.m.fileInfos[index.int32]~ as if we don't have templates/procedures to take care of repetitive code. - Closes nim-works#210 - it is hardly possible to gain anything by refactoring this part of the compiler. I updated documentation on some of the relevant pieces I found, as well as some minor tests, but otherwise there is nothing to gain here. Current implementation is usable for the purposes of nim-works#211 - it is possible to call into ~parseCommand()~ and get self-contained chunk of data for all the flags, that we can also do roundtrips on (using nim-works#213). * Tried to do but failed Due to large number of dependencies between data storage, reporting etc. it was not possible to really separate CLI parser logic from everything else. I tried separating them out into standalone files, but it was a lot more troubles than it worth: - Moving CLI parser would've require separating 'external' reports into different file, but this would still pull in ~ast_types.nim~, which is a pretty large dependency on its own. - CLI parser can do external reports - but it is possible to have multiple failures before processing terminates if there is a ~--errormax=N~ before. So logical idea of - "CLI flag is either valid or invalid" does not really cut here, since "invalid" can be postponed. - Because there is still a need to drag around whole suite of configuration state, reporting "deprecated" warnings can stay as it is now.
3beb92b
to
7084ad6
Compare
|
||
let csd = currentSourcePath().parentDir() | ||
|
||
suite "Path options specification": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anecdote/Tangent:
This sort of testing is an important step forward, pretty early when I started working on nimsuggest
I was told about findNimProjectFile
or some proc like that. Anyhow, the intention was detecting a project file so the vscode extension can infer things in a better way than having to specify a config.
Long story short, findNimProjectFile
is busted and the whole thing is buggy as well. It really needs a spec and this test case shows a pretty good way of how I can now enumerate that.
So at the time I didn't have a great way of testing it and no one was a fan of adding these sort of tests to the compiler so I ended up dropping it. This PR reminded me of that, so now at least there is a way forward. 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r+
Build succeeded: |
Due to how this thing is implemented, it is hardly possible to separate the mutation part from everything else. So I ended up just writing more documentation and some tests for these parts.