Utilities like parsing `use` (import) statements? (e.g. use something inside Rust codebase?)

help
1

Hi, thanks for the great language! When developing GitHub - fzyzcjy/flutter_rust_bridge: Flutter/Dart <-> Rust binding generator, feature-rich, but seamless and simple., I need to understand the imports in order to avoid name conflicts. For example, users may write down struct MyStruct {...} on both a.rs and b.rs, and flutter_rust_bridge needs to differentiate between the two when user writes down something like use a::*; let x: MyStruct.

I guess this must have been implemented inside the Rust compiler - otherwise it is surely impossible to compile Rust code. Therefore, to avoid duplicating the code (the DRY principle), I hope to somehow reuse existing code, instead of looking at spec and write down a parsing logic by myself. I would appreciate it if I could know whether this is possible or suggested? Thanks!

2

This is not a question of parsing, but one of name resolution. Parsing means turning a flat representation (in the case of programming languages, a string that is the source code) into a structured one (a so-called abstract syntax tree or AST). Parsing is context-independent and doesn't add information – the AST doesn't contain any more information than the source code did, it's "only" vastly easier and more practical to work with.

What you are looking for is more than mere parsing; it already involves an early stage of type checking, i.e., mapping the context-sensitive source code into entities that don't require further name lookup, so basically this adds information about the relationship between modules and crates.

The compiler has related logic at least in this crate.

1 Like
3

I see, thank you very much for the explanations!

That crate looks complicated, and seems not to be used by end users (e.g. not on crates.io: Rust Package Registry). Therefore, do you suggest me to manually write down code to resolve it, or to call that code?

4

I have no strong opinion about that, as I haven't tried doing either.

My guess would be that re-implementing Rust's complete name resolution algorithm from scratch, and doing so correctly, would be more of a challenge than figuring out how to use a crate.

Cargo can handle direct Git dependencies.

1 Like
5

As an alternative you could consider trying to hook into rust-analyzer (this part should be handled by the hir-def crate). In any case you'll need something that handles macro expansion and name resolution, be it an existing crate or your own. I don't think it will be easy to write by yourself, but integrating with an existing create may also be pretty challenging.

1 Like
6

@paramagnetic @SkiFire13 Thank you!

trying to hook into rust-analyzer

Could you please explain a bit more? I searched "rust hook" and do not get much results.

In any case you'll need something that handles macro expansion and name resolution, be it an existing crate or your own.

About macro expansion, I use the GitHub - dtolnay/cargo-expand: Subcommand to show result of macro expansion which works pretty well.

EDIT: Oh I see, cargo expand is indeed rustc -Zunpretty=expanded. Then, is it possible to have something similar to that, but does a name resolution?

7

Ah I see: seems -Zunpretty has some interesting variants! I quickly checked some of them, e.g. expanded,hygiene looks interesting (but does not fully solve the question...).

8

It wasn't nothing technical, I just meant to use rust-analyzer's crate.

That won't always work correctly as it's lossy around hygiene. Consider for example this code:

macro_rules! foo {
    ($i:ident) => {
        let a = 10;
        println!("{}", $i);
    }
}

fn main() {
    let a = 5;
    foo!(a); // prints 5
}

If you expand it you'll get the equivalent of this:

fn main() {
    let a = 5;
    let a = 10;

    println!("{}", a); // now prints 10
}

The problem is that the two as are different identifiers for the compiler due to having different syntax context, even though their name is the same. Once expanded the syntax context is lost and they compare equal.

-Zunpretty=expanded,hygiene handles the hygiene problem and may give you enough informations to recover the name resolution informations, however note that there's nothing guaranteeing it will continue to have this output format.

1 Like
9

@SkiFire13 Thank you!

To be more specific, I only care about types on signatures - function input argument types, function output types, struct field types, enum field types, etc, but do not care about function body code.

I checked -Zunpretty=expanded,hygiene, but in some cases, it does not seem to produce enough information in some cases either. For example,

use std::result::*;

fn main() -> Result<(), ()> {
    panic!()
}

gives something like

rustc +nightly -Zunpretty=expanded,hygiene src/main.rs
#![feature /* 767#0 */(prelude_import)]
#![no_std /* 1195#0 */]
#[prelude_import /* 1323#1 */]
use ::std /* 1696#1 */::prelude /* 1322#1 */::rust_2015 /* 1459#1 */::*;
#[macro_use /* 1034#1 */]
extern crate std /* 1696#2 */;
use std /* 1696#0 */::result /* 1433#0 */::*;

fn main /* 1037#0 */() -> Result /* 225#0 */<(), ()> {
    {
        ::std /* 2#7 */::rt /* 1456#7 */::begin_panic /* 391#7
                */("explicit panic")
    }
}
...

and the Result type does not give any more information.

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.