This optimizes `read` for the case in which the number of bytes
requested is larger than the internal buffer. Note that the first
comparison occurs again right afterwards and should thus be free. The
second comparison occurs only in the cold branch.
This optimizes `read` for the case in which the number of bytes
requested is larger than the internal buffer. Note that the first
comparison occurs again right afterwards and should thus be free. The
second comparison occurs only in the cold branch.
Fix for issue #18091
The problem seems to be that `ast_util::int_ty_to_string` takes unsigned number, and no one adds `-` to result string. I've fixed it by putting `-` before result string using `format!`.
I've also added `test_signed_int_to_string()` to check if implementation is valid.
Spring cleaning is here! In the Fall! This commit removes quite a large amount
of deprecated functionality from the standard libraries. I tried to ensure that
only old deprecated functionality was removed.
This is removing lots and lots of deprecated features, so this is a breaking
change. Please consult the deprecation messages of the deleted code to see how
to migrate code forward if it still needs migration.
[breaking-change]
All of these crates have been deprecated for some time and properly live in the
rust-lang organization as cargo-based crates.
To update your code, depend on the rust-lang/foo repository via cargo.
[breaking-change]
Use a match expression directly in the println statement, instead of creating a second variable. It seems weird that the current guide.md complains about creating an extra variable, when the same feature could be demonstrated without creating the extra variable.
When translating the unboxing shim, account for the fact that the shim translation has already performed the necessary unboxing of input types and values when forwarding to the shimmed function. This prevents ICEing or generating incorrect code.
Closes#16739
Check object lifetime bounds in coercions, not just trait bounds. Fixes#18055.
r? @pcwalton
This is a [breaking change]. Change code like this:
fn foo(v: &[u8]) -> Box<Clone+'static> { ... }
to make the lifetimes agree:
// either...
fn foo(v: &'static[u8]) -> Box<Clone+'static> { box v }
// or ...
fn foo<'a>(v: &'a [u8]) -> Box<Clone+'a> { box v }
Make the doc more consistent & runnable.
* Use `_index` instead of `_rhs` when appropriate.
* Use `_from` and `_to` to avoid warning.
* Remove unnecessary `::core::ops`
The representability-checking routine ```is_type_representable``` failed to detect structural recursion in some cases, leading to stack overflow later on.
The first problem was in the loop in the ```find_nonrepresentable``` function. We were improperly terminating the iteration if we saw a ```ContainsRecursive``` condition. We should have kept going in case a later member of the struct (or enum, etc) being examined was ```SelfRecursive```. The example from #17431 triggered this issue:
```rust
use std::sync::Mutex;
struct Foo { foo: Mutex<Option<Foo>> }
impl Foo { fn bar(self) {} }
fn main() {}
```
I'm not 100% sure, but I think the ```ty_enum``` case of ```fn type_structurally_recursive``` had a similar problem, since it could ```break``` on ```ContainsRecursive``` before looking at all variants. I've replaced this with a ```flat_map``` call.
The second problem was that we were failing to identify code like ```struct Foo { foo: Option<Option<Foo>> }``` as SelfRecursive, even though we correctly identified ```struct Foo { foo: Option<Foo> }```. This was caused by using DefId's for the ```ContainsRecursive``` check, which meant the nested ```Option```s were identified as illegally recursive (because ```ContainsRecursive``` is not an error, we would then keep compiling and eventually hit a stack overflow).
In order to make sure that we can recurse through the different ```Option``` invocations, I've changed the type of ```seen``` from ```Vec<DefId>``` to ```Vec<t>``` and added a separate ```same_type``` function to check whether two types are the same when generics are taken into account. Now we only return ```ContainsRecursive``` when this stricter check is satisfied. (There's probably a better way to do this, and I'm not sure my code is entirely correct--but my knowledge of rustc internals is pretty limited, so any help here would be appreciated!)
Note that the ```SelfRecursive``` check is still comparing ```DefId```s--this is necessary to prevent code like this from being allowed:
```rust
struct Foo { x: Bar<Foo> }
struct Bar<T> { x: Bar<Foo> }
```
All four of the new ```issue-17431``` tests cause infinite recursion on master, and errors with this pull request. I wrote the extra ```issue-3008-4.rs``` test to make sure I wasn't introducing a regression.
Fixes#17431.
When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.
Related to #13728.
This adds ‘help’ diagnostic messages to rustc. This is used for anything that provides help to the user, particularly the `--explain` messages that were previously integrated into the relevant error message.
They look like this:
```
match.rs:10:13: 10:14 error: unreachable pattern [E0001]
match.rs:10 1 => {},
^
match.rs:3:1: 3:38 note: in expansion of foo!
match.rs:7:5: 20:2 note: expansion site
match.rs:10:13: 10:14 help: pass `--explain E0001` to see a detailed explanation
```
(`help` is coloured cyan.) Adding these errors on a separate line stops the lines from being too long, as discussed in #16619.
detected (correctly) that there was only one impl and hence ignored the
`Self` bound completely. I (semi-arbitrarily) elected to delect the
impl, forcing the trait matcher to be more conservative and lean on the
where clauses in scope, yielding the original error message.
On 32-bit architectures, the size calculations on two of the tests wrap-around
in typeck, which gives the relevant arrays a size of 0, which is (correctly)
successfully allocated.
I was going to write some doc in order to remove the #[allow(missing_doc)] but there was actually none missing.
I also removed a warning i didn't see in my last commit #18018
Linked to #18009
This is some improvement as asked and discused here: http://www.reddit.com/r/rust/comments/2j2ij3/benchmark_improvement_reverse_compliment/
Before:
```
real 0m0.396s
user 0m0.280s
sys 0m0.112s
```
after:
```
real 0m0.293s
user 0m0.216s
sys 0m0.076s
```
best C version:
```
real 0m0.135s
user 0m0.132s
sys 0m0.060s
```
Another possibility will be to add a `DoubleEndedIterator::next_two_side()` with a deffault implementation, and specialising it for slices, and use it here (`MutableSlice::reverse()` can then become safe). This benchmark will then be safe.
What do you think?
When translating the unboxing shim, account for the fact that the shim
translation has already performed the necessary unboxing of input
types and values when forwarding to the shimmed function. This
prevents ICEing or generating incorrect code.
Closes#16739
This PR is based on #17784, which fixes closure soundness problems in borrowck. Only the last two commits are unique to this PR.
My understanding of regionck is still evolving, so I'm not sure if this is the right approach. Feedback is appreciated.
- In `link_reborrowed_region`, we account for the ability of upvars to
change their mutability due to later processing. A map of recursive
region links we may want to establish in the future is maintained,
with the links being established when the mutability of the borrow
is adjusted.
- When asked to establish a region link for an upvar, we link it to
the region of the closure body. This creates the necessary
constraint to stop unsound reborrows from the closure environment.
This partially (maybe completely) solves issue #17403. Remaining work:
- This is only known to help with by-ref upvars. I have not looked at
by-value upvars yet to see if they can cause problems.
- The error diagnostics that result from failed region inference are
pretty inscrutible.
When an overloaded call expression has parameters but the function
object takes none, construct an array of formal argument types with
the arity of the call expression so that we don't fail by indexing out
of bounds later.
Closes#16939
