Skip to content

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

Merged
merged 5 commits into from
Feb 4, 2021
Merged

Conversation

nicholatian
Copy link
Contributor

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-#included 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 the test/ suite, but everything else has been checked manually, file-by-file, by me and I have added a great many #defines and typedefs 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 #defined to some benign stub beforehand in the .vscode/vscode.h file. This shouldn’t affect compilation at all, and before I #defined 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 one enum 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 named enums and structs 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.

jart added a commit that referenced this pull request Feb 4, 2021
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
Copy link
Owner

@jart jart left a 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;
Copy link
Owner

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.

Copy link
Contributor Author

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.

Copy link
Owner

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.

@jart
Copy link
Owner

jart commented Feb 4, 2021

Oh see also 4608579 since I forgot to squash that into the commit I mentioned earlier.

@jart jart self-assigned this Feb 4, 2021
@jart jart added the vscode label Feb 4, 2021
@nicholatian
Copy link
Contributor Author

Seems to work just as well to me. It’s worth pointing out that the JSON has a lot of the other #defines, usually function decorators, continuing to make this work.

@jart jart merged commit 888cfa7 into jart:master Feb 4, 2021
@jart
Copy link
Owner

jart commented Feb 4, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants