On 1 June 2017 at 14:36, Tim Northover wrote:
> On 26 May 2017 at 11:29, Richard Smith wrote:
> > If we generally think that distinction is a good thing, then (because
> this
> > is a conforming extension) consistency weakly suggests that it should
> not be
> > controlled by GNU mode. But I don'
On 26 May 2017 at 11:29, Richard Smith wrote:
> If we generally think that distinction is a good thing, then (because this
> is a conforming extension) consistency weakly suggests that it should not be
> controlled by GNU mode. But I don't find that argument decisive; the
> important thing is that
On 26 May 2017 at 10:34, Tim Northover via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On 24 May 2017 at 17:54, Richard Smith wrote:
> > Yikes :-( Maybe libc++ *should* have that extension then. It sounds like
> > we'll silently get the wrong value for any attempt at std::complex /
> > _Co
On 24 May 2017 at 17:54, Richard Smith wrote:
> Yikes :-( Maybe libc++ *should* have that extension then. It sounds like
> we'll silently get the wrong value for any attempt at std::complex /
> _Complex interop right now:
That sounds like a pretty good idea whatever we decide to do about the lite
On 24 May 2017 at 15:32, Marshall Clow via Phabricator
wrote:
> More. Trying the above code on godbolt.org, gcc 6.1/6.2/6.3/7.1 all reject it
> (with `-std=c++14` and `-std=c++1z`) with the error message:
This was a pretty explicit intent in Richard's proposal: treat
incoming code as charitably
On 24 May 2017 3:19 pm, "Tim Northover" wrote:
On 24 May 2017 at 15:06, Richard Smith wrote:
> I think this is expected. Clang has an extension where it treats 1.0if as
a
> _Complex float if no operator""if is available;
Since it's breaking some bots, I've reverted my commit while we hash
this
mclow.lists added a comment.
More. Trying the above code on godbolt.org, gcc 6.1/6.2/6.3/7.1 all reject it
(with `-std=c++14` and `-std=c++1z`) with the error message:
> : In function 'int main()':
> :4:30: error: unable to find numeric literal operator 'operator""if'
>
> { std::complex foo
On 24 May 2017 at 15:06, Richard Smith wrote:
> I think this is expected. Clang has an extension where it treats 1.0if as a
> _Complex float if no operator""if is available;
Since it's breaking some bots, I've reverted my commit while we hash
this out. r303813.
> libc++ has an extension
> where
On 24 May 2017 at 14:35, Marshall Clow via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> mclow.lists added a comment.
>
> This broke a libc++ test. The following is expected to fail to compile:
>
> #include
> #include
>
> int main()
> {
> std::complex foo = 1
mclow.lists added a comment.
This broke a libc++ test. The following is expected to fail to compile:
#include
#include
int main()
{
std::complex foo = 1.0if; // should fail w/conversion operator
not found
}
when build as C++1z
https://reviews.llvm.org/D33424
___
t.p.northover closed this revision.
t.p.northover added a comment.
Thanks Richard, I've committed it as r303694 with your suggestions.
https://reviews.llvm.org/D33424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
I like it, and it seems like it would nicely generalize if there are more cases
that we find need this treatment.
Comment at: clang/lib/Lex/LiteralSupport.cpp:676-682
-
t.p.northover updated this revision to Diff 99974.
t.p.northover added a comment.
OK, that seems doable. After playing around I came up with this new patch (and
remembered to "git add" my own test this time).
It feels like a bit of a hack, but I played around with some alternatives and
couldn't
rsmith added a comment.
Counterproposal: in `-std=*++14` onwards, treat this construct as a
user-defined literal, but fall back on the built-in interpretation if name
lookup doesn't find an `operator""i` function. (The two interpretations only
conflict if the source code explicitly does somethi
t.p.northover created this revision.
Herald added a subscriber: mcrosier.
While looking into the regression tests' compatibility with C++14, many of the
failures were because that specification defined UDLs for imaginary constants,
specifically ones ending in 'i' and 'il'. This conflicted with t
15 matches
Mail list logo
