string: Add documentation for `From` impls
Hi this is part of #51430. I'm a first time contributor, so I started with a small task adding a bit of documentation for From impls.
Fix TLS errors when downloading stage0
While attempting to test #49878 on Windows I hit the following error when attempting to download stage0.
```
The request was aborted: Could not create SSL/TLS secure channel
```
Instead of using the shell, we can just use `urllib`, which seems to fix the issue.
Make PhantomData #[structural_match]
fixes https://github.com/rust-lang/rust/issues/55028
This makes `PhantomData<T>` structurally matchable, irrespective of whether `T` is, per the discussion on this week's language team meeting (the general consensus was that this was a bug-fix).
All types containing `PhantomData<T>` and which used `#[derive(PartialEq, Eq)]` and were previously not `#[structural_match]` only because of `PhantomData<T>` will now be `#[structural_match]`.
r? @nikomatsakis
rustdoc: don't inline `pub use some_crate` unless directly asked to
cc https://github.com/rust-lang/rust/issues/52509 (fixes it? i'm not sure about my comment summoning the docs team)
When rustdoc encounters a `pub use` statement for an item from another crate, it will eagerly inline its contents into your crate. This somewhat clashes with the new paths behavior in Rust 2018, in which crates are implicitly linked and re-exported with `pub use` instead of `pub extern crate`. In rust 2015, `pub extern crate` would only create a single line for its re-export in the docs, so i'm making it do the same with `pub use some_crate;`.
The exact new behavior is like this: *If rustdoc sees a `pub use` statement, and the item being imported is the root of another crate, it will only inline it if `#[doc(inline)]` is provided.* I made it only avoid crate roots because otherwise it would stop inlining any module, which may or may not be what people want.
Use read_unaligned instead of read in transmute_copy
Closes: #55044
This change could result in performance regression on non-x86 platforms. (but it also can fix some of UB which lurks in existing programs) An alternative would be to update `transmute_copy` documentation with alignment requirements.
When reading this I wondered what “some significant optimizations” referred to. As far as I can tell, the specialization of `.fuse()` is the only case where `FusedIterator` has any impact at all. Is this accurate @Stebalien?
Fix emission of niche-filling discriminant values
Bug #55606 points out a regression introduced by #54004; namely that
an assertion can erroneously fire when a niche-filling discriminant
value is emitted.
This fixes the bug by removing the assertion, and furthermore by
arranging for the discriminant value to be masked according to the
size of the niche. This makes handling the discriminant a bit simpler
for debuggers.
The test case is from Jonathan Turner.
Closes#55606
Make `MatcherPos::stack` a `SmallVec`.
This avoids some allocations.
This seems like a trivial change, but the compiler rejects it:
```
Compiling syntax v0.0.0 (/home/njn/moz/rust1/src/libsyntax)
error[E0597]: `initial` does not live long enough=========> ] 89/110: syntax
--> libsyntax/ext/tt/macro_parser.rs:647:57
|
647 | let mut cur_items = smallvec![MatcherPosHandle::Ref(&mut initial)];
| ^^^^^^^^^^^^ borrowed value does not live long enough
...
762 | }
| -
| |
| `initial` dropped here while still borrowed
| borrow later used here, when `initial` is dropped
error: aborting due to previous error
```
This is either a compiler bug, or there's some subtle thing I don't understand. The lifetimes sure seem straightforward: `initial` is declared, and then `cur_items` is declared immediately afterward, and it uses a reference to `initial`. The error message makes it sound like the compiler is dropping the variables in the wrong order.
r? @nikomatsakis, any idea what the problem is?
Remove the `alloc_system` crate
In what's hopefully one of the final nails in the coffin of the "old allocator story of yore" this PR deletes the `alloc_system` crate and all traces of it from the compiler. The compiler no longer needs to inject allocator crates anywhere and the `alloc_system` crate has no real reason to exist outside the standard library.
The unstable `alloc_system` crate is folded directly into the standard library where its stable interface, the `System` type, remains the same. All unstable traces of `alloc_system` are removed, however.
