microsoft / microsoft/vscode-cpptools

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

Open
#13,184 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Language Service
Dominant language
TypeScript
Stars
6.2k
Forks
1.7k
Avg merge
14h 46m
Merged PRs (30d)
61

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the is_valid_file, is_supported_file, and is_file_supported entry points, including the ftf_compiled, ftf_header, and ftf_idl checks. Compare their handling of files.assocations entries with hard-coded extensions, then determine whether the chosen behavior should treat unhandled associated files as source files or require a new setting for source/header distinctions.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, vscode
Domain
tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.