rust-dev-tools / rls-data Goto Github PK

Which I need to be able to link to functions from C++. I can tag them manually with no_mangle from bindgen, which does the trick, but ideally it wouldn't be needed.

I'm filing instead of writing a PR directly because I don't know the process (I know rustc also needs to be updated), and also because I don't know what's the best way to fix it.

I can imagine DefKind::ForeignFunction / DefKind::ForeignStatic, but also maybe just a is_foreign enum / boolean in Def.

WDYT @nrc? I'm happy to send patches for whatever is needed :)

It has been deprecated: announcement.

Is there any functionality you would require from Serde or another library before this would be possible?

Right now if running the rust compiler on Windows with -Zsave-analysis, the Span::file_name items usually end up with windows-style paths (e.g. Z:\foo\bar.txt). However in some cases they appear to have a mix of windows and unix dir separators (e.g. Z:\foo\bar/lib.rs). This is just weird. It should be consistent in what slashes it's using.

For context, this came up when trying analyze these files for searchfox on a linux host. The rls-analysis crate will read save-analysis files generated on Windows, but the Span::file_name ends up as a PathBuf of a single component because \ is a valid filename char on Linux. I can deal with this by doing a search-and-replace, but when the separators are mixed (both \ and /) it makes me uneasy.

/cc @emilio

In order to support more fine-grained detail about Enum variants, add new DefKinds. This will help RLS and its clients to be more specific in symbol classifications for the variants.

I'll be happy to work on a PR for this.

This still has

rustc-serialize = "0.3"

In its Cargo.toml. IIRC this is being deprecated.

CratePreludeData.crate_root and ExternalCrateData.file_name both store file paths, so using PathBuf as the type would semantically make more sense.