Links to docs for clang-tidy checks use incorrect version

[bshoshany]

Environment

• OS and Version: Windows 11 23H2
• VS Code Version: 1.94.0
• C/C++ Extension Version: 1.21.6

Bug Summary and Steps to Reproduce

When using clang-tidy, diagnostic messages displayed in the problems pane contain helpful links to the check's documentation on llvm.org. However, the link is to a version that does not match the version of clang-tidy being used. I noticed this after upgrading LLVM to v19.1.0. This version introduced some new clang-tidy checks, such as use-std-min-max, which did not exist in previous versions. But the link provided by the extension is:

https://releases.llvm.org/18.1.6/tools/clang/tools/extra/docs/clang-tidy/checks/readability/use-std-min-max.html

This link does not work, because it links to the page for v18.1.6, which did not have this particular check. The correct link is:

https://releases.llvm.org/19.1.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability/use-std-min-max.html

Which does work. I'm not sure why it links to 18.1.6, because the bundled version is actually 18.1.8, but in any case I think the extension needs to do clang-tidy --version on whatever binary it's using, and then provide a link to the correct version.

Configuration and Logs

N/A

Other Extensions

No response

Additional context

No response

[bshoshany]

Update (related to issue #12806 and PR #12813): Even though the clang-tidy version is now correctly determined, the URL to the docs still has v18.1.6 hard-coded into it. You can see it here:

vscode-cpptools/Extension/src/LanguageServer/codeAnalysis.ts

Line 381 in 292d84f

const primaryDocUri: vscode.Uri = vscode.Uri.parse(`https://releases.llvm.org/18.1.6/tools/clang/tools/extra/docs/clang-tidy/${docPage}`);

So maybe the version that is determined in settings.ts should be cached and then inserted into this URL? I'm talking specifically about this function that was modified in PR #12813:

vscode-cpptools/Extension/src/LanguageServer/settings.ts

Lines 273 to 320 in 292d84f

	private getClangPath(isFormat: boolean): string | undefined {
	let path: string | undefined = changeBlankStringToUndefined(this.getAsStringOrUndefined(isFormat ? "clang_format_path" : "codeAnalysis.clangTidy.path"));
	if (!path) {
	const cachedClangPath: string | undefined = isFormat ? getCachedClangFormatPath() : getCachedClangTidyPath();
	if (cachedClangPath !== undefined) {
	return cachedClangPath;
	}
	const clangName: string = isFormat ? this.clangFormatName : this.clangTidyName;
	const setCachedClangPath: (path: string) => void = isFormat ? setCachedClangFormatPath : setCachedClangTidyPath;
	const whichPath: string | null = which.sync(clangName, { nothrow: true });
	if (whichPath === null) {
	return undefined;
	}
	path = whichPath;
	setCachedClangPath(path);
	if (!path) {
	return undefined;
	} else {
	// Attempt to invoke both our own version of clang-* to see if we can successfully execute it, and to get its version.
	let bundledVersion: string;
	try {
	const bundledPath: string = getExtensionFilePath(`./LLVM/bin/${clangName}`);
	const output: string = execSync(quote([bundledPath, '--version'])).toString();
	bundledVersion = output.match(/(\d+\.\d+\.\d+)/)?.[1] ?? "";
	if (!semver.valid(bundledVersion)) {
	return path;
	}
	} catch (e) {
	// Unable to invoke our own clang-*. Use the system installed clang-*.
	return path;
	}
	// Invoke the version on the system to compare versions. Use ours if it's more recent.
	try {
	const output: string = execSync(`"${path}" --version`).toString();
	const userVersion = output.match(/(\d+\.\d+\.\d+)/)?.[1] ?? "";
	if (semver.ltr(userVersion, bundledVersion)) {
	path = "";
	setCachedClangPath(path);
	}
	} catch (e) {
	path = "";
	setCachedClangPath(path);
	}
	}
	}
	return path;
	}

Seems like an easy enough fix, if I had time I would have just written my own PR, but this is a very busy month 😞

[sean-mcmanus]

This should be fixed by #12834 for 1.23.0.

[bshoshany]

@sean-mcmanus That's great, thanks! Although, if I understand correctly, now v19.1.0 is hard-coded into the script, so as soon as a new version (e.g. 19.2.0 or 20.1.0) is released with some new checks, the URL will be incorrect again ☹

[thernstig]

@bshoshany and @sean-mcmanus I agree this is not fixed per se. Since it is hard coded this will always be a problem.

[bshoshany]

I noticed that there are also clang-tidy documentation URLs that are version-independent (or more precisely, automatically lead to the latest version). For example, instead of:

https://releases.llvm.org/19.1.0/tools/clang/tools/extra/docs/clang-tidy/checks/misc/include-cleaner.html

We can use:

https://clang.llvm.org/extra/clang-tidy/checks/misc/include-cleaner.html

The only disadvantage of using this is that if someone is using an older version of clang-tidy, this might show some additional features that were added to the same check in newer versions but do not exist in the older version, but this is definitely better than not seeing the documentation for the check at all.

[bshoshany]

Sorry, I accidentally pressed the wrong button and closed the issue, and now I can't reopen it, can someone please reopen it? @sean-mcmanus