Rollup merge of #63162 - RalfJung:miri-xargo, r=alexcrichton
Miri tests: use xargo to build separate libstd
This uses `cargo miri setup` to prepare the libstd that is used for testing Miri, instead of adjusting the entire bootstrap process to make sure the libstd that already gets built is fit for Miri.
The issue with our current approach is that with `test-miri = true`, libstd and the test suite get built with `--cfg miri`, which e.g. means hashbrown uses no SIMD, and not all things are tested. Such global side-effects seem like footguns waiting to go off.
On the other hand, the new approach means we install xargo as a side-effect of doing `./x.py test src/tools/miri`, which might be surprising, and we also both have to build xargo and another libstd which costs some extra time. Not sure if the tools builders have enough time budget for that. Maybe there is a way to cache xargo?
We have to first first land https://github.com/rust-lang/miri/pull/870 in Miri and then update this PR to include that change (also to get CI to test Miri before bors), but I wanted to get the review started here.
Cc @oli-obk (for Miri) @alexcrichton (for CI) @Mark-Simulacrum (for bootstrap)
bors [Thu, 8 Aug 2019 17:19:22 +0000 (17:19 +0000)]
Auto merge of #63380 - Centril:rollup-tzfhtnu, r=Centril
Rollup of 8 pull requests
Successful merges:
- #63261 (bump rand in libcore/liballoc test suites)
- #63316 (Update rustfmt to 1.4.4)
- #63332 (Add an overflow check in truncate implementation for Unix.)
- #63342 (Don't use remap-path-prefix in dep-info files.)
- #63366 (doc: Fix typo in float from bytes methods)
- #63370 (Fix ICE #63364)
- #63377 (Improved documentation for compile_error!())
- #63379 (Add test for issue 53096)
Rollup merge of #63342 - ehuss:remap-path-dep-info, r=alexcrichton
Don't use remap-path-prefix in dep-info files.
This changes it so that dep-info files do not use remapped paths.
Having remapped paths causes problems with Cargo because if you remap to a nonexistent path (like `/rustc/$HASH` which rustc distributions do), then Cargo's change tracking thinks the files don't exist and will always rebuild.
I don't actually know if this is a good idea. I think it makes sense, but I do not know what the exact requirements are for reproducible builds. I consider these files separate from the binary artifacts generated, and as a build-system helper, so it seems reasonable to me.
I'm also not sure if this needs a test. I'll definitely add one on the cargo side if this is merged.
Rollup merge of #63261 - RalfJung:rand, r=nikomatsakis
bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
5 commits in 8e7d614303b0dec7492e048e63855fcd3b944ec8..b4b3536839042a6743fc76f0d9ad2a812020aeaa
2019-07-16 21:02:33 +0100 to 2019-08-07 02:29:50 +0200
- Update partially initialized values in drop documentation. (rust-lang-nursery/reference#648)
- Define sound and unsound (rust-lang-nursery/reference#647)
- Fix a type in the modules section: functions => modules (rust-lang-nursery/reference#645)
- Fix some links. (rust-lang-nursery/reference#642)
- Update recursion_limit default limit (rust-lang-nursery/reference#633)
## rust-by-example
14 commits in e3679e214d8db44586aca9b20aa27517007d1923..f2c15ba5ee89ae9469a2cf60494977749901d764
2019-07-15 11:13:44 -0300 to 2019-08-07 10:14:25 -0300
- Remove redundant semicolons (rust-lang/rust-by-example#1239)
- Rename "Read Lines" chapter title (rust-lang/rust-by-example#1230)
- Added space between word and inline code block in unit_testing.md (rust-lang/rust-by-example#1237)
- [typo] fix unit_testing wrong output (rust-lang/rust-by-example#1210)
- flow_control/match/binding.md: `...' -> `..=' (rust-lang/rust-by-example#1233)
- generics/impl.md: follow rustfmt style (rust-lang/rust-by-example#1236)
- freeze.md: Incorrect example (rust-lang/rust-by-example#1226)
- Make `point` consistent (rust-lang/rust-by-example#1229)
- Fix typo at error -> panic (rust-lang/rust-by-example#1227)
- Snake didn't deserve to die 🐍 (rust-lang/rust-by-example#1228)
- Reorder links in destructuring.md (rust-lang/rust-by-example#1225)
- Rename variable names for consistent in iter_result.md (rust-lang/rust-by-example#1224)
- Fix several shell output and code highlights. (rust-lang/rust-by-example#1222)
- Add new example for Rc. (rust-lang/rust-by-example#1223)
## edition-guide
5 commits in f6c8b92d4e63edd28e862be952f33861f35956f8..e58bc4ca104e890ac56af846877c874c432a64b5
2019-07-06 22:10:32 +0200 to 2019-07-31 20:14:12 +0200
- Hide extraneous `use` in anonymous lifetime example. (rust-lang-nursery/edition-guide#190)
- Attempt to clarify "no more mod.rs". (rust-lang-nursery/edition-guide#187)
- Remove -preview for rustup components. (rust-lang-nursery/edition-guide#188)
- rust-lang-nursery/edition-guide#184 More clear explanation and Title. (rust-lang-nursery/edition-guide#185)
- More clear table headers (rust-lang-nursery/edition-guide#186)
Rollup merge of #63331 - gorup:conditionalinit, r=cramertj
Test conditional initialization validation in async fns
r? @cramertj
Per [paper doc](https://paper.dropbox.com/doc/async.await-Call-for-Tests--AiWF2Nt8tgDiA70qFI~oiLOOAg-nMyZGrra7dz9KcFRMLKJy) calling for async/.await tests, tests are desired for conditionally initialized local variables. This PR hopes to provide tests for that.
#63294 seems to be tracking the items from the paper doc that this PR is related to
#62121 is an open issue asking for more async/.await tests that this relates to
bors [Thu, 8 Aug 2019 05:28:07 +0000 (05:28 +0000)]
Auto merge of #63282 - Xanewok:update-rls, r=nikomatsakis
Update RLS
Most importantly this includes:
* Collect file -> edition mapping after AST expansion ([#1513](https://github.com/rust-lang/rls/pull/1513)) (enabled by https://github.com/rust-lang/rust/pull/62679)
* Fix rustfmt during builds by reading edition from manifest ([#1533](https://github.com/rust-lang/rls/pull/1533))
Which fixes the annoying problem where users couldn't format via RLS while `cargo fmt` worked.
The beta cut-off is drawing near and I'd like to make sure this lands before then.
bors [Wed, 7 Aug 2019 22:07:24 +0000 (22:07 +0000)]
Auto merge of #62457 - zackmdavis:minimax_search_and_the_structure_of_cognition, r=varkor
pretty-pretty extremal constants!
(A resurrection of the defunct #57073.)
While many programmers may intuitively appreciate the significance of "magic numbers" like −2147483648, Rust is about empowering everyone to build reliable and efficient software! It's a bit more legible to print the constant names (even noisy fully-qualified-paths thereof).
The bit-manipulation methods mirror those in `librustc_mir::hair::pattern::_match::all_constructors`; thanks to the immortal Varkor for guidance.
bors [Wed, 7 Aug 2019 16:56:46 +0000 (16:56 +0000)]
Auto merge of #60547 - redox-os:redox-unix, r=alexcrichton
redox: convert to target_family unix
This is the second step to supporting rust-lang/rust#60139.
In order to have a smooth transition, there will need to be a change made in liblibc at the same time, switching Redox over to the unix target family. See https://github.com/rust-lang/libc/pull/1332
Zack M. Davis [Sun, 7 Jul 2019 02:41:12 +0000 (19:41 -0700)]
pretty-pretty extremal constants!
While many programmers may intuitively appreciate the significance of
"magic numbers" like −2147483648, Rust is about empowering everyone to
build reliable and efficient software! It's a bit more legible to
print the constant names (even noisy fully-qualified-paths thereof).
The bit-manipulation methods mirror those in
`librustc_mir::hair::pattern::_match::all_constructors`; thanks to the
immortal Varkor for guidance.
bors [Wed, 7 Aug 2019 00:45:00 +0000 (00:45 +0000)]
Auto merge of #63341 - Centril:rollup-hkhxahb, r=Centril
Rollup of 9 pull requests
Successful merges:
- #63034 (Fix generator size regressions due to optimization)
- #63035 (Use MaybeUninit to produce more correct layouts)
- #63163 (add a pair of whitespace after remove parentheses)
- #63294 (tests for async/await drop order)
- #63307 (don't ignore mir_dump folder)
- #63308 (PlaceRef's base is already a reference)
- #63310 (Tests around moving parts of structs and tuples across await points)
- #63314 (doc: the content has since been moved to the guide)
- #63333 (Remove unnecessary features from compiler error code list)
Rollup merge of #63310 - gorup:partial-moves, r=cramertj
Tests around moving parts of structs and tuples across await points
r? cramertj
Per the [dropbox paper](https://paper.dropbox.com/doc/async.await-Call-for-Tests--AiR3vlp1s_Kw0yzWZ1sWMnaIAQ-nMyZGrra7dz9KcFRMLKJy) about more tests, it appears there are some tests wanted around local variables (under the section ["Dynamic semantics"](https://paper.dropbox.com/doc/async.await-Call-for-Tests--AiR3vlp1s_Kw0yzWZ1sWMnaIAg-nMyZGrra7dz9KcFRMLKJy#:uid=122335511260129643493892&h2=Dynamic-semantics)). Here is one commit, and I can probably get code up for other scenarios listed there, although I may not have the full background to know what is being targeted by the tests. Please assist me if I'm off course, thanks!
---
- Executed all 4 new tests
- Executed `tidy` command
Rollup merge of #63307 - RalfJung:gitignore, r=alexcrichton
don't ignore mir_dump folder
I dumped some MIR and wondered why `git status` wouldn't show the tree as dirty, reminding me to clean up after myself. Turns out this folder was explicitly gitignored. I don't think it should be.
If someone doesn't want to clean up that way, they can add it to `.git/info/exclude`.
(That file seems like it could need some general cleanup, honestly, but that's for another day.)
Rollup merge of #63294 - alsuren:async-tests, r=cramertj
tests for async/await drop order
This is just me helping out with https://github.com/rust-lang/rust/issues/62121 where I can.
I'm also going to use this as a public place to collect my thoughts about what has already been done and what hasn't (adding comments to the dropbox paper doc was quickly getting spammy).
I've tried to keep my commit messages similar to the line items on https://paper.dropbox.com/doc/async.await-Call-for-Tests--AiKouT0L41mSnK1741s~TiiRAg-nMyZGrra7dz9KcFRMLKJy as possible.
A bunch of my tests are likely to be either redundant with other tests, or lower quality than other tests that people are writing. A reasonable approach might be to tell me which commits you want to keep and I'll throw away the rest of them.
The part from the dropbox paper doc that I'm concentrating on here is:
(items marked with `?` are ones that I can't immediately think of how to test, so I will leave for other people. Items with checkboxes are things that I have done or will try to do next)
### Dynamic semantics
- `async`/`await` with unusual locals:
- ? partially uninhabited
- ? conditionally initialized
- ~drop impls~ already done in src/test/ui/async-await/drop-order/*
- ? nested drop impls
- ~partially moved (e.g., `let x = (vec![], vec![]); drop(x.0); foo.await; drop(x.1);`)~ see https://github.com/rust-lang/rust/pull/63310
- Control flow:
- basic
- complex
- [x] `.await` while holding variables of different sizes
- (possibly) drop order
- [x] including drop order for locals when a future is dropped part-way through execution
- Parameters' drop order is covered in my commit f40190a
- ~An async fn version of `dynamic-drop.rs`~
- already done by matthewjasper in https://github.com/rust-lang/rust/pull/62193/files
- ? interaction with const eval, promoteds, and temporaries
- [x] drop the resulting future and check that local variables and parameters are dropped in the expected order (interaction with cancellation, in other words)
- also in f40190a
Explanation of commits:
* 0a1bdd4 is the simplest place I could think of to explicitly test `.await` while holding variables of different sizes. I'm pretty sure that this will end up being redundant with something else, so I'm happy to drop it.
* f40190a is a copy-paste from `drop-order-for-async-fn-parameters.rs` with `NeverReady.await` dumped on the end of each testcase.
* Normally I don't like copy-paste-based tests, but `drop-order-for-async-fn-parameters-by-ref-binding.rs` is also copy-paste, so I thought it might be okay.
* [x] I'm a bit sad that this doesn't cover non-parameter locals, but I think it should be easy enough to extend in that direction, so I might have a crack at that tomorrow.
* c4940e0f90 makes a bunch of local variables and moves them into either `{}` blocks or `async move {}` blocks, checking for any surprising differences.
* I have tried to give the test functions descriptive names
* I have not duplicated the tests for methods with/without self.
* I think that all of these tests could be rewritten to be clearer if I could write down the expected drop order next to each test.
Rollup merge of #63034 - tmandry:reduce-generator-size-regressions, r=cramertj
Fix generator size regressions due to optimization
I tested the generator optimizations in #60187 and #61922 on the Fuchsia
build, and noticed that some small generators (about 8% of the async fns
in our build) increased in size slightly.
This is because in #60187 we split the fields into two groups, a
"prefix" non-overlap region and an overlap region, and lay them out
separately. This can introduce unnecessary padding bytes between the two
groups.
In every single case in the Fuchsia build, it was due to there being
only a single variant being used in the overlap region. This means that
we aren't doing any overlapping, period. So it's better to combine the
two regions into one and lay out all the fields at once, which is what
this change does.
Fix generator size regressions due to optimization
I tested the generator optimizations in #60187 and #61922 on the Fuchsia
build, and noticed that some small generators (about 8% of the async fns
in our build) increased in size slightly.
This is because in #60187 we split the fields into two groups, a
"prefix" non-overlap region and an overlap region, and lay them out
separately. This can introduce unnecessary padding bytes between the two
groups.
In every single case in the Fuchsia build, it was due to there being
only a single variant being used in the overlap region. This means that
we aren't doing any overlapping, period. So it's better to combine the
two regions into one and lay out all the fields at once, which is what
this change does.
bors [Tue, 6 Aug 2019 17:19:05 +0000 (17:19 +0000)]
Auto merge of #61515 - shepmaster:boxed-slice-to-array, r=cramertj
Add implementations for converting boxed slices into boxed arrays
This mirrors the implementations of reference slices into arrays.
# Discussion
- [x] Should we use const generics? ([probably not](https://github.com/rust-lang/rust/pull/61515#issuecomment-498690649))
- [ ] [What's the safety rationale here](https://github.com/rust-lang/rust/pull/61515#discussion_r290296613)?
- [ ] [Should the errors return the original object](https://github.com/rust-lang/rust/pull/61515#discussion_r290336592)?
bors [Tue, 6 Aug 2019 13:37:22 +0000 (13:37 +0000)]
Auto merge of #63328 - Centril:rollup-482ujaf, r=Centril
Rollup of 6 pull requests
Successful merges:
- #62459 (Use internal iteration in the Sum and Product impls of Result and Option)
- #62821 (Not listed methods)
- #62837 (Fix theme picker blur handler: always hide instead of switching)
- #63286 (Replace error callback with Result)
- #63296 (Deduplicate rustc_demangle in librustc_codegen_llvm)
- #63298 (assume_init: warn about valid != safe)
Rollup merge of #63296 - alexcrichton:deduplicate-demangle, r=Mark-Simulacrum
Deduplicate rustc_demangle in librustc_codegen_llvm
This commit removes the crates.io dependency of `rustc-demangle` from
`rustc_codegen_llvm`. This crate is actually already pulled in to part
of the `librustc_driver` build and with the upcoming pipelining
implementation in Cargo it causes build issues if `rustc-demangle` is
left to its own devices.
This is not currently required, but once pipelining is enabled for
rustc's own build it will be required to build correctly.
Rollup merge of #62837 - Kinrany:patch-1, r=GuillaumeGomez
Fix theme picker blur handler: always hide instead of switching
Fixes a minor bug in UI generated by rustdoc.
For example, this page: https://doc.rust-lang.org/std/
Reproduction steps:
1. Click the theme picker twice
* The list of themes will be shown and then hidden
2. Click anywhere else
* The list of themes will be show again, which is unexpected
The bug was caused by blur event handler toggling the state of the element instead of always hiding it regardless of the current state.
Rollup merge of #62459 - timvermeulen:result_sum_internal_iteration, r=scottmcm
Use internal iteration in the Sum and Product impls of Result and Option
This PR adds internal iteration to the `ResultShunt` iterator type underlying the `Sum` and `Product` impls of `Result`. I had to change `ResultShunt` to hold a mutable reference to an error instead, similar to `itertools::ProcessResults`, in order to be able to pass the `ResultShunt` itself by value (which is necessary for internal iteration).
`ResultShunt::process` can unfortunately no longer be an associated function because that would make it generic over the lifetime of the error reference, which wouldn't work, so I turned it into the free function `process_results`.
I removed the `OptionShunt` type and forwarded the `Sum` and `Product` impls of `Option` to their respective impls of `Result` instead, to avoid having to repeat the internal iteration logic.
That PR makes error messages worse than before, and we couldn't come up with a way of actually making them better, so revert it for now. Any idea for making this error message better is welcome!
Rollup merge of #63230 - tmandry:disallow-possibly-uninitialized, r=Centril
Make use of possibly uninitialized data [E0381] a hard error
This is one of the behaviors we no longer allow in NLL. Since it can
lead to undefined behavior, I think it's definitely worth making it a
hard error without waiting to turn off migration mode (#58781).
Closes #60450.
My ulterior motive here is making it impossible to leave variables
partially initialized across a yield (see #60889, discussion at #63035), so
tests are included for that.
cc #54987
---
I'm not sure if bypassing the buffer is a good way of doing this. We could also make a `force_errors_buffer` or similar that gets recombined with all the errors as they are emitted. But this is simpler and seems fine to me.
r? @Centril
cc @cramertj @nikomatsakis @pnkfelix @RalfJung
Rollup merge of #63184 - JasonShin:master, r=sfackler
Explaining the reason why validation is performed in to_str of path.rs
I thought it's good to explain the reason for the validation during the conversion between Path/PathBuffer into str, which explains the reason for returning an Option at this point (good for beginners who are reading through the docs).
Rollup merge of #63017 - matklad:no-fatal, r=petrochenkov
Remove special code-path for handing unknown tokens
In `StringReader`, we have a buffer of fatal errors, which is used only in a single case: when we see something which is not a reasonable token at all, like `🦀`. I think a more straightforward thing to do here is to produce an explicit error token in this case, and let the next layer (the parser), deal with it.
However currently this leads to duplicated error messages. What should we do with this? Naively, I would think that emitting (just emitting, not raising) `FatalError` should stop other errors, but looks like this is not the case? We can also probably tweak parser on the case-by-case basis, to avoid emitting "expected" errors if the current token is an `Err`. I personally also fine with cascading errors in this case: it's quite unlikely that you actually type a fully invalid token.
@petrochenkov, which approach should we take to fight cascading errors?
projects / rust.git / log