Change deprecation warning to indicate custom derive support was removed
I'm very new to Rust and the message was confusing to me (using nightly and not really sure if I was > 1.15 or not).
Fix short hand struct doc
Don't want to discredit @hngiang effort on this issue.
I just want to lend a hand to fix this issue #38830, it is a very nice feature and is seemingly completed.
Fixes#39096
r? @steveklabnik
Delete the makefile build system
This PR deletes the makefile build system in favor of the rustbuild build system. The beta has now been branched so 1.16 will continue to be buildable from the makefiles, but going forward 1.17 will only be buildable with rustbuild.
Rustbuild has been the default build system [since 1.15.0](https://github.com/rust-lang/rust/pull/37817) and the makefiles were [proposed for deletion](https://internals.rust-lang.org/t/proposal-for-promoting-rustbuild-to-official-status/4368) at this time back in November of last year.
And now with the deletion of these makefiles we can start getting those sweet sweet improvements of using crates.io crates in the compiler!
Add support for test suites emulated in QEMU
This commit adds support to the build system to execute test suites that cannot
run natively but can instead run inside of a QEMU emulator. A proof-of-concept
builder was added for the `arm-unknown-linux-gnueabihf` target to show off how
this might work.
In general the architecture is to have a server running inside of the emulator
which a local client connects to. The protocol between the server/client
supports compiling tests on the host and running them on the target inside the
emulator.
Closes#33114
A few ergonomic From impls for SocketAddr/IpAddr
My main motivation is removing things like this: `"127.0.0.1:3000".parse().unwrap()`. Instead, this now works: `SocketAddr::from(([127, 0, 0, 1], 3000))` or even `([127, 0, 0, 1], 3000).into())` when passing to a function.
Improve error message for uninferrable types #38812
Hello,
I tried to improve the error message for uninferrable types. The error code is `E0282`.
```rust
error[E0282]: type annotations needed
--> /home/cengizIO/issue38812.rs:2:11
|
2 | let x = vec![];
| - ^^^^^^ cannot infer type for `T`
| |
| consider giving `x` a type
|
= note: this error originates in a macro outside of the current crate
```
and
```rust
error[E0282]: type annotations needed
--> /home/cengizIO/issue38812.rs:2:15
|
2 | let (x,) = (vec![],);
| ---- ^^^^^^ cannot infer type for `T`
| |
| consider giving a type to pattern
|
= note: this error originates in a macro outside of the current crate
```
Rust compiler now tries to find uninferred `local`s with type `_` and adds them into the error message.
I'm probably wrong on wording that I used. Please feel free to suggest better alternatives.
Thanks @nikomatsakis for mentoring 🍺
Any comments/feedback is more than welcome!
Thank you
Ipv6Addr <-> u128
Because we have `u128` now, it makes sense to add a conversion between `Ipv6Addr` and `u128` in addition to the existing one between `Ipv4Addr` and `u32`.
This shouldn't violate the existing feature gate on `u128` because you can't use the type without the feature gate, but if i have to add something, I can.
Previously, `assert_eq!(left, right,)` (respectively, `assert_ne!(left,
right,)`; note the trailing comma) would result in a confusing "requires
at least a format string argument" error. In reality, a format string is
optional, but the trailing comma puts us into the "match a token tree of
zero or more tokens" branch of the macro (in order to support the
optional format string), and passing the empty token tree into
`format_args!` results in the confusing error. If instead we match a
token tree of one or more tokens, we get a much more sensible
"unexpected end of macro invocation" error.
While we're here, fix up a stray space before a comma in the match
guards.
Resolves#39369.
This is much nicer for callers who want to short-circuit real I/O errors
with `?`, because they can write this
if let Some(status) = foo.try_wait()? {
...
} else {
...
}
instead of this
match foo.try_wait() {
Ok(status) => {
...
}
Err(err) if err.kind() == io::ErrorKind::WouldBlock => {
...
}
Err(err) => return Err(err),
}
The original design of `try_wait` was patterned after the `Read` and
`Write` traits, which support both blocking and non-blocking
implementations in a single API. But since `try_wait` is never blocking,
it makes sense to optimize for the non-blocking case.
Tracking issue: https://github.com/rust-lang/rust/issues/38903
Revert "Add 128-bit atomics"
This reverts commit 9903975003.
Unfortunately 128-bit atomics have broken our nightly builds (#39590) and while we investigate I'm posting a temporary revert of the PR that added them. If we can figure out a solution though before this lands I'd be happy to close!
* Moved algorithm explanation to module docs
* Added ``` before and after the examples
* Explanation of the `rbox`, `ibox` and `cbox` names
* Added docs about the breaking types to `Breaks`
* Don't disambiguate if there are multiple impls for the same type.
* Disambiguate for impls of &Foo and &mut Foo.
* Don't try to disambiguate generic types.
* Add version info to channel.rs as main.mk is no longer available
* Update `Makefile.in` used with bootstrap to not try to require `mk/util.mk`
* Update the `dist` target to avoid the makefile pieces
