Merge upstream codeql-cli/latest.

[ropwareJB]

Simply merges codeql-cli/latest tag from upstream. No other changes.

In general, the fix is to replace catch (Exception) with one or more catch clauses for specific, expected exception types that are safe to handle locally, and allow other exceptions to propagate.

For this snippet, the only code in the try block is:

return new FileInfo(config).Directory?.FullName;

The likely, non‑fatal exceptions from this are:

• ArgumentException / ArgumentNullException / PathTooLongException — invalid path string.
• NotSupportedException — invalid path format (e.g., URI).
• SecurityException / UnauthorizedAccessException / IOException — problems accessing the file system.

Catching these and logging a warning preserves the intended behavior (skip problematic configs, log a warning, return null) while allowing more serious exceptions to bubble up.

The best minimal change is to replace the generic catch with a multi‑catch that targets these I/O and argument/path related exceptions. No additional methods or imports are required, since System and System.IO are already imported; the extra exception types (SecurityException, PathTooLongException) are also in System.

Concretely, in csharp/extractor/Semmle.Extraction.CSharp.DependencyFetching/NugetPackageRestorer.cs, within the lambda passed to .Select(config => { ... }), change:

catch (Exception exc)
{
    logger.LogWarning($"Failed to get directory of '{config}': {exc}");
}

to:

catch (IOException exc)
catch (UnauthorizedAccessException exc)
catch (ArgumentException exc)
catch (System.Security.SecurityException exc)
catch (PathTooLongException exc)
{
    logger.LogWarning($"Failed to get directory of '{config}': {exc}");
}

(or equivalent grouping, depending on style), keeping the rest of the method intact.

To avoid Path.Combine silently dropping earlier arguments, we should ensure that later segments passed to it are not absolute paths. The general approaches are: (1) validate and reject absolute segments, (2) normalize absolute segments into relative ones, or (3) restructure combining logic so that only the base is absolute and subsequent segments are guaranteed relative. Using Path.Join alone does not solve the “absolute later argument overrides earlier ones” behavior; both Combine and Join behave similarly in this respect, so the fix must address the arguments themselves.

For this specific method, the best minimal fix is to sanitize subfolderName locally so that if it is an absolute path, we strip it down to its final directory/file name (using Path.GetFileName) before combining. FileUtils.ComputeHash(srcDir) is already a derived hash and not an absolute path, so it is safe. This change preserves existing behavior for all relative subfolderName values (the intended use), while ensuring that even if an absolute path somehow slips through, it will no longer cause the temp directory and hash to be ignored. Concretely, in ComputeTempDirectoryPath(string srcDir, string subfolderName) (around line 941 in csharp/extractor/Semmle.Extraction.CSharp.DependencyFetching/NugetPackageRestorer.cs), introduce a local variable that normalizes subfolderName if Path.IsPathRooted(subfolderName) is true, and then use that variable in the Path.Combine call. No new imports or helper methods are required; everything is available from System.IO.

In general, the fix is to replace the bare catch with one or more typed catch clauses that only handle the exceptions we actually expect from this sequence of operations, and optionally add a final catch that rethrows unexpected exceptions rather than silently swallowing them.

The best minimally invasive fix here is:

• Catch specific, expected exceptions such as ArgumentException, InvalidOperationException, and NotSupportedException that can reasonably arise from:
  • SplitAt (index/argument errors),
  • Construct on INamedTypeSymbol,
  • LINQ First over the members.
• Optionally add a second catch (Exception) that rethrows (or logs and rethrows) to avoid hiding truly unexpected failures. However, that would change behavior by no longer falling back for all exception types.
• To avoid changing behavior, we should only handle the specific exceptions and allow everything else to propagate. This still changes behavior in edge cases (those previously swallowed), but in a safer direction and is aligned with the CodeQL recommendation while retaining the documented fallback for anticipated failures.

No new imports are needed; the exception types are in System, which is already imported at the top of the file. The only change is to the catch clause around lines 693–697 in csharp/extractor/Semmle.Extraction.CSharp/CodeAnalysisExtensions/SymbolExtensions.cs.

In general, to fix this kind of issue you replace nested if statements that lack else branches with a single if statement whose condition is the logical && of the original conditions. You must ensure there is no intervening code whose execution would be altered and that operator precedence is clear (using parentheses where necessary).

For this specific case in csharp/extractor/Semmle.Extraction.CSharp/CodeAnalysisExtensions/SymbolExtensions.cs, inside GetParameterKind(this IParameterSymbol parameter), we should combine:

if (parameter.Ordinal == 0)
{
    if (parameter.ContainingSymbol is IMethodSymbol method && method.IsExtensionMethod)
    {
        return Parameter.Kind.This;
    }
}

into a single if:

if (parameter.Ordinal == 0 &&
    parameter.ContainingSymbol is IMethodSymbol method &&
    method.IsExtensionMethod)
{
    return Parameter.Kind.This;
}

This keeps existing functionality intact: Parameter.Kind.This is returned only when the parameter is the first parameter (Ordinal == 0) and belongs to an extension method. No imports, new methods, or additional definitions are required; we only refactor the condition and block structure within the shown method.