update from origin 2020-07-13 #10
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit marks temporaries from MIR construction as internal such that they are skipped in `sanitize_witness` (where each MIR local is checked to have been contained within the generator interior computed during typeck). This resolves an ICE whereby the construction of checked addition introduced a `(u64, bool)` temporary which was not in the HIR and thus not in the generator interior. Signed-off-by: David Wood <david@davidtw.co>
Remove `TypeckTables::empty(None)` and make hir_owner non-optional. Each commit before the last one removes uses of `TypeckTables::empty(None)`, replacing the empty tables with having `Option` around the `&'tcx TypeckTables<'tcx>` that HIR visitors kept track of. The last commit removes the concept of "empty `TypeckTables`" altogether, guaranteeing that every `TypeckTables` corresponds to a HIR body owner. r? @nikomatsakis
to feature(rc_as_ptr) These were stabilized alongside the Weak versions, but having `feature = "weak_.."` on a fn definition for the non-weak pointers is potentially very confusing.
Move contributing.md to rustc-dev-guide and point at getting started See description on rust-lang/rustc-dev-guide#753
Use WASM's saturating casts if they are available WebAssembly supports saturating floating point to integer casts behind a target feature. The feature is already available on many browsers. Beginning with 1.45 Rust will start defining the behavior of floating point to integer casts to be saturating as well. For this Rust constructs additional checks on top of the `fptoui` / `fptosi` instructions it emits. Here we introduce the possibility for the codegen backend to construct saturating casts itself and only fall back to constructing the checks ourselves if that is not possible. Resolves part of #73591
…-closure-async, r=petrochenkov resolve: disallow labelled breaks/continues through closures/async blocks Fixes #73541. This PR modifies name resolution to prohibit labelled breaks/continues through closures or async blocks, fixing an ICE. In addition, it improves the diagnostics surrounding labelled breaks/continues through closures or async blocks by informing the user if the label exists in an parent scope and telling them that won't work. r? @petrochenkov (resolve) cc @estebank (diagnostic changes) @tmandry (issue is from `wg-async-foundations`)
Use 'tcx for references to AccessLevels wherever possible. Most of the changes are just fallout from removing a lifetime parameter from structs, and mostly in clippy. r? @Manishearth
Update psm version This new version includes a fix for building on aarch64 windows. cc #72881
Add option for local docker testing. This adds the option `--dev` to `src/ci/docker/run.sh` so that it will enter an interactive environment for local testing. I have often needed this for testing things, but I always needed to edit this script. I wanted the ability to interact in the environment, run different commands, inspect errors, etc.
disable BTree min_max test in Miri for now Until #73915 is fixed, better skip this test in Miri so that we can test the others at least.
Document rustc_ast::ast::Pat
Use str::strip* in bootstrap This is technically a breaking change, replacing the use of `trim_start_matches` with `strip_prefix`. However, because in `rustc -Vv` output there are no lines starting with multiple "release:", this should go unnoticed in practice.
Only add CFGuard on `windows-msvc` targets As @ollie27 pointed out in #73893, the `cfguard` module flag causes incorrect behavior on `windows-gnu` targets. This patch restricts rustc to only add this flag for `windows-msvc` targets (this may need to be changed if other linkers gain support for CFGuard).
Only allow `repr(i128/u128)` on enum Fixes #74082
Start-up clean-up r? @petrochenkov
Correctly mark the ending span of a match arm Closes #74050 r? @matthewjasper
Avoid "whitelist" Other terms are more inclusive and precise.
…ulacrum ⬆️ rust-analyzer This updates rust-analyzer submodule to the latest release. I plan to do that every Monday after rust-analyzer release (about 16:00 CET). This is semi-automated by https://github.com/rust-analyzer/rust-analyzer/pull/5253/files#diff-c06f6a9cbd0ad2421bcc2ddc28805457R77-R100. Who would be the appropriate person to r? on Mondays?
Update books ## book 3 commits in 4e7c00bece1544d409312ec93467beb62b5bd0cb..84a31397b34f9d405df44f2899ff17a4828dba18 2020-06-19 09:39:12 -0400 to 2020-07-04 10:50:18 -0500 - Update Windows install instructions (rust-lang/book#2389) - Update ch01-02-hello-world.md (rust-lang/book#2386) - bump mdbook version in github action (rust-lang/book#2380) ## reference 2 commits in 04d5d5d7ba624b6f5016298451f3a63d557f3260..0ea7bc494f1289234d8800bb9185021e0ad946f0 2020-06-16 15:08:05 -0700 to 2020-07-02 15:33:04 -0700 - Fix mis-capitalization of type name. (rust-lang/reference#844) - Fix name of trait for array indexing. (rust-lang/reference#840) ## embedded-book 1 commits in 616962ad0dd80f34d8b802da038d0aed9dd691bb..94d9ea8460bcbbbfef1877b47cb930260b5849a7 2020-06-23 16:03:45 +0000 to 2020-07-05 14:17:40 +0000 - Note on transformation of static variables by attribute exception (rust-embedded/book#251) ## rust-by-example 1 commits in 6f94ccb48da6fa4ed0031290f21411cf789f7d5e..229c6945a26a53a751ffa4f9cb418388c00029d3 2020-06-20 17:51:30 -0300 to 2020-07-06 10:13:15 -0300 - Modify comments (rust-lang/rust-by-example#1359)
Update rust-installer to latest version This pulls in a fix for the install script on some tr(1) implementations, as well as an update to use `anyhow` instead of `failure` for error handling.
…k-Simulacrum Fix disabled dockerfiles When the dockerfiles were moved into the host-x86_64 directory, paths for COPY commands were updated with the new host-x86_64/ prefix. This suggested that the intended context was src/ci/docker. However, the context for disabled docker images was src/ci/docker/host-x86_64. This broke the new paths and prevented src/ci/docker/scripts from being included in the context at all. This commit corrects this context allowing docker to find the files it needs for COPY commands. Also includes a quick fix to riscv recommended by @bjorn3
take self by value in ToPredicate
Rollup of 19 pull requests Successful merges: - #71322 (Accept tuple.0.0 as tuple indexing (take 2)) - #72303 (Add core::future::{poll_fn, PollFn}) - #73862 (Stabilize casts and coercions to `&[T]` in const fn) - #73887 (stabilize const mem::forget) - #73989 (adjust ub-enum test to be endianess-independent) - #74045 (Explain effects of debugging options from config.toml) - #74076 (Add `read_exact_at` and `write_all_at` to WASI's `FileExt`) - #74099 (Add VecDeque::range* methods) - #74100 (Use str::strip* in bootstrap) - #74103 (Only add CFGuard on `windows-msvc` targets) - #74109 (Only allow `repr(i128/u128)` on enum) - #74122 (Start-up clean-up) - #74125 (Correctly mark the ending span of a match arm) - #74127 (Avoid "whitelist") - #74129 (:arrow_up: rust-analyzer) - #74135 (Update books) - #74145 (Update rust-installer to latest version) - #74161 (Fix disabled dockerfiles) - #74162 (take self by value in ToPredicate) Failed merges: r? @ghost
Stabilize `transmute` in constants and statics but not const fn cc #53605 (leaving issue open so we can add `transmute` to `const fn` later) Previous attempt: #64011 r? @RalfJung cc @rust-lang/wg-const-eval
debuginfo: Mangle tuples to be natvis friendly, typedef basic types These changes are meant to unblock #70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.) * f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>` * 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)
Optimize is_ascii for str and [u8]. This optimizes the `is_ascii` function for `[u8]` and `str`. I've been surprised this wasn't done for a while, so I just did it. Benchmarks comparing before/after look like: ``` test ascii::long_readonly::is_ascii_slice_iter_all ... bench: 174 ns/iter (+/- 79) = 40172 MB/s test ascii::long_readonly::is_ascii_slice_libcore ... bench: 16 ns/iter (+/- 5) = 436875 MB/s test ascii::medium_readonly::is_ascii_slice_iter_all ... bench: 12 ns/iter (+/- 3) = 2666 MB/s test ascii::medium_readonly::is_ascii_slice_libcore ... bench: 2 ns/iter (+/- 0) = 16000 MB/s test ascii::short_readonly::is_ascii_slice_iter_all ... bench: 3 ns/iter (+/- 0) = 2333 MB/s test ascii::short_readonly::is_ascii_slice_libcore ... bench: 4 ns/iter (+/- 0) = 1750 MB/s ``` (Taken on a x86_64 macbook 2.9 GHz Intel Core i9 with 6 cores) Where `is_ascii_slice_iter_all` is the old version, and `is_ascii_slice_libcore` is the new. I tried to document the code well, so hopefully it's understandable. It has fairly exhaustive tests ensuring size/align doesn't get violated -- because `miri` doesn't really help a lot for this sort of code right now, I tried to `debug_assert` all the safety invariants I'm depending on. (Of course, none of them are required for correctness or soundness -- just allows us to test that this sort of pointer manipulation is sound and such). Anyway, thanks. Let me know if you have questions/desired changes.
Fix cross compilation of LLVM to aarch64 Windows targets When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build. This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built. If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target. Related issue: #72881 Requires LLVM change: rust-lang/llvm-project#67
…etrochenkov linker: illumos ld does not support --eh-frame-hdr As of #73564, the --eh-frame-hdr flag is unconditionally passed to linkers on many platforms. The illumos link editor does not currently support this flag. The linker machinery in the Rust toolchain currently seems to use the (potentially cross-compiled) target to choose linker flags, rather than looking at what might be running on the build system. Disabling the flag for all illumos/Solaris targets seems like the best we can do for now without more serious surgery.
…ochenkov Add a help to use `in_band_lifetimes` in nightly Fixes #73775
Reword incorrect `self` token suggestion
Minor refactor for rustc_resolve diagnostics match Use `matches!` instead of old `if let`
update miri This incorporates rust-lang/miri#1474. [Last time](#74146) that change caused trouble but I fixed xargo since then and [now it should work](#74146 (comment)). Cc @rust-lang/miri r? @ghost
Rollup of 10 pull requests Successful merges: - #72920 (Stabilize `transmute` in constants and statics but not const fn) - #73715 (debuginfo: Mangle tuples to be natvis friendly, typedef basic types) - #74066 (Optimize is_ascii for str and [u8].) - #74116 (Fix cross compilation of LLVM to aarch64 Windows targets) - #74167 (linker: illumos ld does not support --eh-frame-hdr) - #74168 (Add a help to use `in_band_lifetimes` in nightly) - #74197 (Reword incorrect `self` token suggestion) - #74213 (Minor refactor for rustc_resolve diagnostics match) - #74240 (Fix #74081 and add the test case from #74236) - #74241 (update miri) Failed merges: r? @ghost
richkadel
added a commit
that referenced
this pull request
Oct 5, 2020
This is a combination of 18 commits. Commit #2: Additional examples and some small improvements. Commit #3: fixed mir-opt non-mir extensions and spanview title elements Corrected a fairly recent assumption in runtest.rs that all MIR dump files end in .mir. (It was appending .mir to the graphviz .dot and spanview .html file names when generating blessed output files. That also left outdated files in the baseline alongside the files with the incorrect names, which I've now removed.) Updated spanview HTML title elements to match their content, replacing a hardcoded and incorrect name that was left in accidentally when originally submitted. Commit #4: added more test examples also improved Makefiles with support for non-zero exit status and to force validation of tests unless a specific test overrides it with a specific comment. Commit #5: Fixed rare issues after testing on real-world crate Commit #6: Addressed PR feedback, and removed temporary -Zexperimental-coverage -Zinstrument-coverage once again supports the latest capabilities of LLVM instrprof coverage instrumentation. Also fixed a bug in spanview. Commit #7: Fix closure handling, add tests for closures and inner items And cleaned up other tests for consistency, and to make it more clear where spans start/end by breaking up lines. Commit #8: renamed "typical" test results "expected" Now that the `llvm-cov show` tests are improved to normally expect matching actuals, and to allow individual tests to override that expectation. Commit #9: test coverage of inline generic struct function Commit #10: Addressed review feedback * Removed unnecessary Unreachable filter. * Replaced a match wildcard with remining variants. * Added more comments to help clarify the role of successors() in the CFG traversal Commit #11: refactoring based on feedback * refactored `fn coverage_spans()`. * changed the way I expand an empty coverage span to improve performance * fixed a typo that I had accidently left in, in visit.rs Commit #12: Optimized use of SourceMap and SourceFile Commit #13: Fixed a regression, and synched with upstream Some generated test file names changed due to some new change upstream. Commit #14: Stripping out crate disambiguators from demangled names These can vary depending on the test platform. Commit #15: Ignore llvm-cov show diff on test with generics, expand IO error message Tests with generics produce llvm-cov show results with demangled names that can include an unstable "crate disambiguator" (hex value). The value changes when run in the Rust CI Windows environment. I added a sed filter to strip them out (in a prior commit), but sed also appears to fail in the same environment. Until I can figure out a workaround, I'm just going to ignore this specific test result. I added a FIXME to follow up later, but it's not that critical. I also saw an error with Windows GNU, but the IO error did not specify a path for the directory or file that triggered the error. I updated the error messages to provide more info for next, time but also noticed some other tests with similar steps did not fail. Looks spurious. Commit #16: Modify rust-demangler to strip disambiguators by default Commit #17: Remove std::process::exit from coverage tests Due to Issue rust-lang#77553, programs that call std::process::exit() do not generate coverage results on Windows MSVC. Commit #18: fix: test file paths exceeding Windows max path len
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.