forked from rust-lang/rust
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update rustc #8
Merged
Merged
Update rustc #8
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
stabilize RangeBounds collections_range rust-lang#30877 The FCP for rust-lang#30877 closed last month, with the decision to: 1. move from `collections::range::RangeArgument` to `ops::RangeBounds`, and 2. rename `start()` and `end()` to `start_bounds()` and `end_bounds()`. Simon Sapin already moved it to `ops::RangeBounds` in rust-lang#49163. I renamed the functions, and removed the old `collections::range::RangeArgument` alias. This is my first Rust PR, please let me know if I can improve anything. This passes all tests for me, except the `clippy` tool (which uses `RangeArgument::start()`). I considered deprecating `start()` and `end()` instead of removing them, but the contribution guidelines indicate we can break `clippy` temporarily. I thought it was best to remove the functions, since we're worried about name collisions with `Range::start` and `end`. Closes rust-lang#30877.
2093 infer outlives requirements Tracking issue: rust-lang#44493 RFC: rust-lang/rfcs#2093 - [x] add `rustc_attrs` flag - [x] use `RequirePredicates` type - [x] handle explicit predicates on `dyn` Trait - [x] handle explicit predicates on projections - [x] more tests - [x] remove `unused`, `dead_code` and etc.. - [x] documentation
Lone breaks outside of loops create errors in the loop check pass but as they are not fatal, compilation continues. MIR building code assumes all HIR break statements to point to valid locations and fires ICEs if this assumption is violated. In normal compilation, this causes no issues, as code apparently prevents MIR from being built if errors are present. However, before that, typecheck runs and with it MIR const eval. Here we operate differently from normal compilation: it doesn't check for any errors except for type checker ones and then directly builds the MIR. This constellation causes an ICE-on-error if bogus break statements are being put into array length expressions. This commit fixes this ICE by letting typecheck fail if bogus break statements are encountered. This way, MIR const eval fails cleanly with a type check error. Fixes rust-lang#50576 Fixes rust-lang#50581
There is no precedent for the `empty` name -- we do not have `Vec::empty` or `HashMap::empty` etc.
Don't ICE if crate has no valid crate types left fixes rust-lang#50993
The `FatalError.raise()` might seem unmotivated (in most places in the compiler, `err.emit()` suffices), but it's actually used to maintain behavior (viz., stop lexing, don't emit potentially spurious errors looking for the next token after the bad Unicodepoint in the exponent): the previous revision's `self.err_span_` ultimately calls `Handler::emit`, which aborts if the `Handler`'s continue_after_error flag is set, which seems to typically be true during lexing (see `phase_1_parse_input` and and how `CompileController::basic` has `continue_parse_after_error: false` in librustc_driver). Also, let's avoid apostrophes in error messages (the present author would argue that users expect a reassuringly detached, formal, above-it-all tone from a Serious tool like a compiler), and use an RLS-friendly structured suggestion. Resolves rust-lang#49746.
…g-impl, r=KodrAus Improve `Debug` impl of `time::Duration` Hi there! For a long time now, I was getting annoyed by the derived `Debug` impl of `Duration`. Usually, I use `Duration` to either do quick'n'dirty benchmarking or measuring the time of some operation in general. The output of the derived Debug impl is hard to parse for humans: is { secs: 0, nanos: 968360102 } or { secs: 0, nanos 98507324 } longer? So after running into the annoyance several times (sometimes building my own function to print the Duration properly), I decided to tackle this. Now the output looks like this: ``` Duration::new(1, 0) => 1s Duration::new(1, 1) => 1.000000001s Duration::new(1, 300) => 1.0000003s Duration::new(1, 4000) => 1.000004s Duration::new(1, 600000) => 1.0006s Duration::new(1, 7000000) => 1.007s Duration::new(0, 0) => 0ns Duration::new(0, 1) => 1ns Duration::new(0, 300) => 300ns Duration::new(0, 4001) => 4.001µs Duration::new(0, 600300) => 600.3µs Duration::new(0, 7000000) => 7ms ``` Note that I implemented the formatting manually and didn't use floats. No information is "lost" when printing. So `Duration::new(123_456_789_000, 900_000_001)` prints as `123456789000.900000001s`. ~~This is not yet finished~~, but I wanted to open the PR now already in order to get some feedback (maybe everyone likes the derived impl). ### Still ToDo: - [x] Respect precision ~~and width~~ parameter of the formatter (see [this comment](rust-lang#50364 (comment))) ### Alternatives/Decisions - Should large durations displayed in minutes, hours, days, ...? For now, I decided not to because the current formatting is close the how a `Duration` is stored. From this new `Debug` output, you can still easily see what the values of `secs` and `nanos` are. A formatting like `3h 27m 12s 9ms` might be more appropriate for a `Display` impl? - Should this rather be a `Display` impl and should `Debug` be derived? Maybe this formatting is too fancy for `Debug`? In my opinion it's not and, as already mentioned, from the current format one can still very easily determine the values for `secs` and `nanos`. - Whitespace between the number and the unit? ### Notes for reviewers - ~~The combined diff sucks. Rather review both commits individually.~~ - ~~In the unit test, I am building my own type implementing `fmt::Write` to test the output. Maybe there is already something like that which I can use?~~ - My `Debug` impl block is marked as `#[stable(...)]`... but that's fine since the derived Debug impl was stable already, right? --- ~~Apart from the main change, I moved all `time` unit tests into the `tests` directory. All other `libcore` tests are there, so I guess it was simply an oversight. Prior to this change, the `time` tests weren't run, so I guess this is kind of a bug fix. If my `Debug` impl is rejected, I can of course just send the fix as PR.~~ (this was already merged in rust-lang#50466)
…sakis std: Ensure OOM is classified as `nounwind` OOM can't unwind today, and historically it's been optimized as if it can't unwind. This accidentally regressed with recent changes to the OOM handler, so this commit adds in a codegen test to assert that everything gets optimized away after the OOM function is approrpiately classified as nounwind Closes rust-lang#50925
…ions, r=petrochencov Underline multiple suggested replacements in the same line <img width="685" alt="screen shot 2018-05-22 at 21 06 48" src="https://user-images.githubusercontent.com/1606434/40403051-174f3180-5e04-11e8-86b6-261630c5ff80.png"> Follow up to rust-lang#50943. Fix rust-lang#50977.
…dreavus Add documentation about env! second argument Fixes rust-lang#48044. r? @QuietMisdreavus
Remove unused lowering field and method r? @nikomatsakis So while trying to understand lowering better, I found out that there's something related to creating definitions. Analyzing that further, I realized that it is entirely dead code. The `parent_def` field was only ever used for setting and resetting the field itself. The field was never read anywhere else and thus its value was entirely unused. Maybe the `unused_field` lint should detect when the only use of a field is the field being read without using the read value other than writing back to the field? The diff is best viewed without whitespace changes getting in the way: https://github.com/rust-lang/rust/pull/51034/files?w=1
…s, r=nikomatsakis Use AllFacts from polonius-engine
…r=QuietMisdreavus Add more missing examples for Formatter r? @QuietMisdreavus
Mention and use `Once::new` instead of `ONCE_INIT`
What does an expression look like, that consists only of special characters? I had a lot of fun creating this together with @CryZe
Update nomicon link in transmute docs The list of "invalid primitive values" has moved to a different URL within the Rustonomicon.
Add inner links in documentation From [this SO question](https://stackoverflow.com/q/50518757/2733851) it looks like this page isn't really clear. I personally do think this page is quite clear, the only think I could think of was adding some references.
Fail typecheck if we encounter a bogus break Lone breaks outside of loops create errors in the loop check pass but as they are not fatal, compilation continues. MIR building code assumes all HIR break statements to point to valid locations and fires ICEs if this assumption is violated. In normal compilation, this causes no issues, as code apparently prevents MIR from being built if errors are present. However, before that, typecheck runs and with it MIR const eval. Here we operate differently from normal compilation: it doesn't check for any errors except for type checker ones and then directly builds the MIR. This constellation causes an ICE-on-error if bogus break statements are being put into array length expressions. This commit fixes this ICE by letting typecheck fail if bogus break statements are encountered. This way, MIR const eval fails cleanly with a type check error. Fixes rust-lang#50576 Fixes rust-lang#50581
Rename TokenStream::empty to TokenStream::new There is no precedent for the `empty` name -- we do not have `Vec::empty` or `HashMap::empty` etc. I would propose landing this but reflecting it in a non-breaking release of proc-macro2 that provides both `new` and a deprecated `empty` constructor. Tracking issue: rust-lang#38356 r? @alexcrichton
Rollup of 11 pull requests Successful merges: - rust-lang#50987 (Underline multiple suggested replacements in the same line) - rust-lang#51014 (Add documentation about env! second argument) - rust-lang#51034 (Remove unused lowering field and method) - rust-lang#51047 (Use AllFacts from polonius-engine) - rust-lang#51048 (Add more missing examples for Formatter) - rust-lang#51056 (Mention and use `Once::new` instead of `ONCE_INIT`) - rust-lang#51059 (What does an expression look like, that consists only of special characters?) - rust-lang#51065 (Update nomicon link in transmute docs) - rust-lang#51067 (Add inner links in documentation) - rust-lang#51070 (Fail typecheck if we encounter a bogus break) - rust-lang#51073 (Rename TokenStream::empty to TokenStream::new) Failed merges:
…henkov restore emplacement syntax (obsolete) Fix rust-lang#50832 r? @petrochenkov
Use `Ident`s for fields in HIR Continuation of rust-lang#49718, part of rust-lang#49300
…omatsakis Fix behaviour of divergence in while loop conditions This fixes `'a: while break 'a {};` being treated as diverging, by tracking break expressions in the same way as in `loop` expressions. Fixes rust-lang#50856. r? @nikomatsakis
…robust-wrt-nll, r=nikomatsakis make ui tests robust with respect to NLL This PR revises the `ui` tests that I could quickly identify that: 1. previously had successful compilations under non-lexical lifetimes (NLL) because they assumed lexical lifetimes, but 2. such assumption of lexical lifetimes was actually not necessarily part of the spirit of the original issue/bug we want to witness. In many cases, this is simply a matter of adding a use of a borrow so that it gets extended long enough to observe a conflict. (In some cases the revision was more subtle, such as adding a destructor, or revising the order of declaration of some variables.) ---- With these test revisions in place, I subsequently updated the expected stderr output under the NLL compiletest mode. So now we should get even more testing of NLL than we were before. Fix rust-lang#51025
…r, r=Mark-Simulacrum [master] Release notes for 1.26.1 None
The issue was used for both box syntax as well as placement new. It got closed due to placement new being unapproved. So a new one got created for box syntax, yet neither the unstable book nor feature_gate.rs got updated. We are doing this now.
Add std/core to prelude if extern_prelude enabled Fixes rust-lang#50605
This is stable, and so no longer needed
Make the OOM hook return `()` rather than `!` Per discussion in rust-lang#51245 (comment) This allows more flexibility in what can be done with the API. This also splits `rtabort!` into `dumb_print` happening in the default hook and `abort_internal`, happening in the actual oom handler after calling the hook. Registering an empty function thus makes the oom handler not print anything but still abort. Cc: @alexcrichton
for both Vec<T> and String - eliminates the boolean first flag in fn join() for String only - eliminates repeated bounds checks in join(), concat() - adds fast paths for small string separators up to a len of 4 bytes
old tests cover the new fast path of str joining already this adds tests for joining into Strings with long separators (>4 byte) and for joining into Vec<T>, T: Clone + !Copy. Vec<T: Copy> will be specialised when specialisation type inference bugs are fixed.
further reduce unsafe fn calls reduce right drift assert! sufficient capacity
optimize joining for slices This improves the speed of string joining up to 3x. It removes the boolean flag check every iteration, eliminates repeated bounds checks and adds a fast paths for small separators up to a len of 4 bytes These optimizations gave me ~10%, ~50% and ~80% improvements respectively over the previous speed. Those are multiplicative. 3x improvement happens for the optimal case of joining many small strings together in my microbenchmarks. Improvements flatten out for larger strings of course as more time is spent copying bits around. I've run a few benchmarks [with this code](https://github.com/Emerentius/join_bench). They are pretty noise despite high iteration counts, but in total one can see the trends. ``` len_separator len_string n_strings speedup 4 10 10 2.38 4 10 100 3.41 4 10 1000 3.43 4 10 10000 3.25 4 100 10 2.23 4 100 100 2.73 4 100 1000 1.33 4 100 10000 1.14 4 1000 10 1.33 4 1000 100 1.15 4 1000 1000 1.08 4 1000 10000 1.04 10 10 10 1.61 10 10 100 1.74 10 10 1000 1.77 10 10 10000 1.75 10 100 10 1.58 10 100 100 1.65 10 100 1000 1.24 10 100 10000 1.12 10 1000 10 1.23 10 1000 100 1.11 10 1000 1000 1.05 10 1000 10000 0.997 100 10 10 1.66 100 10 100 1.78 100 10 1000 1.28 100 10 10000 1.16 100 100 10 1.37 100 100 100 1.26 100 100 1000 1.09 100 100 10000 1.0 100 1000 10 1.19 100 1000 100 1.12 100 1000 1000 1.05 100 1000 10000 1.12 ``` The string joining with small or empty separators is now ~50% faster than the old concatenation (small strings). The same approach can also improve the performance of joining into vectors. If this approach is acceptable, I can apply it for concatenation and for vectors as well. Alternatively, concat could just call `.join("")`.
Simplify HashMap layout calculation by using Layout `RawTable` uses a single allocation to hold both the array of hashes and the array of key/value pairs. This PR changes `RawTable` to use `Layout` when calculating the amount of memory to allocate instead of performing the calculation manually. r? @SimonSapin
Make GlobalCtxt thread-safe r? @michaelwoerister
Tweak output on E0599 for assoc fn used as method - Use suggestion instead of `help` when possible - Add primary span label - Remove incorrect `help` suggestion using incorrect syntax - Do not refer to only one possible candidate as `candidate #1`, refer to it as `the candidate`
Replace `if` with `if and only if` in the definition dox of `Sync` The old text was: "The precise definition is: a type `T` is `Sync` if `&T` is Send." Since we've also got ``` impl<'a, T> Send for &'a T where T: Sync + ?Sized, ``` I purpose we can change the `if` to `if and only if` to make it more precise.
…ce, r=QuietMisdreavus Add missing whitespace in num example r? @QuietMisdreavus
…=QuietMisdreavus Remove feature flag from fs::read_to_string example This is stable, and so no longer needed
…s, r=Mark-Simulacrum Pull 1.26.2 release notes into master None
…crum Rollup of 5 pull requests Successful merges: - rust-lang#51135 (Tweak output on E0599 for assoc fn used as method) - rust-lang#51152 (Replace `if` with `if and only if` in the definition dox of `Sync`) - rust-lang#51262 (Add missing whitespace in num example) - rust-lang#51272 (Remove feature flag from fs::read_to_string example) - rust-lang#51286 (Pull 1.26.2 release notes into master) Failed merges:
fs: copy: Add EPERM to fallback error conditions Fixes rust-lang#51266
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.
settings.html
,all.html
,aliases.js
.