Hi everyone!
As you may know, I'm working on debug info support for rustc. Last week
I found a small bug regarding the size of structs as stored in the debug
info. Once found, it was not hard to fix but it led me to thinking a bit
more on how to handle memory layout in the debug info code and
Hi Rémi,
Yes, this looks like a compiler bug to me.
Cheers,
Philipp
On Mon, Jun 24, 2013 at 1:07 PM, Rémi Fontan remifon...@yahoo.fr wrote:
I have another example that puzzles me.
struct Vec { x:float, y:float, z:float }
impl Vec {
pub fn getRef'a('a mut self, i:uint) - 'a mut float
For those interested, I'll be logging my progress on this (and other
things) at http://rustlog.octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 6/24/13 2:14 AM, Michael Woerister wrote:
* There is the trans::adt module and the Repr enum which look very
promising. It does not provide all the information I need (e.g. it will
include generated fields, but does not explicitely specify where they
are located, just in comments (enum
On 06/24/2013 05:26 PM, Patrick Walton wrote:
On 6/24/13 2:14 AM, Michael Woerister wrote:
* There is the trans::adt module and the Repr enum which look very
promising. It does not provide all the information I need (e.g. it will
include generated fields, but does not explicitely specify where
On 13-06-24 09:10 AM, Michael Woerister wrote:
This still leaves open the question of internal runtime structures, such
as heap boxes, vecs, and possibly pointers.
Unsafe and region pointers seem to be regular machine-word sized values,
but I think I read somewhere that some pointers (to
Can someone clarify what's going on here?
You have multiple mod file2 statements in the crate. This is probably not
what you want.
If you have mod X in two files, X::Y in those two files DO NOT refer to the
same thing,
but to two different things. Use use statements instead.
On 13-06-17 05:57 PM, Graydon Hoare wrote:
Hi,
As part of preparation for 0.7 (due around the end of june / early july)
we're going to be closing the tree for a while, fixing the lingering
breakage that's snuck through 'auto' and accumulated on 'master', and
greatly widening the 'auto' coverage
Thanks again for everyone's patience. I remain convinced that having
automatic integration is worth much more than a free-for-all on the tree,
That alone is worth more than 20 new active developers, I would say.
Thanks for your hard work on this Graydon, and team !
--
-Thad
On 06/24/2013 07:28 PM, Graydon Hoare wrote:
On 13-06-24 09:10 AM, Michael Woerister wrote:
This still leaves open the question of internal runtime structures, such
as heap boxes, vecs, and possibly pointers.
Unsafe and region pointers seem to be regular machine-word sized values,
but I think
Thanks. For the sake of completeness, here is the fixed version:
test-crate.rc
mod file1;
mod file2;
fn main() {
file1::bar();
}
-- file1.rs
use file2::HasInt;
struct X {
x : int
}
impl HasInt for X {
fn foo(self) - int {
self.x
}
}
pub fn
On 6/22/13 6:38 PM, Brian Anderson wrote:
...
I agree Rust would be great for presenting these issues since it is
designed to make the programmer understand the costs of abstractions,
but it also doesn't punish them for making errors in the various ways
that C does. I totally want this to happen
Hi,
Some clever folks on #rust have pointed out that there is a (somewhat)
exploitable security flaw in the way bors consumes r+ comments.
Specifically, github permits a repository owner, in some circumstances
(which we can't quite figure out) to _edit comments of other people_ on
commits in
On Mon, Jun 24, 2013 at 9:17 PM, Graydon Hoare gray...@mozilla.com wrote:
Hi,
Some clever folks on #rust have pointed out that there is a (somewhat)
exploitable security flaw in the way bors consumes r+ comments.
Specifically, github permits a repository owner, in some circumstances
(which
On 13-06-24 07:05 PM, Daniel Micay wrote:
Also, not just the head commit because someone could reset and force push. :P
Bors only pays attention to comments on the head commit, and comments on
commits adhere to that specific sha1 only. This is intentional.
The part where users can edit
Wouldn't an easier way to fix this (without having to change the way review
comments are set out) just be to only allow track r+ comments if they're
unedited? Github seems to support this facility according to the API
documentation (just check if created_at and updated_at are the same). If a
Oops, accidentally sent that twice. Anyway, I just realised that the
timestamp for editing is only accurate to a minute (from what I can see),
so someone could easily write a script that automatically edits any
comments by a reviewer (or just sticks by their emails and quickly edits
it). So
17 matches
Mail list logo
