This commit moves `std::env` away from the `std::old_io` error type as well as
the `std::old_path` module. Methods returning an error now return `io::Error`
and methods consuming or returning paths use `std::path` instead of
`std::old_path`. This commit does not yet mark these APIs as `#[stable]`.
This commit also migrates `std::old_io::TempDir` to `std::fs::TempDir` with
essentially the exact same API. This type was added to interoperate with the new
path API and has its own `tempdir` feature.
Finally, this commit reverts the deprecation of `std::os` APIs returning the old
path API types. This deprecation can come back once the entire `std::old_path`
module is deprecated.
[breaking-change]
Specifically, the following actions were taken:
* The `copy_memory` and `copy_nonoverlapping_memory` functions
to drop the `_memory` suffix (as it's implied by the functionality). Both
functions are now marked as `#[stable]`.
* The `set_memory` function was renamed to `write_bytes` and is now stable.
* The `zero_memory` function is now deprecated in favor of `write_bytes`
directly.
* The `Unique` pointer type is now behind its own feature gate called `unique`
to facilitate future stabilization.
* All type parameters now are `T: ?Sized` wherever possible and new clauses were
added to the `offset` functions to require that the type is sized.
[breaking-change]
I tried to follow [the style guide][1] as much as possible. This is just from some random readings of the code, so no guarantees on completeness, even in the edited files.
[1]: http://aturon.github.io/style/README.html
This affects the `set_non_blocking` function which cannot fail for Unix or
Windows, given correct parameters. Additionally, the short UDP write error case
has been removed as there is no such thing as \"short UDP writes\", instead, the
operating system will error out if the application tries to send a packet
larger than the MTU of the network path.
Tests often use `vec![1, 2, 3]` instead of shorter and faster `[1, 2, 3]`.
This patch removes a lot of unnecessary `vec!`s. Hopefully, the tests will compile and run a bit faster.
report are not *necessary* cycles, but we'll work on refactoring them
over time. This overlaps with the cycle detection that astconv already
does: I left that code in because it gives a more targeted error
message, though perhaps less helpful in that it doesn't give the full
details of the cycle.
Fixes#22525
I wasn't sure if I should reuse `write::get_llvm_opt_level` or not. It returns an `llvm::CodeGenOptLevel`, which is the Rust binding for `CodeGenOpt::Level`. `lto.rs` is passing an optlevel to LLVM's `PassManagerBuilder`, which takes an unsigned int. `PassManagerBuilder`'s optlevel uses essentially the same enumeration (i.e. 0-3 with 2 as default), but it's implicit.
Adds `<module::Type>::method` support and makes `module::Type::method` a shorthand for it.
This is most of #16293, except that chaining multiple associated types is not yet supported.
It also fixes#22563 as `impl`s are no longer treated as modules in resolve.
Unfortunately, this is still a *[breaking-change]*:
* If you used a global path to a primitive type, i.e. `::bool`, `::i32` etc. - that was a bug I had to fix.
Solution: remove the leading `::`.
* If you passed explicit `impl`-side type parameters to an inherent method, e.g.:
```rust
struct Foo<T>(T);
impl<A, B> Foo<(A, B)> {
fn pair(a: A, b: B) -> Foo<(A, B)> { Foo((a, b)) }
}
Foo::<A, B>::pair(a, b)
// Now that is sugar for:
<Foo<A, B>>::pair(a, b)
// Which isn't valid because `Foo` has only one type parameter.
// Solution: replace with:
Foo::<(A, B)>::pair(a, b)
// And, if possible, remove the explicit type param entirely:
Foo::pair(a, b)
```
* If you used the `QPath`-related `AstBuilder` methods @hugwijst added in #21943.
The methods still exist, but `QPath` was replaced by `QSelf`, with the actual path stored separately.
Solution: unpack the pair returned by `cx.qpath` to get the two arguments for `cx.expr_qpath`.
Also, to ensure we do not let the dropck get skipped, ICE if cat_expr
errors when *not* in error state.
This is not known to be a breaking change (i.e. I do not know of a
current case that causes the new ICE to be exercised).
