[PATCH] Removing some thread safety custom parsing

[Aaron Ballman]

On Wed, Sep 4, 2013 at 1:57 PM, Delesley Hutchins <delesley at google.com> wrote:
>
> It does look like the unevaluated context is the only thing missing at this
> point.  It seems reasonable to me that the unevaluated context might be
> useful to other attributes, outside of thread safety, so we could consider
> adding an extra bit to Attr in Attr.td.

I am playing around with some ideas on that front (making the
arguments a bit more tied to the parsing behavior), but am not far
enough along to know whether it's a feasible/good idea or not.  For
instance, this would allow for you to get an unresolved identifier in
more than just the first argument position.  I'll keep the evaluation
context in mind as I toy with the concept.

~Aaron
>
>
>
> On Wed, Sep 4, 2013 at 10:40 AM, Aaron Ballman <aaron at aaronballman.com>
> wrote:
>>
>> Drat!  I knew it was too good to be true.  ;-)  Thanks!
>>
>> ~Aaron
>>
>> On Wed, Sep 4, 2013 at 1:28 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>> >
>> > On 4 Sep 2013 10:16, "Aaron Ballman" <aaron at aaronballman.com> wrote:
>> >>
>> >> With the refactorings that have been happening for attribute parsing,
>> >> it seems this piece of custom parsing logic for thread safety analysis
>> >> can go away.  The only real modification here is the updated test case
>> >> which provides a definition for two functions; I wanted to make sure I
>> >> was not subverting the intention of the test.
>> >
>> > Sadly, you are. We need the unevaluated context around the expression
>> > parsing here. But I suspect most of the duplication can still be
>> > factored
>> > out.
>
>
>
>
> --
> DeLesley Hutchins | Software Engineer | delesley at google.com | 505-206-0315