The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.
This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.
cc #23533
The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro
Don't allow upcasting to a supertype in the type of the match discriminant. Fixes#23116.
This is a [breaking-change] in that it closes a type hole that previously existed.
r? @pnkfelix
This commit:
* Introduces `std::convert`, providing an implementation of
RFC 529.
* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.
Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.
* Deprecates many `from_foo` constructors in favor of `from`.
* Changes `PathBuf::new` to take no argument (creating an empty buffer,
as per convention). The previous behavior is now available as
`PathBuf::from`.
* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.
Closes#22751Closes#14433
[breaking-change]
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.
Boolean values and small aggregates have a different type in args/allocas than
in SSA values but the intrinsics for volatile and atomic ops were
missing the necessary casts to handle that.
Fixes#23550
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.
The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.
Boolean values and small aggregates have a different type in
args/allocas than in SSA values but the intrinsics for volatile and
atomic ops were missing the necessary casts to handle that.
Fixes#23550
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.
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.
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.
* 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
Require braces when a closure has an explicit return type. This is a [breaking-change]: instead of a closure like `|| -> i32 22`, prefer `|| -> i32 { 22 }`.
Fixes#23420.
