[llvm] r211668 - Fix another asserting method in the null streamer.

Philip Reames listmail at philipreames.com
Fri Jun 27 10:24:25 PDT 2014


On 06/25/2014 02:21 PM, Rafael EspĂ­ndola wrote:
>>> Why? We wouldn't want it to assert on the RecordStreamer for example.
>> This comes down to a question of what the best default is for the base
>> class.  If you're implementing a new derived class, is calling this function
>> without overriding it a source of error?  If so, the check is worth keeping.
>> Otherwise, it isn't.  I don't know the semantics of the MC hierarchy enough
>> to address this.
>>
>> I brought the issue up since I saw three changes in a row (two from you, one
>> from Nakamura) which seem to solve similar problems with different
>> solutions.  That raised a question in my mind, so I asked.
> So, there are only 3 file formats and a handful of streamers.  IMHO
> the best design is to move what we can to the target streamers (ARM
> being the current worst offender) and what remains in the MCStreamer
> interface should be implement in whatever way is most convenient for
> the existing streamers. We support plugging in targets, not file
> formats.
>
> Given that, it seems that a nop implementation is probably the best.
> If the interface gets too cluttered the way forward would probably be
> to add a ObjectFormat streamer, similar to what we did for the
> targets, but IMHO we are not there yet.
I will defer to your judgement here.  Thanks for taking the time to 
consider the question.

Philip




More information about the llvm-commits mailing list