When cloning a stream, the data is already guaranteed to be in a consistent
state, so there's no need to perform a zeroing. This prevents segfaults as seen
in #15231Closes#15231
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
r? @alexcrichton
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
When cloning a stream, the data is already guaranteed to be in a consistent
state, so there's no need to perform a zeroing. This prevents segfaults as seen
in #15231Closes#15231
These forms return the pointer directly, rather than the added
indirection, indentation, and inefficiencies of the closures in
`.with_ref` and `.with_mut_ref`. The two closure functions are
deprecated.
Replace
foo(c_str.with_ref(|p| p))
c_str.with_ref(|p| {
foo(p);
bar(p);
})
with
foo(c_str.as_ptr())
let p = c_str.as_ptr();
foo(p);
bar(p);
This change does mean that one has to be careful to avoid writing `let p
= x.to_c_str().as_ptr();` since the `CString` will be freed at the end
of the statement. Previously, `with_ref` was used (and `as_ptr` avoided)
for this reason, but Rust has strongly moved away from closures to more
RAII-style code, and most uses of `.with_ref` where in the form
`.with_ref(|p| p)` anyway, that is, they were exactly `.as_ptr`.
[breaking-change]
Getting rust to build on windows can be a bit annoying in setting up all the toolchains and whatnot. The whole process is made much easier by using msys2 so let's document that prominently right on the README.
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
I believe that #5781 got fixed by the DST work. It duplicated the
variance inference work in #12828. Therefore, all that is left in #5781
is adding a test.
Closes#5781.
r? @huonw
This can break code that looked like:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any + Send> = ...;
x.f();
Change such code to:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any> = ...;
x.f();
That is, upcast before calling methods.
This is a conservative solution to #5781. A more proper treatment (see
the xfail'd `trait-contravariant-self.rs`) would take variance into
account. This change fixes the soundness hole.
Some library changes had to be made to make this work. In particular,
`Box<Any>` is no longer showable, and only `Box<Any+Send>` is showable.
Eventually, this restriction can be lifted; for now, it does not prove
too onerous, because `Any` is only used for propagating the result of
task failure.
This patch also adds a test for the variance inference work in #12828,
which accidentally landed as part of DST.
Closes#5781.
[breaking-change]
This PR includes two big things and a bunch of little ones.
1) It enables hygiene for variables bound by 'match' expressions.
2) It fixes a bug discovered indirectly (#15221), wherein fold traversal failed to visit nonterminal nodes.
3) It fixes a small bug in the macro tutorial.
It also adds tests for the first two, and makes a bunch of small comment improvements and cleanup.
... and possibly totally pointless. Specifically, fixing
these to make their macros hygienic may mean that they no
longer test the thing that they were supposed to test.
rustc: update the unnecessary parens lint for struct literals.
Things like `match X { x: 1 } { ... }` now need to be written with
parentheses, so the lint should avoid warning in cases like that.
This diff will look better once bors takes care of https://github.com/rust-lang/rust/pull/15183
@brson and I talked about it, and, if I commit this skeleton, I can submit PRs for each portion, without doing this silly "builds on previous PRs" stuff, and it shouldn't cause conflicts.
This lays out what I think the guide should cover, and in what order. I haven't picked a cohesive project yet that shows all this off, but I think this progression of concepts is appropriate.
