On 10/5/21 03:21, Matteo Bruni wrote:
On Mon, Oct 4, 2021 at 3:52 AM Zebediah Figura zfigura@codeweavers.com wrote:
Signed-off-by: Zebediah Figura zfigura@codeweavers.com
This series is kind of an RFC, though, because I'm not actually sure we want to do this. The obvious benefit is that we get rid of a lot of common boilerplate that's otherwise pretty hard to sidestep—as shown by the diffstat in patch 3. On the other hand, we might want to do something like GCC's "x <aka y>", in which case this would be a step in the wrong direction (and a pretty impactful step at that.)
This is generally fine to me, although I don't think I see much of an improvement from this going forward. Basically all the cases that are simplified in patch 3 are error messages (unsurprisingly); simplifying the code for those is nice and good but probably not too big of a deal. It would be more significant if we were to add many more errors down the line or if the same kind of boilerplate started to be required in some other places, possibly far from error paths. Maybe that's actually the case?
Nothing that occurs to me at the moment, no.
On the other hand I wouldn't be surprised if we add a lot more errors going forward...
I guess that kind of "x (aka y)" notes in error messages would be nice to have, although probably not critical. I don't know that the changes made by this patch series would matter a whole lot in that regard though? It shouldn't make a difference for named types and those are often the most interesting ones to "unravel" (I'm thinking of the usual typedef case here).
I wasn't really planning on implementing it any time soon, but I don't want to step in the wrong direction if it's desirable at all.
The idea is that if you want "x (aka y)" you'd probably add that capability to hlsl_type_to_string() [or introduce a similar function while keeping hlsl_type_to_string() around].
I guess that name too could always be stored in the type object...
Or we could forgo this series but have special format modifiers for various things. That takes work too though. Probably best just to leave things alone for now.
(This series also has us taking a bit more memory, but it's not a lot. We already allocate names for all numeric types, since they aren't keywords.)
Yeah, I'm not particularly concerned by that either.