Re: [PATCH] scripts: generate_rust_analyzer.py: add missing macros -> core dep

[Tamir Duberstein]

On Sun, Feb 9, 2025 at 12:05 PM Miguel Ojeda
<miguel.ojeda.sandonis@xxxxxxxxx> wrote:
>
> On Sun, Feb 9, 2025 at 5:49 PM Tamir Duberstein <tamird@xxxxxxxxx> wrote:
> >
> > Ah, I see! I'm happy to do that in this patch if you think it's worth it.
>
> I don't know if it is worth it (it requires testing it, I guess) -- we
> can go simple until we see we need it, especially for a fix.
>
> > The python function `append_crate` takes both `deps` and
> > `is_proc_macro`, so implying dependencies based on the value of
> > `is_proc_macro` could create duplication.
>
> Yes, but the dependencies for proc macros are a completely different
> set -- that is what I was discussing above. And those dependencies
> will be shared across all proc macros, when/if we have several
> eventually (e.g. per subsystem).
>
> That is why, since we already have `is_proc_macro`, I think we should
> just use that. It may make sense to split `append_crate` into two
> functions or similar, e.g. having a `append_proc_macro_crate` (that
> perhaps does not require any dependencies) -- it would be the same
> idea but cleaner.
>
> Anyway, the simpler the change, the better, especially for a fix. But
> please take it into consideration.
>
> Cheers,
> Miguel

Heh, I keep typing a reply and you keep beating me to it. TL;DR I came
to the same conclusion: we should keep the fix simple and refactor on
-next.

I'll send v2 shortly.

The detailed reason why splitting host and target crates requires
refactoring is that we currently we use `display_name` as a crate's
unique identifier (i.e. both as a way of naming it as another crate's
dependency, and as its name in the dependent crate). If we wanted to
have separate target and host `core` crates we'd need a slightly more
sophisticated way of describing dependencies. I'll work on this in a
separate series.