Skip to content
This repository has been archived by the owner on Dec 14, 2021. It is now read-only.

Support for Rust #16

Open
Champii opened this issue Nov 20, 2019 · 8 comments
Open

Support for Rust #16

Champii opened this issue Nov 20, 2019 · 8 comments

Comments

@Champii
Copy link

Champii commented Nov 20, 2019

Hello !

I've started the work concerning the rust bindings of SourcetrailDB. It is a (very) early (and non yet working) version of those, made with rust-bindgen.

You can see the progress and contribute at https://github.com/Champii/SourcetrailDB/tree/master/resources_rust

The current approach is to use rust-bindgen directly on the generated static library, but that may be inefficient as rust-bindgen does not handle std types well (std::string for example). Their doc recommend to generate them all as opaque types, but then we lose the ability to use them.

One of the possible workaround is to create a C ABI to interface the C++ code with Rust, or to try the method used by the python bindings and wrap the most commonly used features in a lightweight and thus Rust-friendly C++ library.

I'll try them both and consider the one that fit the most.

Feel free to share your point of view on the matter, and/or throw some suggestions on the best way to handle that !

If I can be of any help, I'd be glad to :)

@astrolemonade
Copy link

How do you manage to represent lifetimes or variable shadowing in Sourcetrail?

@egraether
Copy link
Contributor

@cata0309 We don't.

  • Variables in global or class scope are stored as symboland must have a unique name. They show up in the graph.
  • Variables in function scope are stored as local_symbol and must have a unique name as well, but that name is not displayed anywhere. So you can shadow a variable by supplying a different name, e.g. by adding the location of first declaration to it's name: var_a<5:2> and var_a<10:6>.

@astrolemonade
Copy link

astrolemonade commented Nov 20, 2019

In Rust lang you can do something like this

//Immutable by default
let x=16;
//But you can change its value and also its type with shadowing 
let x=vec![3.4,4.5];

How would you represent the variable x if it is in the same function? It can have the same name as in the example and still different meanings. There must be a way to distinguish the first declaration and the shadowing one. Is it possible to add some additional info to them like line position in a local_symbol in this case? I always asked myself how Sourcetrail would manage to deal with lifetimes and also with user created data types.

@egraether
Copy link
Contributor

egraether commented Nov 20, 2019

As mentioned, you can append info to the name of the local_symbol. It's up to the indexer author to decide whether these 2 variables are the same or not.

@jokeyrhyme
Copy link

Do you think it is possible to use the Rust language server for this work? That might make it possible to map all languages that have such a server (e.g. Go, TypeScript, etc) in a generic way into Sourcetrail

@yozlet
Copy link

yozlet commented Nov 22, 2019

@jokeyrhyme I was just wondering the same thing, because a well-implemented Language Server can handle most (maybe all?) of what Sourcetrail needs. I'll create a separate issue.

EDIT: Added as #20

@D1mon
Copy link

D1mon commented Jul 27, 2020

how is the project progressing? I've been waiting for a ~year. I really need rust language support. please do not abandon the project.

@astrolemonade
Copy link

@D1mon I am sorry to inform you but it looks like a dead end, things are moving slow.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants