Skip to content
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

Associations added using files.assocations lack sufficient information to distinguish between source files and header files. #13184

Open
Colengms opened this issue Jan 23, 2025 · 0 comments

Comments

@Colengms
Copy link
Contributor

Colengms commented Jan 23, 2025

VS Code has files.assocations, which allows file extensions/names to be associated with languages. We check that, to see if a file is C, C++, CUDA, or none of the above (falling back to hard-coded associations, using is_file_supported). However, VS Code doesn't provide a setting for distinguishing between source files and header files (as that's not a universal concept). Whenever we need to make that distinction, we leverage the VC common is_valid_file, with flags indicating whether we're checking for source or header - usually ftf_compiled vs ftf_header (with some additional checks for ftf_idl, which may not be needed. We associate .idl with C++, but I'm not sure if that's valid).

We've probably got some existing bugs related to is_valid_file not considering extensions/names added by files.assocation.

One thing we could do is, if is_valid_file fails but is_supported_file succeeds, we could default to considering the file a source file (not a header). If a file had previously passed is_supported_file, perhaps all checks for ftf_compiled could be changed to !ftf_header, to entire the 'neither' case is always considered a source file.

Another approach might be to add some hook in is_valid_file that falls back to is_supported_file for any unhandled (not hard-coded) extensions, and assume they're source files (not headers). That way, is_valid_file can at least return success for those instead of dropping them entirely.

Ultimately, if we want to be able to distinguish between non-standard source and header extensions, we will need a new setting for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

1 participant