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`

Aperta
  • Qualcosa non va?
#23,009 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
47/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
compilers, testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
CodeQL
Stelle
10.3k
Fork
2.1k
Merge medio
2g 6h
PR unite (30g)
137

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di github/codeql

Tutte le issue di github/codeql

Issue simili

Altre issue su Compilers

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.