The functions is useful for all kinds of fat pointers, but get_len()
just feels so wrong for trait object fat pointers. Let's use get_meta()
because that's rather neutral.
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
before:
576.91user 4.26system 7:42.36elapsed 125%CPU (0avgtext+0avgdata 1142192maxresident)k
after:
566.50user 4.84system 7:36.84elapsed 125%CPU (0avgtext+0avgdata 1124304maxresident)k
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
The implementation of the remainder operation belongs to
librustc_trans, but it is also stubbed out in libcore in order to
expose it as a trait on primitive types. Instead of exposing some
implementation details (like the upcast to `f64` in MSVC), use a
minimal implementation just like that of the `Div` trait.
Since enums are namespaced now, should we also remove the `Fk` prefixes from `FnKind` and remove the reexport? (The reexport must be removed because otherwise it clashes with glob imports containing `ItemFn`). IMO writing `FnKind::Method` is much clearer than `FkMethod`.
It doesn't really make sense for DefId to be in libsyntax -- it is concerned with a single crate only. It is the compiler that understands the idea of many crates. (At some point, there might be a useful intermediate point here.) This is a refactoring in support of incr. compilation, which will be adjusting the notion of a DefId to make it more durable across compilations.
This will probably be a [breaking-change] for every plugin ever. You need to adjust things as follows:
use rustc::middle::def_id::{DefId, LOCAL_CRATE}; // two most common definitions
ast_util::is_local(def_id) => def_id.is_local()
ast_util::local_def(node_id) => DefId::local(node_id)
We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.
Part of #24407.
This PR doesn't have code example since I didn't find how to raise it. If someone finds a code which does, please say it !
cc @pnkfelix
cc @eddyb
r? @Manishearth
We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.
It came up twice in quick succession on IRC that rustdoc doesn't run tests in bin crates, and doesn't give any explanation/warning either as to why. I thought it couldn't hurt to emphasize that in the Book.
The chapter on concurrency has two examples that both start with:
let something = thread::spawn(…
but the returned values have different types, because the second example has `.join()` at the end of the expression.
I haven't noticed that join at first, and was wondering how is that possible that the result can have `.is_err()` and `.join()` methods.
I've changed the second example to have the same structure as the first, so they're easy to compare.
