| Age | Commit message (Collapse) | Author | Lines |
|
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
|
|
This closes issue #17021.
|
|
Closes #17773.
|
|
For example, this renames `GroupRWX` to `GROUP_RWX`, and deprecates the old
name. Code using these statics should be updated accordingly.
|
|
This causes it to hit the previously ICEing debuginfo codepath
|
|
Closes issue #17734
r? @nick29581
|
|
|
|
I'm not sure how to add an automated test for this.
|
|
|
|
|
|
This began as an attempt to fix an ICE in borrowck (issue #17655), but the rabbit hole went pretty deep. I ended up plumbing support for capture-by-reference unboxed closures all the way into trans.
Closes issue #17655.
|
|
|
|
|
|
|
|
|
|
This test works as a regression test for issue #17655. It also
exercises mutation of by-ref upvars.
|
|
Conflicts:
.travis.yml
|
|
This rewrites them to the current `ItemStatic` production of the compiler, but I
want to get this into a snapshot. It will be illegal to use a `static` in a
pattern of a `match` statement, so all those current uses will need to be
rewritten to `const` once it's implemented. This requires that the stage0
snapshot is able to parse `const`.
cc #17718
|
|
|
|
Conflicts:
src/libcollections/lib.rs
src/libcore/lib.rs
src/librustdoc/lib.rs
src/librustrt/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/test/run-pass/issue-8898.rs
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #17169.
Fixes #17649.
|
|
The bitshifts were wrong in that they invoked undefined behavior and
only passed the lower byte of the presumed-to-be-32bit errno value.
Apparently all actually possible values for errno happen to be easily
under 256, so this didn't cause any actual problems.
This commit fixes the bitshifts, but doesn't generalize to errno types
that aren't 32bit.
|
|
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
|
|
This reverts commit df2f1fa7680a86ba228f004e7de731e91a1df1fe.
|
|
This reverts commit 95cfc35607ccf5f02f02de56a35a9ef50fa23a82.
|
|
|
|
Fixes #17662.
|
|
[breaking-change]
If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
|
|
Deprecates slicing methods from ImmutableSlice/MutableSlice in favour of slicing syntax or the methods in Slice/SliceMut.
Closes #17273.
|
|
|
|
This commit removes the `iotest!` macro from `std::io`. The macro was
primarily used to ensure that all io-related tests were run on both
libnative and libgreen/librustuv. However, now that the librustuv stack
is being removed, the macro is no longer needed.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
[breaking-change]
|
|
|
|
Fixes that unit-like structs cannot be used if they are re-exported and used in another crate. (ICE)
The relevant changes are in `rustc::metadata::{decoder, encoder}` and `rustc::middle::ty`.
A test case is included.
The problem is that the expressoin `UnitStruct` is an `ExprPath` to an `DefFn`, which is of expr kind `RvalueDatumExpr`, but for unit-struct ctors the expr kind should be `RvalueDpsExpr`. I fixed this (in a I guess clean way) by introducing `CtorFn` in the metadata and including a `is_ctor` flag in `DefFn`.
|
|
r=nikomatsakis
prefer `Deref` over `DerefMut` in all other circumstances.
Because the compiler now prefers `Deref`, this can break code that
looked like:
let mut foo = bar.borrow_mut();
(*foo).call_something_that_requires_mutable_self();
Replace this code with:
let mut foo = bar.baz();
(&mut *foo).call_something_that_requires_mutable_self();
Closes #12825.
[breaking-change]
r? @nikomatsakis
|
|
This breaks code that looks like:
match foo {
1..3 => { ... }
}
Instead, write:
match foo {
1...3 => { ... }
}
Closes #17295.
r? @nick29581
|
|
|
|
prefer `Deref` over `DerefMut` in all other circumstances.
Closes #12825.
|
|
Fixes #17662.
|
|
|
|
|
|
This breaks code that looks like:
match foo {
1..3 => { ... }
}
Instead, write:
match foo {
1...3 => { ... }
}
Closes #17295.
[breaking-change]
|
|
Fixes that unit-like structs cannot be used if they are reexported and
used in another crate. The compiler fails with an ICE, because unit-like
structs are exported as DefFn and the expression `UnitStruct` is
interpreted as function pointer instead of a call to the constructor.
To resolve this ambiguity tuple-like struct constructors are now exported
as CtorFn. When `rustc::metadata::decoder` finds a CtorFn it sets a new
flag `is_ctor` in DefFn to true.
Relevant changes are in `rustc::metadata::{encoder, decoder}` and in
`rustc::middle::ty`.
Closes #12660 and #16973.
|
|
This is the bare minimum to stop using split stacks on Windows, fixing https://github.com/rust-lang/rust/issues/13259 and #14742, by turning on stack probes for all functions and disabling compiler and runtime support for split stacks on Windows.
It does not restore the out-of-stack error message, which requires more runtime work.
This includes a test that the Windows TCB is no longer being clobbered, but the out-of-stack test itself is pretty weak, only testing that the program exits abnormally, not that it isn't writing to bogus memory, so I haven't truly verified that this is providing the safety we claim.
A more complete solution is in https://github.com/rust-lang/rust/pull/16388, which has some unresolved issues yet.
cc @Zoxc @klutzy @vadimcn
|