mergeConfigurations discards custom configurations whose uri is a vscode.Uri

[owevertonguedes]

With C_Cpp.mergeConfigurations enabled, every SourceFileConfigurationItem a configuration provider returns is discarded when its uri is a vscode.Uri object rather than a string. Nothing reaches the language server, and the only trace is a discarding invalid SourceFileConfigurationItem line in the developer console.

The vscode.Uri form is the one the API documents, in the @example on SourceFileConfigurationItem.uri:

let item: SourceFileConfigurationItem = {
    uri: vscode.Uri.file(path),
    configuration: ...
};

Cause

provideCustomConfigurationAsync deep-copies the provider's configurations before merging in the entries from c_cpp_properties.json:

if (fileConfiguration?.mergeConfigurations) {
    configs = deepCopy(configs);

deepCopy is JSON.parse(JSON.stringify(obj)), and vscode.Uri declares toJSON(), so the round trip turns the Uri into a plain object. sendCustomConfigurations then validates each item with isSourceFileConfigurationItem, which accepts only a string or a real Uri:

return input && (util.isString(input.uri) || util.isUri(input.uri)) &&

isUri is input instanceof vscode.Uri. The copied value is neither, so every item is dropped, sanitized.length === 0, and the function returns before sending anything.

Result

uri	mergeConfigurations	configurations sent
string	off	all
string	on	all
vscode.Uri	off	all
vscode.Uri	on	none

Only the last row is broken, which makes it look like mergeConfigurations silently does nothing rather than like a provider problem.

I ran into this while working on #14125, which is in the same function. I have not sent a fix because there is more than one reasonable place to put it: normalize uri to a string before the copy, keep the uri out of the copy, or let isUri accept the serialized form. I am happy to send a PR if you have a preference.

[Colengms]

readonly uri: string | vscode.Uri;

normalize uri to a string before the copy

Normalizing that field to a string before the deepCopy seems like a good approach to me.

[bobbrow]

I probably would have preferred the isUri approach which would require less copying, but either way is probably fine.