Update cargo, rls
## cargo
17 commits in ebda5065ee8a1e46801380abcbac21a25bc7e755..8751eb3010d4cdb5329b5a6bd2b6d765c95b0dca
2020-04-16 14:28:43 +0000 to 2020-04-21 18:04:35 +0000
- Uplift windows gnu DLL import libraries. (rust-lang/cargo#8141)
- Add windows-gnu CI and fix tests (rust-lang/cargo#8139)
- Several updates to token/index handling. (rust-lang/cargo#7973)
- Add `resolver` opt-in for new feature resolver. (rust-lang/cargo#8129)
- Improve error message when running `cargo install .` (rust-lang/cargo#8137)
- fix mem replace unused (rust-lang/cargo#8138)
- Change `-Cembed-bitcode=no` use to `-Cbitcode-in-rlib=no`. (rust-lang/cargo#8134)
- Refactor BuildContext (rust-lang/cargo#8068)
- Rename allows_underscores to allows_dashes. (rust-lang/cargo#8135)
- Fixed a needless borrow. (rust-lang/cargo#8130)
- Add link to changelog in the Cargo book. (rust-lang/cargo#8126)
- Fix target for doc test cross compilation (rust-lang/cargo#8094)
- Add note about .cargo/config support. (rust-lang/cargo#8125)
- Fix pdb uplift when executable has dashes. (rust-lang/cargo#8123)
- Hint upgrading for future edition keys (rust-lang/cargo#8122)
- Use some fs shorthand functions. (rust-lang/cargo#8124)
- Update documentation to mention "config.toml" instead of "config" (rust-lang/cargo#8121)
## rls
1 commits in 2659cbf14bfb0929a16d7ce9b6858d0bb286ede7..7de2a1f299f8744ffe109139f9f1fdf28bfec909
2020-04-14 22:07:24 +0200 to 2020-04-19 22:41:55 +0000
- Update cargo (rust-lang-nursery/rls#1663)
attempt to recover perf by removing `exports_all_green`
attempt to recover perf by removing `exports_all_green` flag.
cc #71248
(My hypothesis is that my use of this flag was an overly conservative generalization of PR #67020.)
Rollup of 4 pull requests
Successful merges:
- #69362 (Stabilize most common subset of alloc_layout_extras)
- #71174 (Check that main/start is not async)
- #71285 (MIR: use HirId instead of NodeId to avoid cycles while inlining)
- #71346 (Do not build tools if user do not want them)
Failed merges:
r? @ghost
MIR: use HirId instead of NodeId to avoid cycles while inlining
I wanted to see if I could limit the number of uses of `NodeId` when `HirId` is available and I saw that some of the MIR `Inliner` code could use `Span` instead of `NodeId`, not unlike in https://github.com/rust-lang/rust/pull/71197.
~If I'm understanding the reason for not calling `optimized_mir` in incremental builds here correctly, this change could also allow us to do so.~
This change could affect performance, so if this approach makes sense, a perf run is probably a good idea.
Check that main/start is not async
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
This PR fixes#68523.
Stabilize most common subset of alloc_layout_extras
Tracking issue: https://github.com/rust-lang/rust/issues/55724
Specifically, this stabilizes:
```rust
pub fn Layout::align_to(&self, align: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::pad_to_align(&self) -> Layout;
pub fn Layout::extend(&self, next: Layout) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::array<T>(n: usize) -> Result<Layout, LayoutErr>;
```
Methods that are tracked by #55724 but are not stabilized here:
```rust
pub fn Layout::padding_needed_for(&self, align: usize) -> usize;
pub fn Layout::repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub fn Layout::repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub fn Layout::extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;
```
Combined, these stabilized functions allow code to construct and manipulate `repr(C)` layouts while letting the standard library handle correctness in the face of edge cases. For example use cases, consider the usage in [hashbrown](https://github.com/Amanieu/hashbrown/blob/2f2af1d/src/raw/mod.rs#L143), [crossbeam-skiplist](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99), [pointer-utils/slice-dst](92aeefeed9/crates/slice-dst/src/layout_polyfill.rs), and of course the standard library itself.
Providing a higher-level API such as `Layout::repr_c<const N: usize>(fields: [Layout; N]) -> Result<(Layout, [usize; N]), LayoutErr>` is blocked on const generics, which are a ways off. Providing an API that doesn't provide offsets would be quite suboptimal, as the reason for calculating the layout like this rather than `Layout::new` is to get the field offsets.
The primary issue with the current API is having to call `.pad_to_align()` to match the layout of a `repr(C)` struct. However, I think this is not just a (failing? limitation?) of the API, but rather intrinsic complexity. While all Rust-defined types have size==stride, and probably will for the foreseeable future, there is no inherent reason why this is a limitation of all allocations. As such, the `Layout` manipulation APIs shouldn't impose this limitation, and instead the higher level api of `repr_c` (or just plain old using `Layout::new`) can make keeping it simple.
cc @matklad r? @rust-lang/libs
Update pattern docs.
A few changes to help clarify string pattern usage:
* Add some examples and stability information in the `pattern` module.
* Fixes the links at https://doc.rust-lang.org/std/str/pattern/ because intra-doc-links don't work with re-exported modules (#65983 I think?).
* Consistently use the same phrasing for `str` methods taking a pattern.
* Also mention that array of `char` is also accepted.
When `Pattern` is stabilized, the phrasing in the `str` methods can be updated to be more general to reflect the exact behavior. I'm reluctant to do this now because the stability story for `Pattern` is uncertain. It may perhaps look something like:
> The pattern can be any type that implements the [`Pattern`] trait. Notable examples are `&str`, [`char`], arrays of [`char`], or functions or closures that determines if a character matches. Additional libraries might provide more complex patterns like regular expressions.
This is complicated because methods like `trim_matches` have bounds, which for example don't support `str`, so those methods may need more elaboration.
Replace big JS dict with JSON parsing
Part of #56545.
@ollie27 suggested that using JSON instead of a JS dict might be faster, so I decided to test it. And the results far exceeded whatever expectations I had...
I used https://github.com/adamgreig/stm32ral for my tests. If you want to build it locally:
```bash
$ cargo doc --features doc --open
```
But I strongly recommend to do it with this PR. Some numbers:
* Loading a page with the JSON search-index: less than 1 second
* Loading a page with the JS search-index: crashed after 30 seconds
I think the results are clear enough...
r? @ollie27
cc @rust-lang/rustdoc
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
Fix formatting errors and bless test outputs
* move tests to ui/async-await
fix test error text
remove span from IsAsync
ty/print: pretty-print constant aggregates (arrays, tuples and ADTs).
Oddly enough, we don't have any UI tests showing this off in types, only `mir-opt` tests.
However, the pretty form should show up in the test output diff of #71018, if this PR is merged first.
<hr/>
Examples of before/after:
|`Option<bool>`|
|:-:|
|`{transmute(0x01): std::option::Option<bool>}`|
| ✨ ↓↓↓ ✨ |
|`std::option::Option::<bool>::Some(true)`|
| `RawVec<u32>` |
|:-:|
| `ByRef { alloc: Allocation { bytes: [4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [] }), undef_mask: UndefMask { blocks: [65535], len: Size { raw: 16 } }, size: Size { raw: 16 }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::<u32>`|
| ✨ ↓↓↓ ✨ |
|`alloc::raw_vec::RawVec::<u32> { ptr: std::ptr::Unique::<u32> { pointer: {0x4 as *const u32}, _marker: std::marker::PhantomData::<u32> }, cap: 0usize, alloc: std::alloc::Global }`|
<hr/>
This PR is a prerequisite for #61486, *sort of*, in that we need to be able to pretty-print values in order to even consider how we might mangle them.
We still don't have pretty-printing for constants of reference types, @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
<hr/>
Each commit should be reviewed separately, as I've fixed a couple deficiencies along the way.
r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid
Deprecate the asm! macro in favor of llvm_asm!
Since we will be changing the syntax of `asm!` soon, deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed.
RFC: https://github.com/rust-lang/rfcs/pull/2843
Make the necessary changes to support concurrency in Miri.
This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency:
1. Move stack from the interpretation context (`InterpCx`) to machine, so that the machine can switch the stacks when it changes the thread being executed.
2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique, which allows using a simpler representation of the memory.
r? @oli-obk
cc @RalfJung
Rollup of 4 pull requests
Successful merges:
- #71026 (Fix false "never constructed" warnings for `Self::` variant paths)
- #71310 (Do not show DefId in diagnostics)
- #71317 (miri-unleash test for llvm_asm)
- #71324 (Fix some tests failing in `--pass check` mode)
Failed merges:
r? @ghost
Rollup of 5 pull requests
Successful merges:
- #71107 (Address concerns of weak-into-raw)
- #71188 (Fixed missing trait method suggests incorrect code (self parameter not named "self"). )
- #71300 (Clarify when to use the tracking issue template)
- #71315 (Add example in the alternative in std::mem::transmute docs)
- #71319 (Clean up E0522 explanation)
Failed merges:
r? @ghost
Address concerns of weak-into-raw
This should address the standing concerns in https://github.com/rust-lang/rust/issues/60728#issuecomment-612525616.
I've still left the ability to create a new dangling pointer from `null`, as I feel like this is the natural behaviour to expect, but I'm fine removing that too. I've modified the documentation to allow the `as_ptr` or `into_ptr` to return whatever garbage in case of a dangling pointer. I've also removed the guarantee to be able to do `from_raw(as_ptr)` from the documentation (but it would still work right now).
I've renamed the method and added implementations for `Rc`/`Arc`.
I've also tried if I can just „enable“ unsized types. I believe the current interface is compatible with them. But the inner implementation will be a bit challenging ‒ I can't use the `data_offset` as is used by `Rc` or `Arc` because it AFAIK „touches“ (creates a reference to) the live value of `T` ‒ and in case of `Weak`, it might be completely bogus or already dead ‒ so that would be UB.
`./x.py test tidy` is completely mad on my own system all over the code base :-(. I'll just hope it goes through CI, or will fix as necessary.
Is it OK if I ask @Amanieu for review, as the concerns are from you?
~r @Amanieu
With the exception of `-C no-redzone`, because that could take a value
before this PR.
This partially undoes one of the earlier commits in this PR, which added
the ability to take a value to all boolean options that lacked it.
The help output for these options looks like this:
```
-C no-vectorize-slp=val -- disable LLVM's SLP vectorization pass
```
The "=val" part is a lie, but hopefully this will be fixed in the future.
