eddyb

21 ms·

61.
by eddyb 9y ago
Okay I just properly took a look at this, and some of the sibling responses are only partially correct. It's not symbol names that change, but the crate does appear to have a hash used to sanity-check against this. I used these sourc
62.
by eddyb 9y ago
You sure you meant to reply to the follow-up to my comment? None of the hashes you mentioned is actually used by the compiler, except to detect changes wrt incremental recompilation. (EDIT: and to catch recompiled crates, see: https:&#
63.
by eddyb 9y ago
No file contents, that would defeat incremental recompilation.
64.
by eddyb 9y ago
In that specific context, crates that have the same name within a Cargo crate graph but aren't the same exact crate - this is pretty much always about semver versions, when incompatible ones are required from different parts of the cra
65.
by eddyb 9y ago
That changed with incremental recompilation, to allow reuse across changes. However, Cargo will still ensure different versions of the same crate have different symbols, by passing its own hashes to rustc via -C metadata.
66.
by eddyb 9y ago
Destructor scopes are determined from syntactical rules and lifetimes don't play any role in them. OTOH, lifetimes are restricted by the shape of the destructor scopes.
67.
by eddyb 9y ago
It's just for an example - see https://doc.rust-lang.org/std/f32/ .
68.
by eddyb 9y ago
No worries, I'm just surprised you managed to find a simple testcase that exhibits it, so, really, thank you! I've opened a (a bit vague for now) issue so at least I don't forget about it: https://github.com/r
69.
by eddyb 9y ago
This looks like yet-another-phase-ordering-issue in LLVM. I hit so many of these it's not even funny. Arguably one could find C code that shows the exact problem under clang. Example of optimized LLVM IR for that sample (press LLVM I
70.
by eddyb 9y ago
> There's no way to give a return value the lifetime of the caller, not the callee. That is, in the general case, not physically possible, and this sort of thing only works in GC languages because they return GC pointers to dynami
71.
by eddyb 9y ago
> This may be more of a "because we can" feature. What I see is actually "it's wanted/needed enough that it's worth putting in the huge effort to make such a complex (and novel?) system reality". EDIT
72.
by eddyb 9y ago
FWIW `cargo vendor` already exists, just not part of Cargo itself, but rather a tool by one of the core devs. It's even used for releasing the official Rust tarballs as we now employ crates.io dependencies in the standard library and t
73.
by eddyb 9y ago
http://www.mcmansionhell.com/ is still up, for now, at least not all the posts are gone, so have a look.
74.
by eddyb 9y ago
:(
75.
by eddyb 9y ago
Why just deprecate? Can't it be made to proxy behind the scenes to globset?
76.
by eddyb 9y ago
You can get it from debuginfo - just load your binary into any debug session (this might even work with no execution or core dump, just a blob of memory that from your program) and then you can cast char* to YourRustType* to be able to in
77.
by eddyb 9y ago
> It's just that it wasn't enforced before. To be clear, this "enforcing" is now the fact that your fields, if you forgot #[repr(C)], might be in a different order than what you assume. But it has been linted for a ve
78.
by eddyb 9y ago
Not by default, no, but what I mean that if you're debugging you can just enable debuginfo and that will contain the descriptions of the types including all fields, with the right offsets and everything.
79.
by eddyb 9y ago
The correct type layout is already encoded in debuginfo, so I'm not sure how that's a problem unless you're avoiding a debugger intentionally or simply can't use one?
80.
by eddyb 9y ago
> now needs 'repr(C)' It always has, we lint for this, and the Rust struct layout has been officially left unspecified (making assumptions based on it UB) from before 1.0, anyway. > One would think that would be 'repr(&
81.
by eddyb 10y ago
Indeed, the way you would be generic over generic closures would be "type HRTB" (e.g. F: for<T: Clone> Fn(&T) -> T), which depends on the trait system overhaul, just like ATC.
82.
by eddyb 10y ago
This idea has been waved around a bit, but in the form of `impl Error` where `_` is. That is, inside the function the `E1 | E2 | ...` type is being built, and if you have automatic dispatch for `Error`'s methods then it will work with
83.
by eddyb 10y ago
No lifetime parameters can be shorter than the lifetime of the struct itself, and that's part of the so-called WF (well-formed(ness)) rules in Rust (which the compiler tries to make as implicit as possible). However , that has nothi
84.
by eddyb 10y ago
Think what happens when you break a line comment (or a string, in languages where it can't span several lines). And that's an easy example at that.
85.
by eddyb 10y ago
If that is what I think it is, see https://docs.rs/indexing for something similar, crafted from invariance over higher-ranked lifetimes, instead of types. I don't think Rust can ever replicate the Haskell implementatio
86.
by eddyb 10y ago
AFAIK that's not actually true, one option they have is going through Mesa's llvmpipe in such cases. EDIT: to be clear, with the Servo nightlies you need to do this yourself but Firefox could bundle it eventually.
87.
by eddyb 10y ago
The only document I can think of outside of Niko Matsakis' blog ( http://smallcultfollowing.com/babysteps/ ) would be https://github.com/rust-lang/rust/blob/master/src/librus
88.
by eddyb 10y ago
Are you referring to unstable APIs being deprecated and removed? Technically we can remove those at any time (happens in librustc all the time), the deprecation period is to help and motivate migration of nightly users, nobody else can
89.
by eddyb 10y ago
The example can be written like this though: let codes: Vec<HuffmanCode> = data_table.iter() .zip(&code_lengths) .zip(&code_table) .map(|((&value, &length), &code)| {
90.
by eddyb 10y ago
Do note that with MIR the focus is polymorphic optimizations - reducing the LLVM IR for all monomorphizations of a generic function, at once . Unlike C++ templates, Rust enforces a single definition with uniform semantics, for a generic

More ›