On 18 Mar 2019, at 18:05, John McCall wrote:
On 18 Mar 2019, at 15:38, Don Hinton wrote:
Hi John:
I found this investigating the cast assert noted here:
http://lists.llvm.org/pipermail/cfe-dev/2019-March/061685.html
I subsequently did quick grep and found a number of cases in
clang+llvm
(d
On 18 Mar 2019, at 15:38, Don Hinton wrote:
Hi John:
I found this investigating the cast assert noted here:
http://lists.llvm.org/pipermail/cfe-dev/2019-March/061685.html
I subsequently did quick grep and found a number of cases in
clang+llvm
(didn't find any in other projects) . I'm happy t
Hi John:
I found this investigating the cast assert noted here:
http://lists.llvm.org/pipermail/cfe-dev/2019-March/061685.html
I subsequently did quick grep and found a number of cases in clang+llvm
(didn't find any in other projects) . I'm happy to fix these in mass,
i.e., s/cast/dyn_cast/, but
On 18 Mar 2019, at 14:39, Don Hinton wrote:
It looks like this change introduced a small bug; Specifically, the
following cast test:
- if (auto PT = dyn_cast(DestTy)) {
...
+ // If we're producing a pointer, this is easy.
+ if (auto destPtrTy = cast(destTy)) {
Since the cast can fail, s
It looks like this change introduced a small bug; Specifically, the
following cast test:
- if (auto PT = dyn_cast(DestTy)) {
...
+ // If we're producing a pointer, this is easy.
+ if (auto destPtrTy = cast(destTy)) {
Since the cast can fail, shouldn't you prefer dyn_cast<>(), which can
re
