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`

Abierto
  • ¿Algo no está bien?
#23,009 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
47/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
compilers, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
CodeQL
Estrellas
10.3k
Forks
2.1k
Merge medio
2 d 6 h
PR fusionados (30 d)
137

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/codeql

Todos los issues de github/codeql

Issues similares

Más issues de Compilers

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.