It’s come up that scopename and hdlname can have redundant information. Before we attempt to resolve this as part of better attribute preservation, since that might involve some level of redundance reduction, it would be good to know ahead of time if there are external expectations for the formatting here. If you have a project producing or interpreting these attributes, please speak up if there’s a situation where both scopename and hdlname are applied on an object and scopename isn’t simply the parent of the hdlname path. More generally, do share your ideas about the format and meaning of these attributes. Currently I’d guess the best move is override scopename with hdlname (and emit a warning) and then not emit scopename by default since hdlname will contain the same information. That way, inside of Yosys, we can provide hdlname and scope getters that are unambiguous and in sync. It’s also likely that the changes to this behavior and interfaces will only really apply to a “mode” of the flow that’s on by default for synth. All this is tied to upcoming work to improve source location data storage, generation, and preservation
I was unaware of both of these attributes, the Spade compiler currently only emits src attributes
From my perspective I don’t see any case where scopename would be be different from the parent of hdlname