contains ref-bindings, do not permit any upcasting from the type of
the value being matched. Similarly, do not permit coercion in a `let`.
This is a [breaking-change] in that it closes a type hole that
previously existed, and in that coercion is not performed. You should
be able to work around the latter by converting:
```rust
let ref mut x: T = expr;
```
into
```rust
let x: T = expr;
let ref mut x = x;
```
Restricting coercion not to apply in the case of `let ref` or `let ref mut` is sort
of unexciting to me, but seems the best solution:
1. Mixing coercion and `let ref` or `let ref mut` is a bit odd, because you are taking
the address of a (coerced) temporary, but only sometimes. It's not syntactically evident,
in other words, what's going on. When you're doing a coercion, you're kind of
2. Put another way, I would like to preserve the relationship that
`equality <= subtyping <= coercion <= as-coercion`, where this is
an indication of the number of `(T1,T2)` pairs that are accepted by
the various relations. Trying to mix `let ref mut` and coercion
would create another kind of relation that is like coercion, but
acts differently in the case where a precise match is needed.
3. In any case, this is strictly more conservative than what we had
before and we can undo it in the future if we find a way to make
coercion mix with type equality.
The change to match I feel ok about but similarly unthrilled. There is
some subtle text already concerning whether to use eqtype or subtype
for identifier bindings. The best fix I think would be to always have
match use strict equality but use subtyping on identifier bindings,
but the comment `(*)` explains why that's not working at the moment.
As above, I think we can change this as we clean up the code there.
After this patch code like `let ref a = *"abcdef"` doesn't cause ICE anymore.
Required for #23121
There are still places in rustc_trans where pointers are always assumed to be thin. In particular, #19064 is not resolved by this patch.
This commit removes the reexports of `old_io` traits as well as `old_path` types
and traits from the prelude. This functionality is now all deprecated and needs
to be removed to make way for other functionality like `Seek` in the `std::io`
module (currently reexported as `NewSeek` in the io prelude).
Closes#23377Closes#23378
This commit removes the reexports of `old_io` traits as well as `old_path` types
and traits from the prelude. This functionality is now all deprecated and needs
to be removed to make way for other functionality like `Seek` in the `std::io`
module (currently reexported as `NewSeek` in the io prelude).
Closes#23377Closes#23378
This reverts commit aec67c2.
Closes#20012
This is temporarily rebased on #23245 as it would otherwise conflict, the last commit is the only one relevant to this PR though.
When investigating #22518, this chapter is really the only part that has `rand`, and the rest still works without it. We should have some examples like this, but for now, it's more important to be right than perfect.
As @alexcrichton says, this was really a libgreen thing, and isn't
relevant now.
As this removes a technically-public function, this is a
[breaking-change]
`uppercase` and `lowercase` are currently named `to_uppercase` and `to_lowercase`. Also adds a link to the `char` type documentation which has much more detail on these iterators.
These two borrowing examples were confusing/misleading. This changes it
to more clearly show how you _can_ borrow a box, and also uses & instead
of &*.
We don't use 'task' anymore, these are now threads.
Because this changes the name of a compiler option, this is
[breaking-change]
I think this is small enough to not need an RFC, nor a period of accepting both. If we want to take both for a while, I can change the patch.
The IP and socket address types all had `FromStr` implemented but the
implementations were not marked stable, nor was the error type returned ready to
be properly stabilized.
This commit marks the implementations of `FromStr` as stable and also renamed
the `ParseError` structure to `AddrParseError`. The error is now also an opaque
structure that cannot be constructed outside the standard library.
cc #22949
[breaking-change]
The IP and socket address types all had `FromStr` implemented but the
implementations were not marked stable, nor was the error type returned ready to
be properly stabilized.
This commit marks the implementations of `FromStr` as stable and also renamed
the `ParseError` structure to `AddrParseError`. The error is now also an opaque
structure that cannot be constructed outside the standard library.
cc #22949
[breaking-change]
As @alexcrichton says, this was really a libgreen thing, and isn't
relevant now.
As this removes a technically-public function, this is a
[breaking-change]
Conflicts:
src/libtest/lib.rs
This should solve issues #23115, #23469, and #23407.
As the title says, this is just a workaround. The underlying problem is that macro expansion can produce invalid spans. I've opened issue #23480 so we don't forget about that.
This should solve issues #23115, #23469, and #23407.
As the title says, this is just a workaround. The underlying problem is that macro expansion can produce invalid spans. I've opened issue #23480 so we don't forget about that.
`uppercase` and `lowercase` are currently named `to_uppercase` and `to_lowercase`.
Also adds a link to the `char` type documentation which has much more detail
on these iterators.
This commit stabilizes the `ErrorKind` enumeration which is consumed by and
generated by the `io::Error` type. The purpose of this type is to serve as a
cross-platform namespace to categorize errors into. Two specific issues are
addressed as part of this stablization:
* The naming of each variant was scrutinized and some were tweaked. An example
is how `FileNotFound` was renamed to simply `NotFound`. These names should not
show either a Unix or Windows bias and the set of names is intended to grow
over time. For now the names will likely largely consist of those errors
generated by the I/O APIs in the standard library.
* The mapping of OS error codes onto kinds has been altered. Coalescing no
longer occurs (multiple error codes become one kind). It is intended that each
OS error code, if bound, corresponds to only one `ErrorKind`. The current set
of error kinds was expanded slightly to include some networking errors.
This commit also adds a `raw_os_error` function which returns an `Option<i32>`
to extract the underlying raw error code from the `Error`.
Closes#16666
[breaking-change]
This commit stabilizes the `ErrorKind` enumeration which is consumed by and
generated by the `io::Error` type. The purpose of this type is to serve as a
cross-platform namespace to categorize errors into. Two specific issues are
addressed as part of this stablization:
* The naming of each variant was scrutinized and some were tweaked. An example
is how `FileNotFound` was renamed to simply `NotFound`. These names should not
show either a Unix or Windows bias and the set of names is intended to grow
over time. For now the names will likely largely consist of those errors
generated by the I/O APIs in the standard library.
* The mapping of OS error codes onto kinds has been altered. Coalescing no
longer occurs (multiple error codes become one kind). It is intended that each
OS error code, if bound, corresponds to only one `ErrorKind`. The current set
of error kinds was expanded slightly to include some networking errors.
This commit also adds a `raw_os_error` function which returns an `Option<i32>`
to extract the underlying raw error code from the `Error`.
* rustdoc was doubly appending the file name to the path of where to
generate the source files, meanwhile, the [src] hyperlinks were not
* Added a flag to rustdoc::html::render::clean_srcpath to ignore the
last path component, i.e. the file name itself to prevent the issue
* This also avoids creating directories with the same name as source
files, and it makes sure the link to `main.css` is correct as well.
Fixes#23192
