You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Technically, a custom configuration provider could manage multiple subprojects within the same workspace, use multiple different compilers to build sources within the same project, or even build some files in the project with different sets of args that influence the include paths returned from the compiler.
Perhaps instead of applying this change to these fields in WorkspaceBrowseConfiguration, specifically, it should instead have an array of compilerPath/compilerArgs pairs, to allow all such combinations to be queried for include paths.
Perhaps instead of applying this change to these fields in WorkspaceBrowseConfiguration, specifically, it should instead have an array of compilerPath/compilerArgs pairs, to allow all such combinations to be queried for include paths.
Let's not do this until/unless it becomes a scenario our customers explicitly ask for. My opinion is that what most developers need is a pointer to *any* implementation of the STL so that auto-complete will work for them. I don't expect them to need N copies of compiler-specific implementations.
Related to: microsoft/vscode-cpptools#9266
Opening this to track updating
compilerPath
,compilerArgs
, andcompilerFragments
fields to allow separate values to be provided for C vs. C++.The text was updated successfully, but these errors were encountered: