Would #[momo] be worthwhile if IDEs worked well with it?

[EliahKagan]

3a339da (#1529) removed #[momo]. This was motivated, at least in part, by degraded auto-completion in RustRover. But the commit message indicates that the benefit was small.

If auto-completion in can be fixed in RustRover and any other popular affected IDEs, would it be worthwhile to restore #[momo]? Or should other considerations continue to keep it out?

---

I don't have a specific RustRover fix in mind, and I have not even (yet?) investigated its effect on other significant IDEs such as VS Code with rust-analyzer or Zed (which I think also uses rust-analyzer). I am more asking this in case that is fixed in the future, to decide whether it is worthwhile to look into opening issues about it in RustRover and whatever else is affected, and to so that I don't forget (I already forgot once, but happened to revisit #1529 while writing #1575).

[Byron]

That's a tough one. @NobodyXu invested a lot into it and it saddened me that the payoff was very minor, in terms of build-time and binary size saved. Overall, I never found the complexity of it all to be worth it, but didn't want to see the effort to be wasted.
However, when it was clear that RustRover had issues, I just couldn't let it be an impediment.

Based on this thought, I suppose it's OK to bring it back if IDEs could handle it as it at least had some positive effect.However, the difficulties dealing with it and the complexities involved with it would still give me a tough time maintaining it.
That part of me, of course, wouldn't want to bring it back for that reason alone.

[EliahKagan]

Would it be acceptable for an IDE to treat it as though it was not there at all? Or should an IDE really "understand" the effect (or lack thereof) on the code it is modifying?

(I don't know anything about how to make that happen, but I have vague sense that workarounds for IDEs are sometimes achieved along those lines.)

[NobodyXu]

Would it be acceptable for an IDE to treat it as though it was not there at all

Hmmm, I think treating it as if not existing would work, if you know for sure mono is not generating buggy code, which does seem like something that it can guarantee given that it's been working fine.