update from origin 2020-08-01 #17
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
FreeBSD has been doing this in our own package builds for two months now. https://svnweb.freebsd.org/ports?view=revision&revision=535771
As `Rc/Arc::weak_count` returns 0 when having no strong counts, this could be confusing and it's better to avoid using that completely. Closes #73840.
Add the rust-docs component to toolchain x86_64-unknown-linux-musl, which allows people using rustup on their musl-based linux distribution to download the rust-docs.
This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293, #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up.
The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own, different `leak` method) does not apply.
This commit updates the metadata location logic to ignore errors when calling `fs::canonicalize`. Canonicalization was added historically so multiple `-L` paths to the same directory don't print errors about multiple candidates (since rustc can deduplicate same-named paths), but canonicalization doesn't work on all filesystems. Cargo, for example, always uses this sort of fallback where it will opportunitistically try to canonicalize but fall back to using the input path if it otherwise doesn't work. If rustc is run on a filesystem that doesn't support canonicalization then the effect of this change will be that `-L` paths which logically point to the same directory will cause errors, but that's a rare enough occurrence it shouldn't cause much issue in practice. Otherwise rustc doesn't work at all today on those sorts of filesystem where canonicalization isn't supported!
Run all tests if have no specified tests The behaviour was changed in #74905 (comment) cc @alex if you could check it again, thank you.
…lacrum 1.45.2 release notes (for master) cc #74958
Miri: fix ICE when unwinding past topmost stack frame Fixes rust-lang/miri#1389
fix part of comparison that would always evaluate to "true", probably an oversight cc @jumbatm
Fix Const-Generic Cycle ICE #74199 This PR intends to fix the bug in Issue #74199 by following the suggestion provided of ignoring the error that causes the ICE. This does not fix the underlying cycle detection issue, but fixes the ICE. Also adds a test to check that it doesn't causes an ICE but returns a valid error for now. r? @lcnr Edit: Also it's funny how this PR number is an anagram of the issue number
Among other things, this brings in [the `__main_argc_argv`] patch, which simplifies the interaction between the compiler and WASI libc's startup code, which will help work on reactor support. [the `__main_argc_argv` patch]: llvm/llvm-project@00072c0
Changes: ```` Use the same index location on nightly as beta relax deprecated diagnostic message check Don't print to raw stderr in test Emit the `test` field in cargo metadata ````
Rollup of 6 pull requests Successful merges: - #74644 (Remove `linked_list_extras` methods.) - #74968 (Run all tests if have no specified tests) - #74982 (1.45.2 release notes) - #74984 (Miri: fix ICE when unwinding past topmost stack frame) - #74986 (fix part of comparison that would always evaluate to "true", probably an oversight) - #74991 (Fix Const-Generic Cycle ICE #74199) Failed merges: r? @ghost
…nherited-params, r=oli-obk mir: add `used_generic_parameters_needs_subst` Fixes #74636. This PR adds a `used_generic_parameters_needs_subst` helper function which checks whether a type needs substitution, but only for parameters that the `unused_generic_params` query considers used. This is used in the MIR interpreter to make the check for some pointer casts and for reflection intrinsics more precise. I've opened this as a draft PR because this might not be the approach we want to fix this issue and we have to decide what to do about the reflection case. r? @eddyb cc @lcnr @wesleywiser
…li-obk [mir] Special treatment for dereferencing a borrow to a static definition Fix #70584. As suggested by @oli-obk in this [comment](#70584 (comment)), one can chase the definition of the local variable being de-referenced and check if it is a true static variable. If that is the case, `validate_place` will admit the promotion. This is my first time to contribute to `rustc`, and I have two questions. 1. A generalization to some extent is applied to decide if the promotion is possible in the static context. In case that there are more projection operations preceding the de-referencing, `validate_place` recursively decent into inner projection operations. I have put thoughts into its correctness but I am not totally sure about it. 2. I have a hard time to find a good place for the test case. This patch has to do with MIR, but this test case would look out of place compared to other tests in `src/test/ui/mir` or `src/test/ui/borrowck` because it does not generate errors while others do. It is tentatively placed in `src/test/ui/statics` for now. Thank you for any comments and suggestions!
add `slice::array_chunks` to std Now that #74113 has landed, these methods are suddenly usable. A rebirth of #72334 Tests are directly copied from `chunks_exact` and some additional tests for type inference. r? @withoutboats as you are both part of t-libs and working on const generics. closes #60735
Rename HAIR to THIR (Typed HIR). r? @nikomatsakis Originally suggested by @eddyb
Update the bundled wasi-libc with libstd This just updates WASI libc, in preparation for WASI reactor support in a separate change. r? @alexcrichton
Clean up E0741 error explanation r? @Dylan-DPC
…plugin, r=GuilliameGomez Some fixes for `plugin.md` in unstable-book - sample codes not working I referred to https://github.com/rust-lang/rust/blob/master/src/test/ui-fulldeps/auxiliary/lint-plugin-test.rs and https://github.com/rust-lang/rust/blob/master/src/test/ui-fulldeps/lint-plugin.rs. - broken link https://github.com/rust-lang/rust/blob/master/src/librustc/lint/builtin.rs -> https://github.com/rust-lang/rust/blob/master/src/librustc_session/lint/builtin.rs
Replace a recursive algorithm with an iterative one and a stack. fixes #74931
Update the WASI libc build to LLVM 10. Among other things, this brings in [the `__main_argc_argv`] patch, which simplifies the interaction between the compiler and WASI libc's startup code, which will help work on reactor support. [the `__main_argc_argv` patch]: llvm/llvm-project@00072c0 r? @alexcrichton
submodules: update cargo from 974eb438d to 2d5c2381e Changes: ```` Use the same index location on nightly as beta relax deprecated diagnostic message check Don't print to raw stderr in test Emit the `test` field in cargo metadata ```` r? @ehuss Trying to get the fix to the registry-index-hash upstream soonish.
Clean up E0743 explanation r? @Dylan-DPC
Rollup of 6 pull requests Successful merges: - #74977 (Clean up E0741 error explanation) - #74981 (Some fixes for `plugin.md` in unstable-book) - #74983 (Replace a recursive algorithm with an iterative one and a stack.) - #74995 (Update the WASI libc build to LLVM 10.) - #74996 (submodules: update cargo from 974eb438d to 2d5c2381e) - #75007 (Clean up E0743 explanation) Failed merges: r? @ghost
Move from `log` to `tracing` The only visible change is that we now get timestamps in our logs: ``` Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: skipping replace of Rvalue::Use(const () because it is already a const Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: propagated into _2 Jul 24 18:41:01.065 TRACE rustc_mir::transform::const_prop: visit_constant: const () ``` This PR was explicitly designed to be as low-impact as possible. We can now move to using the name `tracing` insteads of `log` on a crate-by-crate basis and use any of the other tracing features where desirable. As far as I can tell this will allow tools to seamlessly keep working (since they are using `rustc_driver::init_log...`). This is the first half of step 1 of the accepted `tracing` MCP (rust-lang/compiler-team#331)
Stabilize Vec::leak as a method Closes #62195 The signature is changed to a method rather than an associated function: ```diff -pub fn leak<'a>(vec: Vec<T>) -> &'a mut [T] +pub fn leak<'a>(self) -> &'a mut [T] ``` The reason for `Box::leak` not to be a method (`Deref` to an arbitrary `T` which might have its own, different `leak` method) does not apply.
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.