r227956 - Add some overloads so that floating point literals can be AST matched properly.

[Kim Gräsman]

OK, fair enough, I thought I'd raise the issue. It still makes me
uneasy, but that's partly because I don't fully understand the rules
for floats beyond the fact that they're full of nasty surprises.

I guess it's hard to phrase it any other way with the same
flexibility. E.g. passing the literal as a string would probably make
it hard to have equals("0.5") match "float i = 0.5f", etc.

- Kim

On Tue, Feb 3, 2015 at 7:11 PM, Daniel Jasper <djasper at google.com> wrote:
> This is for matching float literals and for that it should provide good
> enough value. I don't think people will want to match the result of
> computations here and if they do want that, we can add more complex
> matchers.
>
> On Tue, Feb 3, 2015 at 6:41 PM, Kim Gräsman <kim.grasman at gmail.com> wrote:
>>
>> Hi Daniel,
>>
>> On Tue, Feb 3, 2015 at 10:45 AM, Daniel Jasper <djasper at google.com> wrote:
>> > Author: djasper
>> > Date: Tue Feb  3 03:45:52 2015
>> > New Revision: 227956
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=227956&view=rev
>> > Log:
>> > Add some overloads so that floating point literals can be AST matched
>> > properly.
>> >
>> > I am not entirely sure whether the implemented sematics are ideal. In
>> > particular, should floatLiteral(equals(0.5)) match "0.5f" and should
>> > floatLiteral(equals(0.5f)) match "0.5". With the overloads in this
>> > patch, the answer to both questions is yes, but I am happy to change
>> > that.
>>
>> This looks scary to me given the general difficulties in comparing floats:
>> https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/
>>
>> Or is it safe because they're both fixed literals and not the result
>> of a calculation? Then again, nothing prevents me from doing;
>>
>>   floatLiteral(equals(sqrt(AnArgument)))
>>
>> - Kim
>
>