rust-analyzer unresolved module

[YUCLing]

I'm having issues with including the templates built by ructe, I'm not sure is it a ructe issue or rust-analyzer issue.

I set up my project with ructe and rust-analyzer claims unresolved module, can't find module file: _utils.rs, or _utils/mod.rs error. The same error appears inside the example code too. Both projects can be compiled without any errors.

I've tried different versions of rust-analyzer, all the same. Also I found an issue in rust-analyzer: rust-lang/rust-analyzer#7846, however it's fixed already.

rust-analyzer version: v0.3.1599
rustc version: 1.71.0

[kaj]

Yes, I have seen problems with this too. I have kind of assumed it is a limitation in rust-analyzer, as the ordinary compiler or clippy don't give me any warning that seems related. The rust-analyzer issue you mention seems related, but has been fixed since 2021. So maybe ructe is doing something stranger than what that fix was about.

I didn't find any mention of the OUT_DIR environment variable in the issue or fixing PR, so maybe they only fixed it for "static" paths?

Could you write a test program, where a build.rs writes two files in $OUT_DIR, have one use the other and then include! the one file an ordinary source file and try to use something from the other file? If that fails, there is still a problem i rust-analyzer (otherwise I can try to do that myself, but I'm not sure when I'll find the time for it).

[YUCLing]

Just tested it. It seems you are right, the issue persisted. I just created a minimal reproduction, I will open an issue in rust-analyzer.

[kaj]

Did you create an issue in rust-analyzer, @YUCLing ? Could you link it here for tracking?

[YUCLing]

Sure, rust-lang/rust-analyzer#15365

[JohnDowson]

I am not sure it is an R-A issue. Honestly, I'm more concerned that cargo accepts the, uhh, interesting folder structure emitted by ructe, when it clearly
a) would not be valid if defined under ./src manually
b) when include!d from OUT_DIR shouldn't even be discoverable

[kaj]

Honestly, I'm more concerned that cargo accepts the, uhh, interesting folder structure emitted by ructe, [...]

Huh? What's "interesting" about the folder structure? Why should it not be discoverable when included?

[Zynh0722]

https://github.com/Zynh0722/ructe/tree/rust-analyzer-workaround

Super crude workaround that I whipped up just compiles all the of the template modules into a single file.

Worth noting that this specific setup almost certainly wont work for statics, or anything other than just a dirt simple setup with just compile_templates, but I both got resolved modules, and type hinting :P

Something similar might be possible with statics, I just havent begun using them yet, so Im just pretending they dont exist.

[Zynh0722]

b) when include!d from OUT_DIR shouldn't even be discoverable

This part is also mildly surprising to me, as well as to the people on reddit that I brought this same issue up to. Also everyone seems to be trying to state its an invalid module structure. It most certainly is valid lol.

The reason I thought it might not be discoverable is because of the assumption that the include! macro is more or less just a text replacement, and not a "include this rust source code, and also discover any relevant modules it may be trying to include relative to its own location"

[kaj]

The include! macro is mainly "just a text replacement", but it is a text replacement with correct span handling, so that error messages can be reported for the correct line of the included file, and so that resolving modules in the included code works correctly. I was a little surprised and rather impressed when I was told this back in 2016, but for the compiler it has worked flawlessly since then.

If that does not with rust-analyzer, then that is a problem in rust-analyzer.

(Here's the comment on my blog where Jethro Beekman told me that this should work.)

[Zynh0722]

The include! macro is mainly "just a text replacement", but it is a text replacement with correct span handling, so that error messages can be reported for the correct line of the included file, and so that resolving modules in the included code works correctly. I was a little surprised and rather impressed when I was told this back in 2016, but for the compiler it has worked flawlessly since then.

If that does not with rust-analyzer, then that is a problem in rust-analyzer.

(Here's the comment on my blog where Jethro Beekman told me that this should work.)

Haha, I am glad we all agree it is indeed a bit magical, though unlike normal I think that is a good thing here.

I do definitely agree the problem is with R-A, as both cargo check and obv following, the compiler itself handle the whole of your implementation quite well.

Hence why I didn't make a PR or suggest the change I made, simply provided a short term workaround for those wanting their IDE experience to not be subpar.

Overall I am quite happy with ructe thus far, and I very much appreciate the effort that's been put into it.

If someone asks, or if I end up using statics, which is more probable by the moment, I will likely extend that workaround to work for those as well, but honestly I don't know if that will be as trivial as compile_templates was, and that is a lot of work to skirt a bug of sorts with R-A.

Otherwise I wouldn't recommend the workaround at all, for I don't understand the implications of my edits, I just know I got the types I wanted being spit out of cmp lmao