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

create a "provisional cache" to restore performance in the case of cycles #61754

Merged
merged 12 commits into from
Jun 16, 2019

Conversation

nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Jun 11, 2019

Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the main cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.

Caveat: I've not run x.py test in full yet.

r? @pnkfelix
cc @arielb1

Fixes #60846

It does not, in fact, execute in a recursive context.
I tried to propagate this information with the return value, but I
found a curiosity (actually, something that I'm not keen on in
general) -- in particular, the candidate cache urrently invokes
evaluation, which may detect a cycle, but the "depth" that results
from that are is easily propagated back out. This probably means that
the candidate caching mechanism *itself* is sort of problematic, but
I'm choosing to ignore that in favor of a more ambitious rewrite
later.
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 11, 2019
@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of 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.
travis_time:end:10dd4c84:start=1560294739297847544,finish=1560294740197612609,duration=899765065
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:59:29] .................................................................................................... 4900/5669
[00:59:33] .................................................................................................... 5000/5669
[00:59:36] .................................................................................................... 5100/5669
[00:59:40] .................................................................................................... 5200/5669
[00:59:44] ................F................................................................................... 5300/5669
[00:59:50] .................................................................................................... 5500/5669
[00:59:53] .................................................................................................... 5600/5669
[00:59:55] .......i.............................................................
[00:59:55] failures:
[00:59:55] failures:
[00:59:55] 
[00:59:55] ---- [ui] ui/traits/cycle-cache-err-60010.rs stdout ----
[00:59:55] 
[00:59:55] error: ui test compiled successfully!
[00:59:55] status: exit code: 0
[00:59:55] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/ui/traits/cycle-cache-err-60010.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/traits/cycle-cache-err-60010" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/traits/cycle-cache-err-60010/auxiliary" "-A" "unused"
[00:59:55] ------------------------------------------
[00:59:55] 
[00:59:55] ------------------------------------------
[00:59:55] stderr:
---
[00:59:55] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:521:22
[00:59:55] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[00:59:55] 
[00:59:55] 
[00:59:55] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/ui" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "ui" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:59:55] 
[00:59:55] 
[00:59:55] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:59:55] Build completed unsuccessfully in 0:55:03

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)

src/libsyntax_pos/lib.rs Outdated Show resolved Hide resolved
@nikomatsakis
Copy link
Contributor Author

nikomatsakis commented Jun 12, 2019

So I think I found the bug causing cycle-cache-err-60010.rs to unexpectedly pass -- copy-and-paste error. Working on a fix.

UPDATE: Or...not. Not sure what problem is.

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-6.0 of 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.
travis_time:end:1e189384:start=1560362267693801950,finish=1560362363448156592,duration=95754354642
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[01:01:51] .................................................................................................... 2100/2920
[01:02:13] .................................................................................................... 2200/2920
[01:02:14] .............test [run-pass] run-pass/mpsc_stress.rs has been running for over 60 seconds
[01:02:23] ....................................................................................... 2300/2920
[01:02:41] ........ii..........................................................F............................... 2400/2920
[01:03:23] .................................................................................................... 2600/2920
[01:03:32] .................................................................................................... 2700/2920
[01:03:42] .................................................................................................... 2800/2920
[01:03:54] .................................................................................................... 2900/2920
[01:03:54] .................................................................................................... 2900/2920
[01:03:57] ....................
[01:03:57] failures:
[01:03:57] 
[01:03:57] ---- [run-pass] run-pass/statics/static-recursive.rs stdout ----
[01:03:57] 
[01:03:57] error: test compilation failed although it shouldn't!
[01:03:57] status: exit code: 101
[01:03:57] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/run-pass/statics/static-recursive.rs" "-Zthreads=1" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/statics/static-recursive/a" "-Crpath" "-O" "-Cdebuginfo=0" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass/statics/static-recursive/auxiliary"
[01:03:57] ------------------------------------------
[01:03:57] 
[01:03:57] ------------------------------------------
[01:03:57] stderr:
---
[01:03:57] note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
[01:03:57] 
[01:03:57] note: rustc 1.37.0-dev running on x86_64-unknown-linux-gnu
[01:03:57] 
[01:03:57] note: compiler flags: -Z threads=1 -Z ui-testing -Z unstable-options -C prefer-dynamic -C rpath -C debuginfo=0
[01:03:57] 
[01:03:57] ------------------------------------------
[01:03:57] 
[01:03:57] 
---
[01:03:57] thread 'main' panicked at 'Some tests failed', src/tools/compiletest/src/main.rs:521:22
[01:03:57] note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[01:03:57] 
[01:03:57] 
[01:03:57] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/run-pass" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-pass" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-6.0/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "6.0.0\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[01:03:57] 
[01:03:57] 
[01:03:57] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:03:57] Build completed unsuccessfully in 0:59:51
---
travis_time:end:1446a883:start=1560366212864650574,finish=1560366212869498993,duration=4848419
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:004e4467
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:03ecbb40
travis_time:start:03ecbb40
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:07bcd09b
$ dmesg | grep -i kill

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)

@rust-highfive
Copy link
Collaborator

The job mingw-check of 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.
travis_time:end:390bcf23:start=1560376588476926289,finish=1560376674303868118,duration=85826941829
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:05:07]    Compiling rustc_macros v0.1.0 (/checkout/src/librustc_macros)
[00:05:13]     Checking syntax_pos v0.0.0 (/checkout/src/libsyntax_pos)
[00:05:15]     Checking rustc_errors v0.0.0 (/checkout/src/librustc_errors)
[00:05:15]     Checking fmt_macros v0.0.0 (/checkout/src/libfmt_macros)
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

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)

@nikomatsakis
Copy link
Contributor Author

I think the problem is fixed, not sure what's up with travis

/// error. When we pop the node at `reached_depth` from the stack, we
/// can commit all the things that remain in the provisional cache.
struct ProvisionalEvaluationCache<'tcx> {
/// next "depth first number" to issue -- just a counter
Copy link
Member

@pnkfelix pnkfelix Jun 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: add (DFN) after "depth first number" as a way of informally binding the acronym in a manner that makes it show up when one does a (case-sensitive) search to find such a binding in the docs.

Copy link
Member

@pnkfelix pnkfelix Jun 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(oh I guess it does show up in this "binding" fashion below in the doc for struct ProvisionalEvaluation)

Copy link
Member

@pnkfelix pnkfelix Jun 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might also explicitly state that it is "depth-first number" (and not just "depth") is that this identifies where a node falls in the graph when laid out in depth-first order, right?

(I briefly thought "there must be a standard term for this notion that is less awkward, but I didn't see anything better than "DFS number", which does not seem superior to "DFN")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DFN is terminology that I took from various prolog papers -- probably this one:

Efficient Top-Down Computation of Queries Under the Well-formed Semantics (Chen, Swift, and Warren; Journal of Logic Programming '95)

so it's not totally unstandard =)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm not sure why i'm tracking both depth and dfn -- I think you only need the DFN.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I just started with depth and had to add DFN later and didn't realize I could simplify it.

put back negative impls to ensure `Span` is not `Send` nor `Sync`
@pnkfelix
Copy link
Member

none of my feedback is severe enough to block an r+, so I'll go ahead and mark it so.

@pnkfelix
Copy link
Member

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Jun 13, 2019

📌 Commit bb97fe0 has been approved by pnkfelix

@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 Jun 13, 2019
@rust-highfive
Copy link
Collaborator

The job mingw-check of 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.
travis_time:end:37b4293c:start=1560420473892025995,finish=1560420592042553859,duration=118150527864
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
$ export AWS_ACCESS_KEY_ID=AKIA46X5W6CZEJZ6XT55
---
[00:05:38]    Compiling rustc_macros v0.1.0 (/checkout/src/librustc_macros)
[00:05:44]     Checking syntax_pos v0.0.0 (/checkout/src/libsyntax_pos)
[00:05:46]     Checking rustc_errors v0.0.0 (/checkout/src/librustc_errors)
[00:05:46]     Checking fmt_macros v0.0.0 (/checkout/src/libfmt_macros)
No output has been received in the last 30m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

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)

@mati865
Copy link
Contributor

mati865 commented Jun 13, 2019

mingw-check runs with RUN_CHECK_WITH_PARALLEL_QUERIES=1 and seems to hang like it did before 3ed0561

Shouldn't this be removed as well?

// Ensure all fields of `TokenTree` is `Send` and `Sync`.
#[cfg(parallel_compiler)]
fn _dummy()
where
Token: Send + Sync,
DelimSpan: Send + Sync,
DelimToken: Send + Sync,
TokenStream: Send + Sync,
{}

@Zoxc
Copy link
Contributor

Zoxc commented Jun 13, 2019

You'll need cfg(bootstrap) on the workaround in 3ed0561.

@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 16, 2019
@Zoxc
Copy link
Contributor

Zoxc commented Jun 16, 2019

Is that a flaky xsv test @rust-lang/infra ?

@Mark-Simulacrum
Copy link
Member

It doesn't look like it should be based on the amount of panics, but I'm not sure. It does use quickcheck which introduces a level of randomness which could lead to it being spurious and/or not related to this PR in particular (cc @BurntSushi as the author).

Since I suspect it is unrelated to this PR, let's @bors retry xsv spurious test

@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 Jun 16, 2019
@bors
Copy link
Contributor

bors commented Jun 16, 2019

⌛ Testing commit 0baa925 with merge e3175c3...

bors added a commit that referenced this pull request Jun 16, 2019
create a "provisional cache" to restore performance in the case of cycles

Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in #60846 -- I plan to add a perf.rust-lang.org regression test to track this.

Caveat: I've not run `x.py test` in full yet.

r? @pnkfelix
cc @arielb1

Fixes #60846
@bors
Copy link
Contributor

bors commented Jun 16, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: pnkfelix
Pushing e3175c3 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 16, 2019
@bors bors merged commit 0baa925 into rust-lang:master Jun 16, 2019
@pnkfelix
Copy link
Member

Given the number of beta-regressions that we believe were injected by PR #60444 (see #61960), I am beta-nominating this PR.

However, I am also a little nervous about back-porting this PR to the current beta, which (if I understand correctly) is scheduled to become the stable release in about two weeks, but his PR itself only landed on nightly 3 days ago. So: Do not immediately assume my nomination is also an endorsement for a backport; I am just trying to initiate discussion of the matter.

@pnkfelix pnkfelix added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jun 19, 2019
@pnkfelix pnkfelix added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 20, 2019
@pnkfelix
Copy link
Member

discussed at T-compiler meeting. Given that this just landed in nightly, we're going to give this a week to bake before officially accepting for beta backport. (But our current inclination is to accept.)

@Mark-Simulacrum
Copy link
Member

@rust-lang/compiler We need to get beta backports approved a little earlier this cycle as we're promoting beta->stable on Saturday. If we could get an FCP going for beta-accepted on this PR that'd be great; or if someone wants to unilaterally beta accept that works too.

@pnkfelix
Copy link
Member

I'm going to unilaterally beta-accept this.

We did talk about the beta-nom of #61754 at the T-compiler meeting last week, and the main misgivings we had were: 1. it didn't seem to resolve all of the performance and overflow issues, 2. it was a bit big+risky for a backport, and 3. it hadn't had much time to bake.

But, now it has had time to bake, and (as also stated at the meeting), it fixes a critical issue.

So, accepting for beta-backport.

@pnkfelix pnkfelix added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Jun 26, 2019
Mark-Simulacrum pushed a commit to pietroalbini/rust that referenced this pull request Jun 26, 2019
…caching-perf-3, r=pnkfelix

create a "provisional cache" to restore performance in the case of cycles

Introduce a "provisional cache" that caches the results of auto trait resolutions but keeps them from entering the *main* cache until everything is ready. This turned out a bit more complex than I hoped, but I don't see another short term fix -- happy to take suggestions! In the meantime, it's very clear we need to rework the trait solver. This resolves the extreme performance slowdown experienced in rust-lang#60846 -- I plan to add a perf.rust-lang.org regression test to track this.

Caveat: I've not run `x.py test` in full yet.

r? @pnkfelix
cc @arielb1

Fixes rust-lang#60846
bors added a commit that referenced this pull request Jun 26, 2019
[beta] Rollup backports

Rolled up:

* [beta] Comment out dev key #61700

Cherry picked:

* Dont ICE on an attempt to use GAT without feature gate #61118
* Fix cfg(test) build for x86_64-fortanix-unknown-sgx #61503
* Handle index out of bound errors during const eval without panic #61598
* Hygienize macros in the standard library #61629
* Fix ICE involving mut references #61947
* rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`. #61896
* Revert "Set test flag when rustdoc is running with --test option" #61199
* create a "provisional cache" to restore performance in the case of cycles #61754

r? @ghost
@pnkfelix
Copy link
Member

pnkfelix commented Jul 4, 2019

This should have had the beta-nominated flag removed as part of PR #62065, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

forego caching cycles leads to a severe perf regression
9 participants