-
-
Notifications
You must be signed in to change notification settings - Fork 698
Add VS Code IntelliSense support scaffolding #40
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
Conversation
You can now use cosmopolitan.h with an ANSI C89 compiler like MSVC. The Cosmopolitan codebase itself won't support being compiled that way. But you can build objects that link against Cosmopolitan using any compiler and you can furthermore use tools like IntelliSense that can't even GNU See also #40
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.
I'm surprised by how well VSCode works with the Cosmopolitan codebase.
Could you please sync to HEAD and then attempt replacing the contents of vscode.h
with the following:
#define __VSCODE_INTELLISENSE__ 1
#define __LP64__ /* TODO: this is a lazy kludge */
#include "libc/integral/normalize.inc"
See also a8d7195 where I've verified all public headers are ANSI C89 compliant. We can make the internal headers that way too. But I'd first ask if it's possible to configure VSCode so that it uses something like Clang?
.vscode/vscode.h
Outdated
#define __FLT_MAX__ 1 | ||
#define __DBL_MAX__ 1 | ||
|
||
#define __INT_LEAST8_TYPE__ signed char; |
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.
Is this intentional? You mentioned semicolon with macros before. I don't understand what this does.
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.
Sorry, that was an accident. I was fairly hasty with a lot of these as there were so many files to trudge through. I’ll fix it along with the other things.
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.
No reason to apologize. That's what code review is for.
I'm really happy with this change, since it's going to go a long way towards helping us attract developers. I want Cosmo to have the best VSCode support possible and I'm committed to maintaining it. I hope the edits earlier today are of assistance.
Oh see also 4608579 since I forgot to squash that into the commit I mentioned earlier. |
Seems to work just as well to me. It’s worth pointing out that the JSON has a lot of the other |
Your last commit says WIP but I don't see any reason why we can't merge now. Thank you for your contribution! I'm happy to review any other changes you send. Let me know when you feel the VSCode support is good enough that we can announce it in the 0.2 release notes. |
This PR adds VS Code IntelliSense support to the Cosmopolitan repository. It does this with as little source modifications as possible through two mechanisms: a file
.vscode/c_cpp_properties.json
interpreted by VS Code, and a file.vscode/vscode.h
which is force-#include
d by VS Code as per the JSON file’s request ahead of any source file processing.The objective here is to make IntelliSense work as smoothly as possible, ideally with no errors anywhere in source at all. I categorically excluded
third_party/
and was unable to work around thetest/
suite, but everything else has been checked manually, file-by-file, by me and I have added a great many#define
s andtypedef
s to essentially dummy out a lot of things that confound IntelliSense, which it often doesn’t need to know about anyway.The most substantive changes to the source code as I recall are a handful of instances where I added in
#ifdef
guards around a peculiar macro, so that it could be pre-emptively#define
d to some benign stub beforehand in the.vscode/vscode.h
file. This shouldn’t affect compilation at all, and before I#define
d it IntelliSense showed it was not already, so yeah.The other substantive change I have needed to make, albeit only in a couple places so far, is the un-nesting of
struct
definitions in cases where their names are re-used elsewhere. I also had to do this with oneenum FdKind
, which I noticed you had touched in my re-sync before opening this PR today @jart. I hope it is not an inconvenience to keep namedenum
s andstruct
s flat in header files.There are a lot of other strange macros for compiler intrinsics and other stuff that I have gotten as ugly as I need to in the IntelliSense header to work around. The only one I wasn’t able to overcome was the vector extension intrinsics, due to a syntactical flexibility they have that IntelliSense needs to be able to comprehend. For that I opened Issue 6890 in the C/C++ IntelliSense repository.
I would like to be able to be assigned or notified for any future issues people open here regarding IntelliSense, since I know @jart is a loyal Emacs user and will not be solving those without switching. I would also recommend a tag for those things, given they are important but also peripheral. Just let me know what I can do.