I haven't done anything like this myself, so I can't say if the lints are
intended to be used outside the compiler. However, I think your problem is
just a missing rustc:: at the start of your imports. You probably want
'use rustc::middle::typeck::infer', for example.
Also, it is possible to get
I haven't tried this at all, but could iterating over the range [ 0,
g.edges.len() ) work?
On Sun, Jun 1, 2014 at 2:26 PM, Cameron Zwarich wrote:
> It’s difficult to do something better without somewhat breaking the
> encapsulation of your graph type, but you could split G into edge and
> verte
Similar to what Daniel said, I don't think this works nicely unless all
possible calls to foo are enclosed with this keyword. The code for enforce!
would be part of foo, and called from multiple locations. If some disable
it and some don't, then what?
In general, I'd be against allowing disabling
My biggest gripe with port and channel is that a port can both send and
receive things, and a channel is what this things travel along. Also, I
believe there is precedent in other languages for source/sink, though that
may be only for pipes, which are unrelated to this discussion.
Regardless, I a
I would expect Channel::new() to create a channel object that either lets
me send and receive, or lets me get a source and sink to send and receive
with. Borrow rules may prevent this, but my point is that Channel::new()
would generally be expected to return a struct, and not a tuple.
On Jan 23, 2
I'd definitely be in support of the change to easy tagging - I've seen
quute a few issues where I've thought 'I could do this' but then realized I
have no idea where to start.
On 2013-11-26 12:59 AM, "Corey Richardson" wrote:
> Hey fellow Rusties,
>
> We have a fair number of new contributors, an
If the values are cached, and the structure implementing the cache has the
same lifetime (or longer? Unsure on that...) as the map then I'd expect it
to work. For generated/retrieved, non-cached values I don't believe it
would work.
On 2013-09-25 7:54 PM, "Daniel Micay" wrote:
> On Wed, Sep 25,
Could it be possible for rusti to spawn a task that runs the expression,
and then if that results in a fail! it would become a simple child-task
failure cleanup, which in this case means printing the appropriate error
message?
Of course, if there is a lot of state, this might not be feasible, but
