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

cycle error building rustc with debug logging #61577

Closed
ehuss opened this issue Jun 6, 2019 · 2 comments · Fixed by #66594
Closed

cycle error building rustc with debug logging #61577

ehuss opened this issue Jun 6, 2019 · 2 comments · Fixed by #66594
Labels
A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. A-traits Area: Trait system C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Jun 6, 2019

When using RUSTC_LOG to debug building rustc itself, I ran into this error:

error[E0391]: cycle detected when processing `hir::def::<impl at src/librustc/hir/def.rs:255:1: 270:2>::present_items::{{opaque}}#0`
   --> src/librustc/hir/def.rs:262:35
    |
262 |     pub fn present_items(self) -> impl Iterator<Item=T> {
    |                                   ^^^^^^^^^^^^^^^^^^^^^
    |                                   |
    |                                   in this expansion of `desugaring of `existential type``
    |                                   in this macro invocation
    |
note: ...which requires processing `hir::def::<impl at src/librustc/hir/def.rs:255:1: 270:2>::present_items::{{opaque}}#0`...
   --> src/librustc/hir/def.rs:262:35
    |
262 |     pub fn present_items(self) -> impl Iterator<Item=T> {
    |                                   ^^^^^^^^^^^^^^^^^^^^^
    |                                   |
    |                                   in this expansion of `desugaring of `existential type``
    |                                   in this macro invocation
note: ...which requires processing `hir::def::<impl at src/librustc/hir/def.rs:255:1: 270:2>::present_items::{{opaque}}#0`...
   --> src/librustc/hir/def.rs:262:35
    |
262 |     pub fn present_items(self) -> impl Iterator<Item=T> {
    |                                   ^^^^^^^^^^^^^^^^^^^^^
    |                                   |
    |                                   in this expansion of `desugaring of `existential type``
    |                                   in this macro invocation
    = note: ...which again requires processing `hir::def::<impl at src/librustc/hir/def.rs:255:1: 270:2>::present_items::{{opaque}}#0`, completing the cycle
note: cycle used when processing `hir::def::<impl at src/librustc/hir/def.rs:255:1: 270:2>::present_items`
   --> src/librustc/hir/def.rs:262:5
    |
262 |     pub fn present_items(self) -> impl Iterator<Item=T> {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Repro:

  1. Set debug = true in config.toml.
  2. ./x.py build to get a debug compiler (and go through several steps in stage 1 we want to skip).
  3. touch src/librustc/lib.rs
  4. RUSTC_LOG=rustc::ty=debug ./x.py build --stage=1 --keep-stage=0 > dlog 2>&1

The last step should rebuild librustc using a compiler with debugging enabled. I imagine there is a faster way to do this, but these are the simplest instructions I could think of.

Is this known/expected? I have no idea what the error means, but it makes debugging more difficult.

Currently on master (7cdaffd).

@jonas-schievink jonas-schievink added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) A-traits Area: Trait system C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 6, 2019
@jonas-schievink
Copy link
Contributor

Ran into the same problem while investigating #60414 (comment), very annoying indeed!

@jonas-schievink jonas-schievink added the A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. label Jun 26, 2019
@Aaron1011
Copy link
Member

I ran into a similar issue when using RUSTC_LOG=rustc::ty=debug - however, I'm not sure if this is exactly the same cause.

I tracked down the cycle error I saw to the pretty-printing code for opaque types. When not printing in 'verbose mode', it attempts to call tcx.predicates_of on the opaque type. If we're already trying to get the predicates of an opaque type, this results in a cycle error.

As a hacky workaround, I changed if self.tcx().sess.verbose() to if self.tcx().sess.verbose() || true. However, the real fix is to avoid running queries during type pretty printing.

Centril added a commit to Centril/rust that referenced this issue Nov 24, 2019
…matthewjasper

Fix cycle when debug-printing opaque types

Fixes rust-lang#61577

When printing an opaque type in non-verbose mode, we use the
`tcx.predicates_of` query to retrieve the opaque type's bounds for
pretty-printing. However, the pervasiveness of logging within librustc
means that we may already be executing `tcx.predicates_of` for the
opaque type we're trying to print, leading to a cycle error.

This commit adds a new 'no queries' thread-local flag to the pretty
printer. This flag is enabled during the computation of `predicates_of`
for opaque types, and causes us to print the opaque type in 'verbose'
mode (which does not require computing any additinal queries). This
should only affect debug logging for highly nested log messages, not any
user-visible output.
@bors bors closed this as completed in bc7b17c Nov 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-impl-trait Area: impl Trait. Universally / existentially quantified anonymous types with static dispatch. A-traits Area: Trait system C-bug Category: This is a bug. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants