This repository was archived by the owner on Jan 7, 2022. It is now read-only.
Conversation
This commit implements a suggestion from @estebank that optimizes the use of snapshots. Instead of creating a snapshot for each recursion in `parse_path_segment` and then replacing `self` with them until the first invocation where if leading angle brackets are detected, `self` is not replaced and instead the snapshot is used to inform how parsing should continue. Now, a snapshot is created in the first invocation that acts as a backup of the parser state before any generic arguments are parsed (and therefore, before recursion starts). This backup replaces `self` if after all parsing of generic arguments has concluded we can determine that there are leading angle brackets. Parsing can then proceed from the backup state making use of the now known number of unmatched leading angle brackets to recover.
MonoItemExt#to_string is used for both debug logging and LLVM symbol name generation. When debugging, we want to print out any type we encounter, even if it's something weird like GeneratorWitness. However, during codegen, we still want to error if we encounter an unexpected type when generating a name. To resolve this issue, this commit introduces a new 'debug' parameter to the relevant methods. When set to 'true', it allows any type to be printed - when set to 'false', it 'bug!'s when encountering an unexpected type. This prevents an ICE when enabling debug logging (via RUST_LOG) while running rustc on generator-related code.
This function takes a generator and wraps it in a future, not vice-versa.
This commit adds a suggestion when a `=` character is used when specifying the value of a field in a struct constructor incorrectly instead of a `:` character.
Update std/lib.rs docs to reflect Rust 2018 usage Fixes #56544 This paragraph was written for Rust 2015. Since 2018 has been stable for a while I think we can update it.
Merge visitors in AST validation Cuts runtime for AST validation on `syntex_syntax` from 31.5 ms to 17 ms.
Recover from parse errors in literal struct fields and incorrect float literals Fix #52496.
Explain type mismatch cause pointing to return type when it is `impl Trait` Fix #57743.
Use structured suggestion in stead of notes
Add error for trailing angle brackets. Fixes #54521. This PR adds a error (and accompanying machine applicable suggestion) for trailing angle brackets on function calls with a turbofish. r? @estebank
Stabilize Any::get_type_id and rename to type_id FCP: rust-lang/rust#27745 (comment) Closes rust-lang/rust#27745.
Fix some cross crate existential type ICEs fixes #53443
Fix issue 57762 against a stock LLVM 7. LLVM 7 was released without a necessary fix for a bug in the DWARF discriminant code. This patch changes rustc to use the fallback mode on (non-Rust) LLVM 7. Closes #57762
use port 80 for retrieving GPG key This works around firewalls blocking port 11371. See https://unix.stackexchange.com/questions/75892/keyserver-timed-out-when-trying-to-add-a-gpg-public-key.
…omez Ignore line ending on older git versions On Ubuntu 16.04 git 2.7.4 tries to fix the line ending of `.png` and `.ico` files, and obviously it ruins them. This PR adds an attribute to those files to ignore which line ending they use. r? @GuillaumeGomez
Rollup of 11 pull requests Successful merges: - #57179 (Update std/lib.rs docs to reflect Rust 2018 usage) - #57730 (Merge visitors in AST validation) - #57779 (Recover from parse errors in literal struct fields and incorrect float literals) - #57793 (Explain type mismatch cause pointing to return type when it is `impl Trait`) - #57795 (Use structured suggestion in stead of notes) - #57817 (Add error for trailing angle brackets.) - #57834 (Stabilize Any::get_type_id and rename to type_id) - #57836 (Fix some cross crate existential type ICEs) - #57840 (Fix issue 57762) - #57844 (use port 80 for retrieving GPG key) - #57858 (Ignore line ending on older git versions) Failed merges: r? @ghost
Fix race condition when emitting stored diagnostics r? @michaelwoerister
Add intrinsic to create an integer bitmask from a vector mask This PR adds a new simd intrinsic: `simd_bitmask(vector) -> unsigned integer` that creates an integer bitmask from a vector mask by extracting one bit of each vector lane. This is required to implement: rust-lang/packed_simd#166 . EDIT: the reason we need an intrinsics for this is that we have to truncate the vector lanes to an `<i1 x N>` vector, and then bitcast that to an `iN` integer (while making sure that we only materialize `i8`, ... , `i64` - that is, no `i1`, `i2`, `i4`, types), and we can't do any of that in a Rust library. r? @rkruppe
Remove quote_*! macros This deletes a considerable amount of test cases, some of which we may want to keep. I'm not entirely certain what the primary intent of many of them was; if we should keep them I can attempt to edit each case to continue compiling without the quote_*! macros involved. Fixes #46849. Fixes #12265. Fixes #12266. Fixes #26994. r? @Manishearth
Fix Instant/Duration math precision & associativity on Windows
**tl;dr** Addition and subtraction on Duration/Instant are not associative on windows because we use the perfcounter frequency in every calculation instead of just when we measure time.
This is my first contrib (PR or Issue) to Rust, so please lmk if I've done this wrong. I followed CONTRIBUTING to the extent I could given my system doesn't seem to be able to build the compiler with changes in the source tree. I also asked about this issue in #rust-beginners a week or so ago, before digging through libstd -- I'm unsure if there's a good way to follow up on that, but I'd be happy to update the docs on the timing structs if this fixes the problem.
## Issue
The `Duration` type keeps seconds in the upper-64 and nanoseconds in the lower-32 bits. In theory doing math on these ought to be basically the same as doing math on any other 64 or 32 bit integral number.
On windows (and I think macos too), however, our math gets messy because the Instant type stores the current point in time in units of HPET Performance Counter counts, not nanoseconds, and does unit conversions on every math operation, rather than just when we measure the time from the system clock.
I tried this code:
```
use std::time::{Duration, Instant};
fn main() {
let now = Instant::now();
let offset = Duration::from_millis(5);
assert_eq!((now + offset) - now, (now - now) + offset);
}
```
On UNIX machines (linux and macos) it behaves as you'd expect -- [no crash](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cf2206c0b7e07d8ecc7767a512364094).
On Windows hosts, however, it blows up because of a precision problem in the Instant +/- Duration math:
```
C:\Users\aberg\work\timetest (master -> origin)
λ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running `target\debug\timetest.exe`
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `4.999914ms`,
right: `5ms`', src\main.rs:6:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: process didn't exit successfully: `target\debug\timetest.exe` (exit code: 101)
C:\Users\aberg\work\timetest (master -> origin)
λ cat src\main.rs
use std::time::{Duration, Instant};
fn main() {
let now = Instant::now();
let offset = Duration::from_millis(5);
assert_eq!((now + offset) - now, (now - now) + offset);
}
```
On windows I think this is a consequence of doing the HPET-PerfCounter-Unit conversion on each math operation. I suspect the reason it works on macs is that (from what I could find online) most apple machines report timing in nanoseconds anyway. For anyone interested, the equivalent functions on macos, with a little work to fish out the numerator/denominator from a timebase struct:
* `QueryPerformanceCounter()` -> `mach_absolute_time()`
* `QueryPerformanceFrequency()` -> `mach_timebase_info()`
If this PR ends up working as I expect it to when CI runs the tests, I can make the same changes to the macos implementation.
## Potential Fix
We ought to be able to sort this out by storing nanoseconds, rather than PerfCounter units, that way intermediate math is done in the most precise units we support and we're only doing unit conversions when we actually measure the system clock (and it might even translate to a small perf gain for people doing tons of Instant/Duration math).
I believe this will address the underlying cause of #56034, and make the guessed epsilon constant from #56059 unnecessary. If it's of interest, I can write up how these timing types work on the tier 1 platforms to address #32626 as well, since I'm already in here figuring it out.
## This Patch
To that end, I've got this patch, which I think should fix it on windows, but I'm having trouble testing it -- any time I change anything in libstd I start getting this error, which no amount of clean building seems to resolve:
```
C:\Users\aberg\work\rust (master -> origin)
λ python x.py test --stage 0 --no-doc src/libstd
Updating only changed submodules
Submodules updated in 0.27 seconds
Finished dev [unoptimized] target(s) in 2.41s
Building stage0 std artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Finished release [optimized] target(s) in 6.78s
Copying stage0 std from stage0 (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc / x86_64-pc-windows-msvc)
Building stage0 test artifacts (x86_64-pc-windows-msvc -> x86_64-pc-windows-msvc)
Compiling test v0.0.0 (C:\Users\aberg\work\rust\src\libtest)
error[E0460]: found possibly newer version of crate `std` which `getopts` depends on
--> src\libtest\lib.rs:36:1
|
36 | extern crate getopts;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-sysroot\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-d7a80ca2ae113c97.rlib
crate `std`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-sysroot\lib\rustlib\x86_64-pc-windows-msvc\lib\std-d7a80ca2ae113c97.dll
crate `getopts`: \\?\C:\Users\aberg\work\rust\build\x86_64-pc-windows-msvc\stage0-test\x86_64-pc-windows-msvc\release\deps\libgetopts-ae40a96de5f5d144.rlib
error: aborting due to previous error
For more information about this error, try `rustc --explain E0460`.
error: Could not compile `test`.
To learn more, run the command again with --verbose.
command did not execute successfully: "C:\\Users\\aberg\\work\\rust\\build\\x86_64-pc-windows-msvc\\stage0\\bin\\cargo.exe" "build" "--target" "x86_64-pc-windows-msvc" "-j" "12" "--release" "--manifest-path" "C:\\Users\\aberg\\work\\rust\\src/libtest/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
failed to run: C:\Users\aberg\work\rust\build\bootstrap\debug\bootstrap test --stage 0 --no-doc src/libstd
Build completed unsuccessfully in 0:00:20
```
---
Since you wrote the linked PRs and might remember looking at related problems:
r? @alexcrichton
Get rid of the fake stack frame for reading from constants r? @RalfJung fixes the ice in rust-lang/rust#53708 but still keeps around the wrong "non-exhaustive match" error cc @varkor
Several changes to libunwind for SGX target Two fixes: * #34978 bites again! * __rust_alloc are actually private symbols. Add new public versions. Also, these ones are `extern "C"`. Upstream changes (fortanix/llvm-project#2, fortanix/llvm-project#3): * b7357de Avoid too new relocation types being emitted * 0feefe5 Use new symbol names to call Rust allocator Fixes fortanix/rust-sgx#65
…eGomez rustdoc: fix ICE from loading proc-macro stubs Fixes rust-lang/rust#55399 When trying to resolve a macro, rustdoc first tries to load it from the resolver to see whether it's a Macros 2.0 macro, so it can return that Def before looking for any other kind of macro. However, this becomes a problem when you try to load proc-macros: since you can't use a proc-macro inside its own crate, this lookup also fails when attempting to link to it. However, we have a hint that this lookup will fail: Macros which are actually `ProcMacroStub`s will fail the lookup, so we can use that information to skip loading the macro. Rustdoc will then happily check `resolve.all_macros`, which will return a usable Def that we can link to.
Add os::fortanix_sgx::ffi module This uses the same byte slice accessors that Unix has. The [ABI specifies](https://docs.rs/fortanix-sgx-abi/0.3.2/fortanix_sgx_abi/struct.ByteBuffer.html) byte slices.
Don't export table by default in wasm Revert of rust-lang/rust#53237 As per discussion here rustwasm/team#251
Add suggestion for incorrect field syntax. Fixes #57684. This commit adds a suggestion when a `=` character is used when specifying the value of a field in a struct constructor incorrectly instead of a `:` character. r? @estebank
compiletest: Support opt-in Clang-based run-make tests and use them for testing xLTO. Some cross-language run-make tests need a Clang compiler that matches the LLVM version of `rustc`. Since such a compiler usually isn't available these tests (marked with the `needs-matching-clang` directive) are ignored by default. For some CI jobs we do need these tests to run unconditionally though. In order to support this a `--force-clang-based-tests` flag is added to compiletest. If this flag is specified, `compiletest` will fail if it can't detect an appropriate version of Clang. @rust-lang/infra The PR doesn't yet enable the tests yet. Do you have any recommendation for which jobs to enable them? cc #57438 r? @alexcrichton
Use LLVM intrinsics for saturating add/sub Use the `[su](add|sub).sat` LLVM intrinsics, if we're compiling against LLVM 8, as they should optimize and codegen better than IR based on `[su](add|sub).with.overlow`. For the fallback for LLVM < 8 I'm using the same expansion that target lowering in LLVM uses, which is not the same as Rust currently uses (in particular due to the use of selects rather than branches). Fixes #55286. Fixes #52203. Fixes #44500. r? @nagisa
SGX target: clean up dist builder, update libunwind This incorporates fortanix/llvm-project#4 Fixes fortanix/rust-sgx#65 r? @alexcrichton
Implement Weak::{strong_count, weak_count}
The counters are also useful on `Weak`, not just on strong references (`Rc` or `Arc`).
In situations where there are still strong references around, you can also get these counts by temporarily upgrading and adjusting the values accordingly. Using the methods introduced here is simpler to do, less error-prone (since you can't forget to adjust the counts), can also be used when no strong references are around anymore, and might be more efficient due to not having to temporarily create an `Rc`.
This is mainly useful in assertions or tests of complex data structures. Data structures might have internal invariants that make them the sole owner of a `Weak` pointer, and an assertion on the weak count could be used to ensure that this indeed happens as expected. Due to the presence of `Weak::upgrade`, the `strong_count` becomes less useful, but it still seems worthwhile to mirror the API of `Rc`.
TODO:
* [X] Tracking issue - rust-lang/rust#57977
Closes rust-lang/rust#50158
Add suggestions to deprecation lints Clippy used to do this suggestion, but the clippy lints happen after the deprecation lints so we ended up never seeing the structured suggestions.
Fix grammar in E0283 explanation Author probably meant not "Maybe anything else?", but "Maybe something else?"
Member
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Feb 2, 2019
6: Sync with upstream Rust. r=ltratt a=vext01 This syncs us with upstream rust via a merge commit. It's a huge sync, and as such isn't really reviewable I'm afraid. It was fairly straight forward, just time consuming. The only thing really of note is that I skipped four more uninteresting tests, which could not be fixed by `#[no_trace]`. All tests passing now. Thanks Co-authored-by: David Wood <david@davidtw.co> Co-authored-by: Aaron Hill <aa1ronham@gmail.com> Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Alex Berghage <bearcage@ludumipsum.com> Co-authored-by: Jewoo Lee <shema7k@gmail.com> Co-authored-by: Michael Woerister <michaelwoerister@posteo> Co-authored-by: Mark Simulacrum <mark.simulacrum@gmail.com>
Member
Author
|
It's going to take a while for the build to start, as buildbot is slowly importing each commit into it's sqlite database one at a time :P |
Contributor
Build failed |
Member
Author
|
The failure is a gdb test failure. I forgot to install a Python enabled gdb on the dev box (bencher11), so this is probably why I didn't hit this. Will install gdb and try to repro. |
Member
|
OK, I can do an r plus when you've installed python-gdb? |
Member
Author
|
Member
Author
Not yet. The failure is real. The buildbot machine has the correct gdb, just not my dev machine. It's likely that I need to adjust a/some tests. |
Member
|
Ah, OK. |
Member
Author
|
I was able to repro after installing a python enabled gdb. It was just that one test. If you are OK with the commit, we can squash it in and kick bors. |
Member
|
Please squash. |
vext01
force-pushed
the
yk-sync-upstream
branch
from
5993de5 to
60558cd
Compare
Member
Author
|
splat |
Member
|
bors r+ |
bors bot
added a commit
that referenced
this pull request
Feb 4, 2019
6: Sync with upstream Rust. r=ltratt a=vext01 This syncs us with upstream rust via a merge commit. It's a huge sync, and as such isn't really reviewable I'm afraid. It was fairly straight forward, just time consuming. The only thing really of note is that I skipped four more uninteresting tests, which could not be fixed by `#[no_trace]`. All tests passing now. Thanks Co-authored-by: David Wood <david@davidtw.co> Co-authored-by: Aaron Hill <aa1ronham@gmail.com> Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Alex Berghage <bearcage@ludumipsum.com> Co-authored-by: Jewoo Lee <shema7k@gmail.com> Co-authored-by: Michael Woerister <michaelwoerister@posteo> Co-authored-by: Mark Simulacrum <mark.simulacrum@gmail.com>
Contributor
Build succeeded |
vext01
pushed a commit
to vext01/ykrustc
that referenced
this pull request
Oct 12, 2020
This is a combination of 18 commits. Commit softdevteam#2: Additional examples and some small improvements. Commit softdevteam#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 softdevteam#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 softdevteam#5: Fixed rare issues after testing on real-world crate Commit softdevteam#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 softdevteam#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 softdevteam#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 softdevteam#9: test coverage of inline generic struct function Commit softdevteam#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 softdevteam#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 softdevteam#12: Optimized use of SourceMap and SourceFile Commit softdevteam#13: Fixed a regression, and synched with upstream Some generated test file names changed due to some new change upstream. Commit softdevteam#14: Stripping out crate disambiguators from demangled names These can vary depending on the test platform. Commit softdevteam#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 softdevteam#16: Modify rust-demangler to strip disambiguators by default Commit softdevteam#17: Remove std::process::exit from coverage tests Due to Issue #77553, programs that call std::process::exit() do not generate coverage results on Windows MSVC. Commit softdevteam#18: fix: test file paths exceeding Windows max path len
vext01
pushed a commit
to vext01/ykrustc
that referenced
this pull request
Dec 2, 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 softdevteam#2 [mir_built] building MIR for `str::<impl str>::split_whitespace` softdevteam#3 [unsafety_check_result] unsafety-checking `str::<impl str>::split_whitespace` softdevteam#4 [mir_const] processing MIR for `str::<impl str>::split_whitespace` softdevteam#5 [mir_promoted] processing `str::<impl str>::split_whitespace` softdevteam#6 [mir_borrowck] borrow-checking `str::<impl str>::split_whitespace` softdevteam#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/rust#77467 (cc `@lcnr).` Possibly this needs a crater run? r? `@nikomatsakis` cc `@matthewjasper`
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
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.
This syncs us with upstream rust via a merge commit.
It's a huge sync, and as such isn't really reviewable I'm afraid.
It was fairly straight forward, just time consuming.
The only thing really of note is that I skipped four more uninteresting tests, which could not be fixed by
#[no_trace].All tests passing now.
Thanks