Closed sunshowers closed 2 years ago
Thinking about this in the context of https://github.com/bytecodealliance/target-lexicon/issues/78, #63, and #76, we've been seeing more pressure towards special-case parsing, and it seems that Rust target names have been evolving away from being triples and toward just being arbitrary sequences of identifiers. This suggests that perhaps target-lexicon should start refocusing on supporting rustc json target identifiers, which are explicitly split into arch/os/vendor/env categories, and not try to support all the new rust target names.
I'm curious if you have a perspective on this. Do you need all these new targets? Do you use target-lexicon for parsing target names?
Thanks! That's a great question. In my own uses in target-spec I use cfg-expr first. That library has a key-value map of builtin targets, similar to what you're suggesting.
I then fall back to target-lexicon if cfg-expr doesn't have a record of that target, typically if the target is new or somehow custom. The heuristic parsing target-lexicon does is still useful for some new targets (eg in this PR, m68k-unknown-linux-gnu, armv7-unknown-linux-uclibceabihf).
So I think the "key-value map queried from the latest rustc json targets" use case is covered well by cfg-expr. I can see target-lexicon still serving a few purposes:
Let me know what you think!
Makes sense. So the thing about this PR that makes me the most nervous is TripleField
. Would it be difficult to organize this code in a way that allows special-case rules to be factored out into helper functions, so that they can be applied one at a time and be clearly separated?
Hi -- I completely apologize for dropping the ball here. I'm going to get to it now.
This should address your concerns -- thanks @sunfishcode!
Looks good, thanks!
There are some idiosyncratic targets in here -- include special code to handle them.