std::vec: Sane implementations for connect_vec and concat_vec
Avoid unnecessary copying of subvectors, and calculate the needed space
beforehand. These implementations are simple but better than the
previous.
Also only implement it once, for all `Vector<T>` using:
impl<'self, T: Clone, V: Vector<T>> VectorVector<T> for &'self [V]
Closes#9581
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.
For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.
The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.
Closes#8651Closes#3547Closes#2537Closes#6971Closes#9222
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.
For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.
The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.
Closes#8651Closes#3547Closes#2537Closes#6971Closes#9222
If an item is skipped due to it being unreachable or for some optimization, then
it shouldn't be encoded into the metadata (because it wasn't present in the
first place).
I have tried this fix and it seems to work either with single or multiple trait inheritance.
trait Base:Base2 + Base3{
fn foo(&self);
}
trait Base2 {
fn baz(&self);
}
trait Base3{
fn root(&self);
}
trait Super: Base{
fn bar(&self);
}
struct X;
impl Base for X {
fn foo(&self) {
println("base foo");
}
}
impl Base2 for X {
fn baz(&self) {
println("base2 baz");
}
}
impl Base3 for X {
fn root(&self) {
println("base3 root");
}
}
impl Super for X {
fn bar(&self) {
println("super bar");
}
}
fn main() {
let n = X;
let s = &n as &Super;
s.bar();
s.foo(); // super bar
s.baz();
s.root();
}
bmaxa@maxa:~/examples/rust$ rustc error.rs
bmaxa@maxa:~/examples/rust$ ./error
super bar
base foo
base2 baz
base3 root
This solves problem of incorrect indexing into vtable
when method from super trait was called through pointer
to derived trait.
Problem was that offset of super trait vtables
was not calculated at all.
Now it works, correct offset is calculated by
traversing all super traits up to super trait
where method belongs. That is how it is
intended to work.
r? anyone
Part of #7081.
Removed many unnecessary context arguments, turning them into visitors. Removed some @allocation.
If this lands, then I think the only thing left that is unaddressed are:
* the various lint visitors, and
* middle/privacy.rs, which has `impl<'self> Visitor<&'self method_map> for PrivacyVisitor`
This fixes private statics and functions from being usable cross-crates, along
with some bad privacy error messages. This is a reopening of #8365 with all the
privacy checks in privacy.rs instead of resolve.rs (where they should be
anyway).
These maps of exported items will hopefully get used for generating
documentation by rustdoc
Closes#8592
This can cause unexpected errors in the runtime when done while
scheduler threads are still initializing. Required some restructuring
of the main_args functions in our libraries.
This can cause unexpected errors in the runtime when done while
scheduler threads are still initializing. Required some restructuring
of the main_args functions in our libraries.
This fixes private statics and functions from being usable cross-crates, along
with some bad privacy error messages. This is a reopening of #8365 with all the
privacy checks in privacy.rs instead of resolve.rs (where they should be
anyway).
These maps of exported items will hopefully get used for generating
documentation by rustdoc
Closes#8592
r? anyone
Also got rid of a bit of `@mut` allocation. (Though not the monster that is `@mut FnCtxt`; that case is documented already on #7081; if we attack it, it will probably be its own ticket, not part of #7081.)
