rustrust-analyzer

What would be the appropriate way to mark a folder as specifically ignored within Cargo and VsCode?


I am working on a hot reloading / dynamic loading system in rust, for a discord bot I am writing. I so far have a working bot and a folder in my project root called Cogs. I am using a build script to compile the contents of this folder (all lone .rs files) into .dylib files before main.rs gets run. However, writing a test.rs file has become difficult because I cannot:

How can I mark this folder as part of the project WITHOUT linking it into the project? So far, here is my cargo.toml:

[workspace]

[package]
name = "all-seeing-eye"
version = "0.1.0"
edition = "2021"
description = "my descrption"
build = "build.rs"

[dependencies]
clearscreen = { version = "2.0.1", features = ["windows-console"] }
crossterm = { version = "0.27.0", features = ["serde"] }
tokio = { version = "1.36.0", features = ["full"] }
serde_json = "1.0.114"
serenity = "0.12.1"
colored = "2.1.0"
serde = "1.0.197"
toml = "0.8.12"
ctrlc = "3.4.4"

[[bin]]
name = "main"
path = "src/main.rs"

And here is my project structure:

Project
| -> Cogs
     | -> test.rs
     | -> more will be added...
| -> src
     | -> main.rs
     | -> logging.rs
     | -> password.rs
     | These should be compiled normally and linked statically, which works fine right now
| -> //some various config
| -> Cargo.toml
| -> build.rs

I have tried every config option I could find on the rust-analyzer plugin, but this didn't work, and I have tried including it as a separate lib in Cargo.toml, but this did not resolve the issue. I just want rust-analyzer to end up seeing that Cogs is actually in use.


Solution

  • Idea: What if you put the Cogs in the src/bin folder as separate binaries besides main.rs, and use Makefile or Just to recompile them when you need? It might heavily depend upon the mechanism by which you link the cogs to the rest of the project.

    For ideal compiler diagnostics, you might be better off focusing on a big library of Cog helpers, and simpler Cog binaries to compose the library capabilities in different ways, otherwise you may wind up forced to repeat code across the cognitive modules of your discord bot (or whatever cogs are).

    Dynamic is cool, and worth playing with, but sometimes it can expose you to runtime errors, and the philosophy of the Rust language is to frontload frustration before runtime, so you know the compiled artifact(s) are legit once they do compile and pass tests. If extensibility is the goal, then one idea would be to use traits and make the cogs share a standard functional interface so anything that quacks like a cog can plug into your bot.

    Might be worth clarifying your motive for this directory structure and figure out how other developers who have similar goals have solved the same problem as they saw it.