Guillaume Gomez [Tue, 1 Dec 2020 22:46:09 +0000 (23:46 +0100)]
Rollup merge of #79508 - jryans:check-dsymutil-result, r=nagisa
Warn if `dsymutil` returns an error code
This checks the error code returned by `dsymutil` and warns if it failed. It
also provides the stdout and stderr logs from `dsymutil`, similar to the native
linker step.
I tried to think of ways to test this change, but so far I haven't found a good way, as you'd likely need to inject some nonsensical args into `dsymutil` to induce failure, which feels too artificial to me. Also, https://github.com/rust-lang/rust/issues/79361 suggests Rust is on the verge of disabling `dsymutil` by default, so perhaps it's okay for this change to be untested. In any case, I'm happy to add a test if someone sees a good approach.
bors [Tue, 1 Dec 2020 14:30:02 +0000 (14:30 +0000)]
Auto merge of #74967 - Aaron1011:feature/incr-def-path-table, r=pnkfelix
Implement lazy decoding of DefPathTable during incremental compilation
PR https://github.com/rust-lang/rust/pull/75813 implemented lazy decoding of the `DefPathTable` from crate metadata. However, it requires decoding the entire `DefPathTable` when incremental compilation is active, so that we can map a decoded `DefPathHash` to a `DefId` from an arbitrary crate.
This PR adds support for lazy decoding of dependency `DefPathTable`s when incremental compilation si active.
When we load the incremental cache and dep
graph, we need the ability to map a `DefPathHash` to a `DefId` in the
current compilation session (if the corresponding definition still
exists).
This is accomplished by storing the old `DefId` (that is, the `DefId`
from the previous compilation session) for each `DefPathHash` we need to
remap. Since a `DefPathHash` includes the owning crate, the old crate is
guaranteed to be the right one (if the definition still exists). We then
use the old `DefIndex` as an initial guess, which we validate by
comparing the expected and actual `DefPathHash`es. In most cases,
foreign crates will be completely unchanged, which means that we our
guess will be correct. If our guess is wrong, we fall back to decoding
the entire `DefPathTable` for the foreign crate. This still represents
an improvement over the status quo, since we can skip decoding the
entire `DefPathTable` for other crates (where all of our guesses were
correct).
bors [Tue, 1 Dec 2020 12:15:10 +0000 (12:15 +0000)]
Auto merge of #79596 - m-ou-se:rollup-hujx3c7, r=m-ou-se
Rollup of 11 pull requests
Successful merges:
- #79038 (Change ui test that are run-pass and that do not test the compiler to library tests)
- #79184 (Stop adding '*' at the end of slice and str typenames for MSVC case)
- #79227 (Remove const_fn_feature_flags test)
- #79444 (Move const ip in ui test to unit test)
- #79522 (Validate lint docs separately.)
- #79525 (Add -Z normalize-docs and enable it for compiler docs)
- #79527 (Move intra-doc link tests into a subdirectory)
- #79548 (Show since when a function is const in stdlib)
- #79568 (update Miri)
- #79573 (Update with status for various NetBSD ports.)
- #79583 (Update books)
5 commits in a7de763c213292f5b44bf10acb87ffa38724814d..a8afdca5d0715b2257b6f8b9a032fd4dd7dae855
2020-11-11 19:13:21 -0800 to 2020-11-30 06:44:46 -0800
- Describe relationship between reference and optimizers (rust-lang/reference#902)
- A simple missing space (rust-lang/reference#909)
- Cleanup formatting (rust-lang/reference#907)
- Use `doc`, not `test` for fn item inner attr example (rust-lang/reference#906)
- Update where our chat is. (rust-lang/reference#903)
4 commits in 1886fda6981b723e4de637074455558f8bc1e83c..236c734a2cb323541b3394f98682cb981b9ec086
2020-10-28 13:46:54 -0500 to 2020-11-30 14:05:49 -0300
- Update old invalid link (rust-lang/rust-by-example#1392)
- Moved "See also" link to the correct page. (rust-lang/rust-by-example#1389)
- Fix some markdown lint warnings (rust-lang/rust-by-example#1388)
- Minor grammar suggestion (rust-lang/rust-by-example#1386)
Mara Bos [Tue, 1 Dec 2020 10:50:25 +0000 (10:50 +0000)]
Rollup merge of #79573 - he32:master, r=jonas-schievink
Update with status for various NetBSD ports.
The NetBSD ports of rust to aarch64, armv7*, i686, and powerpc**
all both build and run. Status is as of rust 1.47.0.
*) Natively requires repeated successive build attempts (`rustc` is
such a resource pig VM-consumption-wise), or run in a chroot
on an aarch64 host where the available VM space is 4GB instead
of the native 2GB.
**) Powerpc either requires `-latomic` in a directory searched by
default by `ld` or to be built within pkgsrc which has a patch and
support package to tackle this issue.
Mara Bos [Tue, 1 Dec 2020 10:50:21 +0000 (10:50 +0000)]
Rollup merge of #79548 - CraftSpider:76998, r=jyn514
Show since when a function is const in stdlib
Fixes #76998
This makes it so that functions with the `#[rustc_const_stable()]` attribute now show from what version they were stably declared const, alongside what version they were declared stable. Example from `Result`:
![image](https://user-images.githubusercontent.com/13342132/100561194-1be60d00-3286-11eb-99ff-1e81201218a9.png)
Mara Bos [Tue, 1 Dec 2020 10:50:18 +0000 (10:50 +0000)]
Rollup merge of #79525 - jyn514:feature-gate-normalize, r=GuillaumeGomez
Add -Z normalize-docs and enable it for compiler docs
Works around https://github.com/rust-lang/rust/issues/79459 by only enabling normalization for the compiler itself (and anyone who opts-in on nightly). Eventually I want to remove this and enable normalization by default, but that's turned out to be [really hard](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20do.20I.20normalize.20projection.20types.20to.20a.20single.20type.3F/near/218125195).
This uses a command line option instead of a feature gate so it's easier to pass it to all crates at once. Theoretically it's better to use a feature gate instead so that it's easier for people to use on docs.rs, but I'm also not terribly concerned with how easy it to use a temporary hack.
Mara Bos [Tue, 1 Dec 2020 10:50:16 +0000 (10:50 +0000)]
Rollup merge of #79522 - ehuss:lint-check-validate, r=Mark-Simulacrum
Validate lint docs separately.
This addresses some concerns raised in https://github.com/rust-lang/rust/pull/76549#issuecomment-727638552 about errors with the lint docs being confusing and cumbersome. Errors from validating the lint documentation were being generated during `x.py doc` (and `x.py dist`), since extraction and validation are being done in a single step. This changes it so that extraction and validation are separated, so that `x.py doc` will not error if there is a validation problem, and tests are moved to `x.py test src/tools/lint-docs`.
This includes the following changes:
* Separate validation to `x.py test`.
* Added some more documentation on how to more easily modify and test the docs.
* Added more help to the error messages to hopefully provide more information on how to fix things.
The first commit just moves the code around, so you may consider looking at the other commits for a smaller diff.
Mara Bos [Tue, 1 Dec 2020 10:50:10 +0000 (10:50 +0000)]
Rollup merge of #79184 - nanguye2496:nanguye2496/fix_slice_and_str_type_name, r=varkor
Stop adding '*' at the end of slice and str typenames for MSVC case
When computing debug info for MSVC debuggers, Rust compiler emits C++ style type names for compatibility with .natvis visualizers. All Ref types are treated as equivalences of C++ pointers in this process, and, as a result, their type names end with a '\*'. Since Slice and Str are treated as Ref by the compiler, their type names also end with a '\*'. This causes the .natvis engine for WinDbg fails to display data of Slice and Str objects. We addressed this problem simply by removing the '*' at the end of type names for Slice and Str types.
Debug info in WinDbg before the fix:
![image](https://user-images.githubusercontent.com/74681961/99594120-9a4dcf80-29a7-11eb-8cce-aedaf1da6d21.png)
Debug info in WinDbg after the fix:
![image](https://user-images.githubusercontent.com/74681961/99597173-717c0900-29ac-11eb-861e-98143a9177cf.png)
This change has also been tested with debuggers for Visual Studio, VS Code C++ and VS Code LLDB to make sure that it does not affect the behavior of other kinds of debugger.
Mara Bos [Tue, 1 Dec 2020 10:50:02 +0000 (10:50 +0000)]
Rollup merge of #79038 - CDirkx:move-ui-tests, r=dtolnay
Change ui test that are run-pass and that do not test the compiler to library tests
Part of #76268, these are some of the relevant ui tests I found that can be replaced by library tests.
Note: this PR just moves the tests, I have not checked for any overlap between these tests and existing library tests. The only test I changed is `env_home_dir`, where I added code to restore the old home dir after testing.
bors [Tue, 1 Dec 2020 09:58:59 +0000 (09:58 +0000)]
Auto merge of #78876 - GuillaumeGomez:better-setting-keyboard-ux, r=jyn514
Make keyboard interactions in the settings menu more pleasant
#78868 improved the keyboard interactions with the settings page. This PR goes a bit further by allowing more than just "space" to toggle the checkboxes.
bors [Tue, 1 Dec 2020 04:53:38 +0000 (04:53 +0000)]
Auto merge of #78142 - operutka:armv5te-unknown-linux-uclibcgnueabi-target, r=petrochenkov
Add built-in support for the armv5te-unknown-linux-uclibcgnueabi target
Hi!
I'd like to add built-in support for the `armv5te-unknown-linux-uclibcgnueabi` target. It's a pretty common target used by many devices like routers and IP cameras. It's mostly a copy-paste of `armv5te-unknown-linux-gnueabi`. I've tested it on a quite complex application that uses tokio, openssl and a lot of other stuff and everything seems to be working fine.
I'm not sure about the `post_link_args` but the point is that my linker fails when `-ldl` isn't specified. Maybe there is a better place where to put this option...
It's my first contribution to Rust itself, so feel free to wash my head :smile:
_Note: The app mentioned above was built with this in my `.cargo/config`:_
```
[unstable]
build-std = ["core", "std", "alloc", "proc_macro", "panic_abort"]
build-std-features = ["panic_immediate_abort"]
```
Havard Eidnes [Mon, 30 Nov 2020 18:18:21 +0000 (19:18 +0100)]
Update with status for various NetBSD ports.
The NetBSD ports of rust to aarch64, armv7*, i686, and powerpc**
all both build and run.
*) Natively requires repeated successive build attempts (rustc is
such a resource pig VM-consumption-wise), or run in a chroot
on an aarch64 host where the available VM space is 4GB instead
of the native 2GB.
**) Powerpc either requires -latomic in a directory searched by
default by 'ld' or to be built within pkgsrc which has a patch
to tackle this.
J. Ryan Stinnett [Sat, 28 Nov 2020 15:09:18 +0000 (15:09 +0000)]
Warn if `dsymutil` returns an error code
This checks the error code returned by `dsymutil` and warns if it failed. It
also provides the stdout and stderr logs from `dsymutil`, similar to the native
linker step.
bors [Mon, 30 Nov 2020 09:00:52 +0000 (09:00 +0000)]
Auto merge of #76467 - jyn514:intra-link-self, r=Manishearth
Fix intra-doc links for `Self` on cross-crate items and primitives
- Remove the difference between `parent_item` and `current_item`; these
should never have been different.
- Remove `current_item` from `resolve` and `variant_field` so that
`Self` is only substituted in one place at the very start.
- Resolve the current item as a `DefId`, not a `HirId`. This is what
actually fixed the bug.
Hacks:
- `clean` uses `TypedefItem` when it _really_ should be
`AssociatedTypeItem`. I tried fixing this without success and hacked
around it instead (see comments)
- This second-guesses the `to_string()` impl since it wants
fully-qualified paths. Possibly there's a better way to do this.
bors [Mon, 30 Nov 2020 01:42:14 +0000 (01:42 +0000)]
Auto merge of #79329 - camelid:int-lit-suffix-error, r=davidtwco
Update error to reflect that integer literals can have float suffixes
For example, `1` is parsed as an integer literal, but it can be turned
into a float with the suffix `f32`. Now the error calls them "numeric
literals" and notes that you can add a float suffix since they can be
either integers or floats.
bors [Sun, 29 Nov 2020 23:14:40 +0000 (23:14 +0000)]
Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check, r=Mark-Simulacrum
Avoid panic_bounds_check in fmt::write.
Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary, because indexing used in fmt::write would generate code using panic_bounds_check, which prints the index and length.
These bounds checks are not necessary, as fmt::Arguments never contains any out-of-bounds indexes.
This change replaces them with unsafe get_unchecked, to reduce the amount of generated code, which is especially important for embedded targets.
---
Demonstration of the size of and the symbols in a 'hello world' no_std binary:
After:
```
text data bss dec hex filename
3068 600 8 3676 e5c after
```
``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip<A,B>::new 0000000000001660 t core::iter::adapters::zip::Zip<A,B>::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str
```
bors [Sun, 29 Nov 2020 18:50:19 +0000 (18:50 +0000)]
Auto merge of #79523 - Nadrieril:fix-usize-ranges, r=varkor
Fix overlap detection of `usize`/`isize` range patterns
`usize` and `isize` are a bit of a special case in the match usefulness algorithm, because the range of values they contain depends on the platform. Specifically, we don't want `0..usize::MAX` to count as an exhaustive match (see also [`precise_pointer_size_matching`](https://github.com/rust-lang/rust/issues/56354)). The way this was initially implemented is by treating those ranges like float ranges, i.e. with limited cleverness. This means we didn't catch the following as unreachable:
```rust
match 0usize {
0..10 => {},
10..20 => {},
5..15 => {}, // oops, should be detected as unreachable
_ => {},
}
```
This PRs fixes this oversight. Now the only difference between `usize` and `u64` range patterns is in what ranges count as exhaustive.
Joshua Nelson [Tue, 8 Sep 2020 04:07:40 +0000 (00:07 -0400)]
Fix intra-doc links for `Self` on primitives
- Remove the difference between `parent_item` and `current_item`; these
should never have been different.
- Remove `current_item` from `resolve` and `variant_field` so that
`Self` is only substituted in one place at the very start.
- Resolve the current item as a `DefId`, not a `HirId`. This is what
actually fixed the bug.
Hacks:
- `clean` uses `TypedefItem` when it _really_ should be
`AssociatedTypeItem`. I tried fixing this without success and hacked
around it instead (see comments)
- This stringifies DefIds, then resolves them a second time. This is
really silly and rustdoc should just use DefIds throughout. Fixing
this is a larger task than I want to take on right now.
bors [Sun, 29 Nov 2020 16:39:23 +0000 (16:39 +0000)]
Auto merge of #79482 - faern:bump-dependencies-invalidly-assuming-mem-layout, r=Mark-Simulacrum
Bump dependencies invalidly assuming memory layout of SocketAddr
Bumps net2, socket2 and miow.
Helps unblock #78802
Done as separate PR since frequent lockfile collisions is a thing... And since the main PR can't be merged until large parts of the ecosystem uses the newer crates only, so we have to start somewhere.
bors [Sun, 29 Nov 2020 14:29:23 +0000 (14:29 +0000)]
Auto merge of #78380 - bstrie:rm-old-num-const-from-tests, r=jyn514
Update tests to remove old numeric constants
Part of #68490.
Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.
For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.
bors [Sun, 29 Nov 2020 11:37:44 +0000 (11:37 +0000)]
Auto merge of #77616 - jyn514:no-normalize, r=lcnr
Don't run `resolve_vars_if_possible` in `normalize_erasing_regions`
Neither `@eddyb` nor I could figure out what this was for. I changed it to `assert_eq!(normalized_value, infcx.resolve_vars_if_possible(&normalized_value));` and it passed the UI test suite.
<details><summary>
Outdated, I figured out the issue - `needs_infer()` needs to come _after_ erasing the lifetimes
</summary>
Strangely, if I change it to `assert!(!normalized_value.needs_infer())` it panics almost immediately:
```
query stack during panic:
#0 [normalize_generic_arg_after_erasing_regions] normalizing `<str::IsWhitespace as str::pattern::Pattern>::Searcher`
#1 [needs_drop_raw] computing whether `str::iter::Split<str::IsWhitespace>` needs drop
#2 [mir_built] building MIR for `str::<impl str>::split_whitespace`
#3 [unsafety_check_result] unsafety-checking `str::<impl str>::split_whitespace`
#4 [mir_const] processing MIR for `str::<impl str>::split_whitespace`
#5 [mir_promoted] processing `str::<impl str>::split_whitespace`
#6 [mir_borrowck] borrow-checking `str::<impl str>::split_whitespace`
#7 [analysis] running analysis passes on this crate
end of query stack
```
I'm not entirely sure what's going on - maybe the two disagree?
</details>
For context, this came up while reviewing https://github.com/rust-lang/rust/pull/77467/ (cc `@lcnr).`
bors [Sun, 29 Nov 2020 09:28:09 +0000 (09:28 +0000)]
Auto merge of #78863 - KodrAus:feat/simd-array, r=oli-obk
Support repr(simd) on ADTs containing a single array field
This is a squash and rebase of `@gnzlbg's` #63531
I've never actually written code in the compiler before so just fumbled my way around until it would build 😅
I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now, but might need some input from `@bjorn3` to know what that is.
cc `@rust-lang/project-portable-simd`
-----
This PR allows using `#[repr(simd)]` on ADTs containing a single array field:
bstrie [Sat, 24 Oct 2020 23:21:40 +0000 (19:21 -0400)]
Update tests to remove old numeric constants
Part of #68490.
Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.
For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.
bors [Sun, 29 Nov 2020 04:54:20 +0000 (04:54 +0000)]
Auto merge of #75752 - jakoschiko:test-suite-time, r=m-ou-se
libtest: Print the total time taken to execute a test suite
Print the total time taken to execute a test suite by default, without any kind of flag.
Closes #75660
# Example
```
anon@anon:~/code/rust/example$ cargo test
Compiling example v0.1.0 (/home/anon/code/rust/example)
Finished test [unoptimized + debuginfo] target(s) in 0.18s
Running target/debug/deps/example-745b64d3885c3565
running 3 tests
test tests::foo ... ok
test tests::bar ... ok
test tests::baz ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s
Doc-tests example
running 3 tests
test src/lib.rs - foo (line 3) ... ok
test src/lib.rs - bar (line 11) ... ok
test src/lib.rs - baz (line 19) ... ok
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s
```
```
anon@anon:~/code/rust/example$ cargo test -- --format terse
Finished test [unoptimized + debuginfo] target(s) in 0.08s
Running target/debug/deps/example-745b64d3885c3565
running 3 tests
...
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.2s
Doc-tests example
running 3 tests
...
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; 1.3s
```
bors [Sun, 29 Nov 2020 02:45:48 +0000 (02:45 +0000)]
Auto merge of #79529 - Dylan-DPC:rollup-6k20msr, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #79327 (Require allocator to be static for boxed `Pin`-API)
- #79340 (Rename "stability" CSS class to "item-info" and combine `document_stability` with `document_short`)
- #79363 (BTreeMap: try to enhance various comments)
- #79395 (Move ui if tests from top-level into `expr/if`)
- #79443 (Improve rustdoc JS tests error output)
- #79464 (Extend doc keyword feature by allowing any ident)
- #79484 (add enable-full-tools to freebsd builds to prevent occasional link er…)
- #79505 (Cleanup: shorter and faster code)
- #79514 (Add test for issue #54121: order dependent trait bounds)
- #79516 (Remove unnecessary `mut` binding)
- #79528 (Fix a bootstrap comment)
Dylan DPC [Sun, 29 Nov 2020 02:14:26 +0000 (03:14 +0100)]
Rollup merge of #79514 - Julian-Wollersberger:order-dependent-bounds, r=Mark-Simulacrum
Add test for issue #54121: order dependent trait bounds
This adds a test for #54121, which has already been fixed by #73905. Now that issue can be closed.
I tested the test [on the playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6cb061d3b81518f268649551eb67769f) where it indeed fails on stable 1.48, but compiles successfully on beta and nightly.
Dylan DPC [Sun, 29 Nov 2020 02:14:22 +0000 (03:14 +0100)]
Rollup merge of #79484 - sreehax:master, r=Mark-Simulacrum
add enable-full-tools to freebsd builds to prevent occasional link er…
On FreeBSD, there is sometimes an issue where linking a rust program will fail due to rust not finding a linker, even though lld is included in the base system. This seems to mostly affect bare metal/cross compilation things, such as wasm builds and arm/riscv bare metal work (eg. when trying to compile [this](https://github.com/quantumscraps/scraps)). On Linux and other operating systems, full tools are enabled for builds of rust, so there are no linking issues. This pr should enable fully functional builds on FreeBSD, assuming rust builds correctly with these options.
Dylan DPC [Sun, 29 Nov 2020 02:14:21 +0000 (03:14 +0100)]
Rollup merge of #79464 - GuillaumeGomez:doc-keyword-ident, r=jyn514
Extend doc keyword feature by allowing any ident
Part of #51315.
As suggested by ``@danielhenrymantilla`` in [this comment](https://github.com/rust-lang/rust/issues/51315#issuecomment-733879934), this PR extends `#[doc(keyword = "...")]` to allow any ident to be used as keyword. The final goal is to allow (proc-)macro crates' owners to write documentation of the keywords they might introduce.
Dylan DPC [Sun, 29 Nov 2020 02:14:19 +0000 (03:14 +0100)]
Rollup merge of #79443 - GuillaumeGomez:improve-rustdoc-js-error-output, r=jyn514
Improve rustdoc JS tests error output
It's pretty common when starting to add new tests for rustdoc-js to have issues to understand the errors. With this, it should make things a bit simpler. So now, in case of an error, it displays:
error: rustdoc-js test failed!
failed to decode compiler output as json: line: {
output: Checking "basic" ... FAILED
==> Result not found in 'others': '{"path":"basic","name":"Fo"}'
Diff of first error:
{
"path": "basic",
- "name": "Fo",
+ "name": "Foo",
}
thread '[js-doc-test] rustdoc-js/basic.rs' panicked at 'explicit panic', src/tools/compiletest/src/json.rs:126:21
```
I think it was ``@camelid`` who asked about it a few days ago?
Dylan DPC [Sun, 29 Nov 2020 02:14:07 +0000 (03:14 +0100)]
Rollup merge of #79327 - TimDiekmann:static-alloc-pin-in-box, r=Mark-Simulacrum
Require allocator to be static for boxed `Pin`-API
Allocators has to retain their validity until the instance and all of its clones are dropped. When pinning a value, it must live forever, thus, the allocator requires a `'static` lifetime for pinning a value. [Example from reddit](https://www.reddit.com/r/rust/comments/jymzdw/the_story_continues_vec_now_supports_custom/gd7qak2?utm_source=share&utm_medium=web2x&context=3):
```rust
let alloc = MyAlloc(/* ... */);
let pinned = Box::pin_in(42, alloc);
mem::forget(pinned); // Now `value` must live forever
// Otherwise `Pin`'s invariants are violated, storage invalidated
// before Drop was called.
// borrow of `memory` can end here, there is no value keeping it.
drop(alloc); // Oh, value doesn't live forever.
```
Jonas Schievink [Sat, 28 Nov 2020 14:58:26 +0000 (15:58 +0100)]
Rollup merge of #79476 - bjorn3:sync_cg_clif-2020-11-27, r=bjorn3
Sync rustc_codegen_cranelift
This implements a few extra simd intrinsics, fixes yet another 128bit bug and updates a few dependencies. It also fixes an cg_clif subtree update that did compile, but that caused a panic when compiling libcore. Other than that this is mostly cleanups.
Jonas Schievink [Sat, 28 Nov 2020 14:58:19 +0000 (15:58 +0100)]
Rollup merge of #79344 - JRF63:fix_install_script_win, r=Mark-Simulacrum
Convert UNC path to local path to satisfy install script on Windows
`mkdir` with the `-p` flag attempts to create `//?` if passed a UNC path. This fails on both MSYS2 and Git Bash.
The UNC paths come from [canonicalizing](https://github.com/rust-lang/rust/blob/32da90b431919eedb3e281a91caea063ba4edb77/src/bootstrap/install.rs#L79) the install prefix path. `mkdir -p` gets invoked on the [install script](https://github.com/rust-lang/rust-installer/blob/d66f476b4d5e7fdf1ec215c9ac16c923dc292324/install-template.sh#L149).
Jonas Schievink [Sat, 28 Nov 2020 14:58:17 +0000 (15:58 +0100)]
Rollup merge of #79234 - ortem:fix-hashmap-pretty-printers, r=Mark-Simulacrum
Resolve typedefs in HashMap gdb/lldb pretty-printers
`GetTypedefedType` (LLDB) and `strip_typedefs` (GDB) calls are needed to resolve key and value types completely.
Without these calls, debugger doesn't show the actual type.
Jonas Schievink [Sat, 28 Nov 2020 14:58:15 +0000 (15:58 +0100)]
Rollup merge of #78853 - calebcartwright:fix-const-block-expr-span, r=spastorino
rustc_parse: fix ConstBlock expr span
The span for a ConstBlock expression should presumably run through the end of the block it contains and not stop at the keyword, just like is done with similar block-containing expression kinds, such as a TryBlock