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

Rollup of 14 pull requests #49875

Merged
merged 40 commits into from
Apr 12, 2018
Merged

Rollup of 14 pull requests #49875

merged 40 commits into from
Apr 12, 2018

Conversation

kennytm
Copy link
Member

@kennytm kennytm commented Apr 11, 2018

Successful merges:

Failed merges:

leoyvens and others added 30 commits March 22, 2018 17:42
The behaviour of `resolve_type_vars_if_possible` is simpler and
infallible.
`resolve_type_vars_with_obligations` is the same but doesn't error on unresolved type variables.
In theory this could make more code compile because we don't error or could ommit an otherwise useful error.
In practice I couldn't observe any effect.
While never intended to be stable we forgot that trait impls are insta-stable!
This construction of `FromIterator` wasn't our first choice of how to stabilize
the impl but our hands are tied at this point, so revert back to the original
definition of `FromIterator` before rust-lang#49597

Closes rust-lang#49725
In issue rust-lang#49588, Michael Lamparski pointed out a scenario in which the
non-shorthand-field-patterns lint could be triggered by a macro-expanded
pattern, in a way which was direly unwieldy for the macro author to guard
against and unreasonable to expect the macro user to take into account. We can
avoid this by not linting patterns that come from macro-expansions. Although
this entails accepting "false negatives" where the lint could genuinely improve
macro-templated code, avoiding the reported "true-but-super-annoying positive"
may be worth the trade? (Some precedent for these relative priorities exists as
no. 47775 (5985b0b).)

Resolves rust-lang#49588.
These terminals generally don't support color.

Fixes rust-lang#49191
Building for x86_64-unknown-linux-musl currently results in an executable lacking debug information for musl libc itself. If you request a backtrace in GDB while control flow is within musl – including sycalls made by musl – the result looks like:

#0  0x0000000000434b46 in __cp_end ()
#1  0x0000000000432dbd in __syscall_cp_c ()
rust-lang#2  0x0000000000000000 in ?? ()

i.e. not very helpful. Adding --enable-debug resolves this, and --enable-optimize re-enables optimisations which default to off given the previous flag.
…n, r=scottmcm

Use sort_by_cached_key where appropriate

A follow-up to rust-lang#48639, converting various slice sorting calls to `sort_by_cached_key` when the key functions are more expensive.
…trochenkov

in which the non-shorthand patterns lint keeps its own counsel in macros

In issue rust-lang#49588, Michael Lamparski pointed out a scenario in which the
non-shorthand-field-patterns lint could be triggered by a macro-expanded
pattern, in a way which was direly unwieldy for the macro author to guard
against and unreasonable to expect the macro user to take into account. We can
avoid this by not linting patterns that come from macro-expansions. Although
this entails accepting "false negatives" where the lint could genuinely improve
macro-templated code, avoiding the reported "true-but-super-annoying positive"
may be worth the trade? (Some precedent for these relative priorities exists as
no. 47775 (5985b0b).)

Resolves rust-lang#49588.
…omatsakis

Small nits to make couple of tests pass on mips targets.
@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 11, 2018
@TimNN
Copy link
Contributor

TimNN commented Apr 11, 2018

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[01:27:17] thread '<unnamed>' panicked at 'isize::MAX + 1 should trigger an OOM!', libstd/collections/hash/map.rs:3640:22
---
[01:27:30] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-musl" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "std" "--"
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:02ede5a2:start=1523473051582066794,finish=1523473051595728633,duration=13661839
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:04ee99b9
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:04ee99b9:start=1523473051602017630,finish=1523473051608247498,duration=6229868
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1029a65e
$ dmesg | grep -i kill
[   10.878622] init: failsafe main process (1093) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

1 similar comment
@TimNN
Copy link
Contributor

TimNN commented Apr 11, 2018

Your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[01:27:17] thread '<unnamed>' panicked at 'isize::MAX + 1 should trigger an OOM!', libstd/collections/hash/map.rs:3640:22
---
[01:27:30] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-musl" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "std" "--"
---
$ ls -lat $HOME/Library/Logs/DiagnosticReports/
ls: cannot access /home/travis/Library/Logs/DiagnosticReports/: No such file or directory
travis_time:end:02ede5a2:start=1523473051582066794,finish=1523473051595728633,duration=13661839
travis_fold:end:after_failure.2
travis_fold:start:after_failure.3
travis_time:start:04ee99b9
$ find $HOME/Library/Logs/DiagnosticReports -type f -name '*.crash' -not -name '*.stage2-*.crash' -not -name 'com.apple.CoreSimulator.CoreSimulatorService-*.crash' -exec printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" {} \; -exec head -750 {} \; -exec echo travis_fold":"end:crashlog \; || true
find: `/home/travis/Library/Logs/DiagnosticReports': No such file or directory
travis_time:end:04ee99b9:start=1523473051602017630,finish=1523473051608247498,duration=6229868
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1029a65e
$ dmesg | grep -i kill
[   10.878622] init: failsafe main process (1093) killed by TERM signal

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

…r=michaelwoerister

Do not uppercase-lint #[no_mangle] statics

The reasoning being that `#[no_mangle]` expresses enough intention that there's likely a good reason for the name.

Fixes rust-lang#36258.
Fix "fp" target feature for AArch64

This fixes the following warning on AArch64:
```
'+fp' is not a recognized feature for this target (ignoring feature)
```

Fixes rust-lang#49782
@kennytm
Copy link
Member Author

kennytm commented Apr 11, 2018

@bors r+

Removed #49850 (This is the only PR which touches allocation stuff).
Added #49849.

@bors
Copy link
Contributor

bors commented Apr 11, 2018

📌 Commit aebb2a3 has been approved by kennytm

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 11, 2018
Add --enable-debug flag to musl CI build script

Building for x86_64-unknown-linux-musl currently results in an executable lacking debug information for musl libc itself. If you request a backtrace in GDB while control flow is within musl – including sycalls made by musl – the result looks like:

```
#0  0x0000000000434b46 in __cp_end ()
#1  0x0000000000432dbd in __syscall_cp_c ()
rust-lang#2  0x0000000000000000 in ?? ()
```

i.e. not very helpful. Adding --enable-debug resolves this, and --enable-optimize re-enables optimisations which default to off given the previous flag.
…m, r=nikomatsakis

proc_macro: Generalize `FromIterator` impl

While never intended to be stable we forgot that trait impls are insta-stable!
This construction of `FromIterator` wasn't our first choice of how to stabilize
the impl but our hands are tied at this point, so revert back to the original
definition of `FromIterator` before rust-lang#49597

Closes rust-lang#49725
Fix ICE with impl Trait

Fixes rust-lang#49556 (comment). May or may not fix 49556 itself. Closures like `|x: &'a _| x` has `ClosureSubsts` of `fn(&'a _) -> &'(ReScope) _`, so `tcx.note_and_explain_free_region` (called [here](https://github.com/rust-lang/rust/blob/a143462783cec88b7b733e8aa09990bfeb59f754/src/librustc/infer/anon_types/mod.rs#L572)) panics.
…atsakis

Replace `structurally_resolved_type` in casts check.

The behaviour of `resolve_type_vars_if_possible` is simpler and infallible. Other minor refactorings.

I'm not sure if this is backwards compatible, in theory resolving obligations between two cast checks could solve a dependency between them, but I don't know if that's actually possible and it doesn't sound like something we'd want to support.
@kennytm kennytm changed the title Rollup of 12 pull requests Rollup of 14 pull requests Apr 11, 2018
@kennytm
Copy link
Member Author

kennytm commented Apr 11, 2018

@bors r+

Removed #49698 (expecting Cargo.lock conflict).
Added #49734, #49730, #48270

@bors
Copy link
Contributor

bors commented Apr 11, 2018

📌 Commit 9f6e5ae has been approved by kennytm

@bors
Copy link
Contributor

bors commented Apr 11, 2018

⌛ Testing commit 9f6e5ae with merge e28ef22...

bors added a commit that referenced this pull request Apr 11, 2018
Rollup of 14 pull requests

Successful merges:

 - #49525 (Use sort_by_cached_key where appropriate)
 - #49575 (Stabilize `Option::filter`.)
 - #49614 (in which the non-shorthand patterns lint keeps its own counsel in macros)
 - #49665 (Small nits to make couple of tests pass on mips targets.)
 - #49781 (add regression test for #16223 (NLL): use of collaterally moved value)
 - #49795 (Properly look for uninhabitedness of variants in niche-filling check)
 - #49809 (Stop emitting color codes on TERM=dumb)
 - #49856 (Do not uppercase-lint #[no_mangle] statics)
 - #49863 (fixed typo)
 - #49857 (Fix "fp" target feature for AArch64)
 - #49849 (Add --enable-debug flag to musl CI build script)
 - #49734 (proc_macro: Generalize `FromIterator` impl)
 - #49730 (Fix ICE with impl Trait)
 - #48270 (Replace `structurally_resolved_type` in casts check.)

Failed merges:
@bors
Copy link
Contributor

bors commented Apr 12, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: kennytm
Pushing e28ef22 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.