Skip to content
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 3,288 commits into from
Jun 5, 2018
Merged

Update rustc #8

merged 3,288 commits into from
Jun 5, 2018

Conversation

onur
Copy link
Owner

@onur onur commented May 2, 2018

  • Linux build
  • Windows build
  • OSX build
  • Add settings.html, all.html, aliases.js.
  • Update debian/

bors and others added 30 commits May 25, 2018 22:18
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:
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.
bors and others added 29 commits June 1, 2018 10:48
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
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
@onur onur merged commit 8f8f0ea into docs.rs Jun 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet