search for: hasvalues

Hey Ben, This change broke some clangd code (no failing test, mea culpa), because it changed the move semantics. Previously: a moved-from llvm::Optional was None (for all types). Now: a moved-from llvm::Optional is None (for non-trivial types), and has the old value (for trivial types). FWIW, a moved-from std::optional is *not* nullopt, and contains the moved-from value. This seems sad to me,

That's an unintentional change. However, the reason for this change was to make optional of trivially copyable types trivially copyable, adding a user-provided move ctor would break that again :( I'm leaning towards making the non-trivial version of llvm::Optional more like std::optional. In the long term std::optional is going to replace llvm::Optional. How bad would that be for your use

On Wed, Jan 24, 2018 at 11:47 PM, Benjamin Kramer <benny.kra at gmail.com> wrote: > That's an unintentional change. However, the reason for this change > was to make optional of trivially copyable types trivially copyable, > adding a user-provided move ctor would break that again :( > > I'm leaning towards making the non-trivial version of llvm::Optional > more

Hi all!   My question is how to colour pixels by z value in persp plot in raster package. Here is an example:     x <- seq(-1.95, 1.95, length = 30) y <- seq(-1.95, 1.95, length = 35) z <- outer(x, y, function(a,b) a*b^2) r1 <- raster(nrows=35, ncols=30, xmn=0, xmx=30, ymn = 0, ymx = 35) r1[] <- c(z) persp(r1)   There already exist some function to produce persp plot for anothe

It seems MemorySSA.cpp is the only real code where we found the problem happening. Is it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None?

Inline George > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Thu, 8 Jan 2015 14:02:26 -0800 writes: > On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: >> On Thu, 8 Jan 2015, Michael Lawrence wrote: >> >> If we do add an argument to get(), then it should be named consistently >>>

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

I'm not exactly thrilled about the size of this diff -- I'll happily break it up into more manageable bits later today, because some of it is test fixes, another bit is a minor bug fix, etc. Important bit (WRT ConstantExpr): moved the loop body from buildGraphFrom into a new function. The body has a few tweaks to call constexprToEdges on all ConstantExprs that we encounter.

On Thu, Jan 8, 2015 at 11:57 AM, <luke-tierney at uiowa.edu> wrote: > On Thu, 8 Jan 2015, Michael Lawrence wrote: > > If we do add an argument to get(), then it should be named consistently >> with the ifnotfound argument of mget(). As mentioned, the possibility of a >> NULL value is problematic. One solution is a sentinel value that indicates >> an unbound value

If we do add an argument to get(), then it should be named consistently with the ifnotfound argument of mget(). As mentioned, the possibility of a NULL value is problematic. One solution is a sentinel value that indicates an unbound value (like R_UnboundValue). But another idea (and one pretty similar to John's) is to follow the SYMSXP design at the C level, where there is a structure that

On Thu, 8 Jan 2015, Michael Lawrence wrote: > If we do add an argument to get(), then it should be named consistently > with the ifnotfound argument of mget(). As mentioned, the possibility of a > NULL value is problematic. One solution is a sentinel value that indicates > an unbound value (like R_UnboundValue). A null default is fine -- it's a default; if it isn't right for

In November, we had a "bug repository conversation" with Peter Hagerty and myself: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16065 where the bug report title started with --->> "exists" is a bottleneck for dispatch and package loading, ... Peter proposed an extra simplified and henc faster version of exists(), and I commented > --- Comment #2