update from origin 2020-06-27 #7
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 is done by adding a global atomic variable (non-TLS) that counts how many threads are panicking. In order to check if the current thread is panicking, this variable is read and, if it is zero, no thread (including the one where `panicking` is being called) is panicking and `panicking` can return `false` immediately without needing to access TLS. If the global counter is not zero, the local counter is accessed from TLS to check if the current thread is panicking.
The DWARF standard suggests that it might be useful to include `DW_AT_linkage_name` when it is *distinct* from the identifier name.
cargo dev update lints use if_chain clean up alot, span_lint_and_sugg find imported macros for sugg
how to compare macro to import path add more imports to test
remove stdout, fix clippy warnings, fmtcar
Macro use sugg changelog: Add auto applicable suggstion to macro_use_imports fixes #5275 <s>Where exactly is the `wildcard_imports_helper` I haven't been able to import anything ex. `use lazy_static;` or something like for that I get version/compiler conflicts?</s> Found it. Should we also check for `#[macro_use] extern crate`, although this is still depended on for stuff like `rustc_private`?
if_same_then_else: don't assume multiplication is always commutative changelog: Don't assume multiplication is always commutative in [`if_same_then_else`] Fixes #5698
…r=estebank emitter: column width defaults to 140 Fixes #72509. This PR modifies the column width computation in the emitter when `termize::dimensions` returns `None` so that it uses the default value of 140 (which is used in UI testing currently) instead of `usize::MAX` which just ends up causing overflows in later computations. I also tried changing the computations which used `column_width` with their saturating equivalent, but the output appeared the same - so I decided to go with this approach because I feel like it's less likely to accidentally re-introduce an ICE like this in future (e.g. adding a non-saturating operation on `column_width` in future). I haven't added a test because I couldn't come up with a MCVE. I stumbled upon this running rustc-perf with the `piston-image` benchmark (running in tmux; it only happened with stage two builds only; and only when running through Cargo, not rustc directly with the same flags). In addition, given the nature of the issue, I don't know that we *could* write a UI test for this. Open to suggestions here though. r? @estebank
…oid, r=sfackler disable collectionbenches for android Fixes #73535 Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
Rollup of 13 pull requests Successful merges: - #72620 (Omit DW_AT_linkage_name when it is the same as DW_AT_name) - #72967 (Don't move cursor in search box when using arrows to navigate results) - #73102 (proc_macro: Stop flattening groups with dummy spans) - #73297 (Support configurable deny-warnings for all in-tree crates.) - #73507 (Cleanup MinGW LLVM linkage workaround) - #73588 (Fix handling of reserved registers for ARM inline asm) - #73597 (Record span of `const` kw in GenericParamKind) - #73629 (Make AssocOp Copy) - #73681 (Update Chalk to 0.14) - #73707 (Fix links in `SliceIndex` documentation) - #73719 (emitter: column width defaults to 140) - #73729 (disable collectionbenches for android) - #73748 (Add code block to code in documentation of `List::rebase_onto`) Failed merges: r? @ghost
- Pass around document_private a lot more - Add tests + Add tests for intra-doc links to private items + Add ignored tests for warnings in reference links
Show the values and computation that would overflow a const evaluation or propagation Fixes #71134 In contrast to the example in the issue it doesn't use individual spans for each operand. The effort required to implement that is quite high compared to the little (if at all) benefit it would bring to diagnostics. cc @shepmaster The way this is implemented it is also fairly easy to do the same for overflow panics at runtime, but that should be done in a separate PR since it may have runtime performance implications.
Warn if linking to a private item Closes #72769 r? @GuillaumeGomez
Fortanix SGX target libunwind build process changes Ticket: fortanix/rust-sgx#174 LLVM related changes (merged): rust-lang/llvm-project#57 Description: libunwind changes needed to run code in sgx environment via rust-sgx. Target that uses this in rust: x86_64-fortanix-unknown-sgx. Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable. With this change we act the same as musl target.
Perform obligation deduplication to avoid buggy `ExistentialMismatch` Address #59326.
Add liballoc impl SpecFromElem for i8
Speedup vec![1_i8; N] for non-zero element.
Before
test do_bench_from_elem_i8 ... bench: 130 ns/iter (+/- 7) = 61 MB/s
test do_bench_from_elem_u8 ... bench: 121 ns/iter (+/- 4) = 66 MB/s
After
test do_bench_from_elem_i8 ... bench: 123 ns/iter (+/- 7) = 65 MB/s
test do_bench_from_elem_u8 ... bench: 121 ns/iter (+/- 5) = 66 MB/s
No speed difference if element is already zero.
```rust
#[bench]
fn do_bench_from_elem_i8(b: &mut Bencher) {
b.bytes = 8 as u64;
b.iter(|| {
let dst = ve::vec![10_i8; 100];
assert_eq!(dst.len(), 100);
assert!(dst.iter().all(|x| *x == 10));
})
}
```
As suggested by @cuviper
https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/SpecForElem.20for.20other.20integers
r? @cuviper
CC @joshtriplett
Edit: Wow, I just realized both reviewers are Josh.
add missing doc links The doc comments contain ``[`size_of_val`]`` but the link target was missing.
Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators Closes #59947: a performance tweak that might benefit some. Optimizes `min` and `max ` on all btree double-ended iterators that do not drop, i.e. the iterators created by: - `BTreeMap::iter` - `BTreeMap::iter_mut` - `BTreeMap::keys` and `BTreeSet::iter` - `BTreeMap::range` and `BTreeSet::range` - `BTreeMap::range_mut` Also in these (currently) single-ended iterators, but obviously for `min` only: - `BTreeSet::difference` - `BTreeSet::intersection` - `BTreeSet::symmetric_difference` - `BTreeSet::union` Did not do this in iterators created by `into_iter` to preserve drop order, as outlined in #62316. Did not do this in iterators created by `drain_filter`, possibly to preserve drop order, possibly to preserve predicate invocation, mostly to not have to think about it too hard (I guess maybe it wouldn't be a change for `min`, which is the only shortcut possible in this single-ended iterator).
…ulacrum Bootstrap: detect Windows based on sys.platform Closes #73689.
…lacrum Document the Self keyword Partial fix of #34601. Document the `Self` keyword. This contains simple examples of the places where `Self` can be used.
Document some invariants correctly/more r? @wesleywiser
Remove irrelevant comment Iterator is no longer a lang item since 216e72f.
Remove blank line
rustc_lexer: Simplify shebang parsing once more Fixes #73250 (beta regression) Treat any line starting with `!#` as a shebang candidate, not only lines with something non-whitespace. This way we no longer need to define what `is_whitespace` means ([Linux shebang whitespace](https://github.com/torvalds/linux/blob/master/fs/binfmt_script.c), ASCII whitespace, Rust lexer whitespace, etc), which is nice. This change makes some invalid Rust code valid (see the regression above), but still never interprets a fragment of valid Rust code as a shebang. (This PR also removes one duplicate test.)
Rollup of 12 pull requests Successful merges: - #72771 (Warn if linking to a private item) - #72937 (Fortanix SGX target libunwind build process changes) - #73485 (Perform obligation deduplication to avoid buggy `ExistentialMismatch`) - #73529 (Add liballoc impl SpecFromElem for i8) - #73579 (add missing doc links) - #73627 (Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators) - #73691 (Bootstrap: detect Windows based on sys.platform) - #73694 (Document the Self keyword) - #73718 (Document the super keyword) - #73728 (Document some invariants correctly/more) - #73738 (Remove irrelevant comment) - #73765 (Remove blank line) 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
richkadel
pushed a commit
that referenced
this pull request
Nov 29, 2020
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 rust-lang#77467 (cc `@lcnr).` Possibly this needs a crater run? r? `@nikomatsakis` cc `@matthewjasper`
richkadel
pushed a commit
that referenced
this pull request
Mar 19, 2021
HWAddressSanitizer support # Motivation Compared to regular ASan, HWASan has a [smaller overhead](https://source.android.com/devices/tech/debug/hwasan). The difference in practice is that HWASan'ed code is more usable, e.g. Android device compiled with HWASan can be used as a daily driver. # Example ``` fn main() { let xs = vec![0, 1, 2, 3]; let _y = unsafe { *xs.as_ptr().offset(4) }; } ``` ``` ==223==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefdeffff0050 at pc 0xaaaad00b3468 READ of size 4 at 0xefdeffff0050 tags: e5/00 (ptr/mem) in thread T0 #0 0xaaaad00b3464 (/root/main+0x53464) #1 0xaaaad00b39b4 (/root/main+0x539b4) #2 0xaaaad00b3dd0 (/root/main+0x53dd0) #3 0xaaaad00b61dc (/root/main+0x561dc) #4 0xaaaad00c0574 (/root/main+0x60574) #5 0xaaaad00b6290 (/root/main+0x56290) #6 0xaaaad00b6170 (/root/main+0x56170) #7 0xaaaad00b3578 (/root/main+0x53578) #8 0xffff81345e70 (/lib64/libc.so.6+0x20e70) #9 0xaaaad0096310 (/root/main+0x36310) [0xefdeffff0040,0xefdeffff0060) is a small allocated heap chunk; size: 32 offset: 16 0xefdeffff0050 is located 0 bytes to the right of 16-byte region [0xefdeffff0040,0xefdeffff0050) allocated here: #0 0xaaaad009bcdc (/root/main+0x3bcdc) #1 0xaaaad00b1eb0 (/root/main+0x51eb0) #2 0xaaaad00b20d4 (/root/main+0x520d4) #3 0xaaaad00b2800 (/root/main+0x52800) #4 0xaaaad00b1cf4 (/root/main+0x51cf4) #5 0xaaaad00b33d4 (/root/main+0x533d4) #6 0xaaaad00b39b4 (/root/main+0x539b4) #7 0xaaaad00b61dc (/root/main+0x561dc) #8 0xaaaad00b3578 (/root/main+0x53578) #9 0xaaaad0096310 (/root/main+0x36310) Thread: T0 0xeffe00002000 stack: [0xffffc0590000,0xffffc0d90000) sz: 8388608 tls: [0xffff81521020,0xffff815217d0) Memory tags around the buggy address (one tag corresponds to 16 bytes): 0xfefcefffef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffef90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffefe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefcefffeff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0xfefceffff000: a2 a2 05 00 e5 [00] 00 00 00 00 00 00 00 00 00 00 0xfefceffff010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0xfefceffff080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Tags for short granules around the buggy address (one tag corresponds to 16 bytes): 0xfefcefffeff0: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. =>0xfefceffff000: .. .. c5 .. .. [..] .. .. .. .. .. .. .. .. .. .. 0xfefceffff010: .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags Registers where the failure occurred (pc 0xaaaad00b3468): x0 e500efdeffff0050 x1 0000000000000004 x2 0000ffffc0d8f5a0 x3 0200efff00000000 x4 0000ffffc0d8f4c0 x5 000000000000004f x6 00000ffffc0d8f36 x7 0000efff00000000 x8 e500efdeffff0050 x9 0200efff00000000 x10 0000000000000000 x11 0200efff00000000 x12 0200effe000006b0 x13 0200effe000006b0 x14 0000000000000008 x15 00000000c00000cf x16 0000aaaad00a0afc x17 0000000000000003 x18 0000000000000001 x19 0000ffffc0d8f718 x20 ba00ffffc0d8f7a0 x21 0000aaaad00962e0 x22 0000000000000000 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000ffffc0d8f650 x30 0000aaaad00b3468 ``` # Comments/Caveats * HWASan is only supported on arm64. * I'm not sure if I should add a feature gate or piggyback on the existing one for sanitizers. * HWASan requires `-C target-feature=+tagged-globals`. That flag should probably be set transparently to the user. Not sure how to go about that. # TODO * Need more tests. * Update documentation. * Fix symbolization. * Integrate with CI
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.