Rust: modules declared in a file brought in by `include!` are not resolved (no canonical paths, unresolved calls), e.g. in `windows-sys` and `windows`

Ouverte
  • Quelque chose ne va pas ?
#23,009 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
47/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
compilers, testing-qa

Piste de recherche

Start with text_range_for_node in rust/extractor/src/translate/base.rs and modImport0 in codeql/rust/internal/PathResolution.qll; compare how the included tree/mod.rs and its inner module are extracted with the normally declared direct module. Reproduce with the supplied two-crate workspace and query, then check that hidden and hidden_extern receive canonical paths and their calls resolve like the control module.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Description of the issue

When a crate's lib.rs brings in part of its module tree with include!("tree/mod.rs"), and that file declares pub mod inner;, CodeQL looks for inner next to lib.rs instead of next to tree/mod.rs, where rustc finds it. As a result, nothing in inner gets a canonical path, calls into it have no getStaticTarget(), and models-as-data rows for its functions never apply.

The public windows-sys and windows crates are built this way (lib.rs contains include!("Windows/mod.rs")), so Windows API calls made through them are never resolved:

  • windows-sys 0.61.2: 0 of the 10,661 functions under src/Windows/Win32 have a canonical path.
  • windows 0.62.2: 777 of 130,113 do (with codeql/rust-all 0.2.25); CreateFileW is not among them.
  • Calls to CreateFileW, ReadFile, RegQueryValueExW, CreateProcessW, ShellExecuteW and recv through windows-sys, and to the first four through windows, are unresolved.

Seen with CodeQL 2.27.2 (codeql/rust-all 0.2.23) and 2.27.4 (codeql/rust-all 0.2.25), Rust 1.99.0, Windows x64. Setting extract_dependencies_as_source=true does not change it.

Reproduction

A two-crate workspace. toy-include brings in module inner through include!; module direct, declared normally, has the same contents and serves as a control.

Cargo.toml

[workspace]
members = ["toy-include", "toy-user"]
resolver = "2"

toy-include/Cargo.toml

[package]
name = "toy-include"
version = "0.1.0"
edition = "2021"

toy-include/src/lib.rs

macro_rules! declare {
    ($name:ident) => {
        extern "C" {
            pub fn $name() -> u32;
        }
    };
}

include!("tree/mod.rs");

pub mod direct;

toy-include/src/tree/mod.rs

pub mod inner;

toy-include/src/tree/inner/mod.rs

pub fn hidden() -> u32 {
    1
}

declare!(hidden_extern);

toy-include/src/direct.rs

pub fn visible() -> u32 {
    2
}

declare!(visible_extern);

toy-user/Cargo.toml

[package]
name = "toy-user"
version = "0.1.0"
edition = "2021"

[dependencies]
toy-include = { path = "../toy-include" }

toy-user/src/main.rs

fn main() {
    let a = toy_include::inner::hidden();
    let b = toy_include::direct::visible();
    let c = unsafe { toy_include::inner::hidden_extern() };
    let d = unsafe { toy_include::direct::visible_extern() };
    println!("{}", a + b + c + d);
}

The workspace builds with cargo check. Query (query/qlpack.yml depends on codeql/rust-all: "*"):

query/include-paths.ql

import rust

/** Each function of the `toy-include` crate, with its canonical path (none if CodeQL gives none). */
query predicate functions(string file, string name, string canonicalPath) {
  exists(Function f |
    f.getFile().getAbsolutePath().matches("%toy-include%") and
    file = f.getFile().getAbsolutePath().regexpCapture(".*toy-include[/\\\\]src[/\\\\](.*)", 1) and
    name = f.getName().getText() and
    if exists(f.getCanonicalPath()) then canonicalPath = f.getCanonicalPath() else canonicalPath = "(none)"
  )
}

/** Each call in the program, with the function it resolves to (none if unresolved). */
query predicate calls(int line, string call, string target) {
  exists(Call c | c.getFile().getBaseName() = "main.rs" |
    line = c.getLocation().getStartLine() and
    call = c.toString() and
    if exists(c.getStaticTarget())
    then target = c.getStaticTarget().getCanonicalPath()
    else target = "(unresolved)"
  )
}

select 1

Run:

codeql database create db --language=rust --source-root=.
codeql query run query/include-paths.ql --database=db --output=out.bqrs
codeql bqrs decode out.bqrs --format=csv --result-set=functions
codeql bqrs decode out.bqrs --format=csv --result-set=calls

Expected: hidden and hidden_extern have the canonical paths toy_include::inner::hidden and toy_include::inner::hidden_extern, and the calls on lines 2 and 4 resolve to them, like the control module's.

Actual:

"file","name","canonicalPath"
"direct.rs","visible","toy_include::direct::visible"
"direct.rs","visible_extern","toy_include::direct::visible_extern"
"tree/inner/mod.rs","hidden","(none)"
"tree/inner/mod.rs","hidden_extern","(none)"

"line","call","target"
2,"...::hidden(...)","(unresolved)"
3,"...::visible(...)","toy_include::direct::visible"
4,"...::hidden_extern(...)","(unresolved)"
5,"...::visible_extern(...)","toy_include::direct::visible_extern"

Likely cause

  • In the extractor, text_range_for_node (rust/extractor/src/translate/base.rs) keeps a node's location only if it maps into the file being extracted. Nodes produced by an include! map into the included file, so the inner module in the expansion reports lib.rs as its file.
  • modImport0 in codeql/rust/internal/PathResolution.qll then looks for mod inner; relative to lib.rs (src/inner.rs, src/inner/mod.rs) instead of src/tree/.
  • tree/mod.rs is also extracted on its own, and there mod inner; does resolve, but that copy is not part of the crate's module tree.

A possible fix: have the extractor give include!d nodes their locations in the included file (or record which file each include! includes), so that mod files are looked up next to the file that declares them.

Langage dominant
CodeQL
Étoiles
10.3k
Forks
2.1k
Merge moyen
2 j 6 h
PR mergées (30 j)
137

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de github/codeql

Toutes les issues de github/codeql

Issues similaires

Plus d'issues Compilers

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.