Panic when compiling gluon on 1.46

I created an empty hello world project with Cargo, added the "gluon" library to it, then tried to compile.
I understand this is something more than just an incompatibility between the nightly compiler and the library.
Does not occur on stable.

Code

There's no code, I added gluon = "0.16.1" to Cargo.toml of an empty project.

Error output

error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:814 ~ gluon[bf1c]::std_lib[0]::regex[0]::load[0]), const_param_did: None }) (end of phase Optimized) at bb26[20]:            
encountered `Assign` statement with incompatible types:                                                                                                                                                          
left-hand side has type: fn(&std_lib::regex::Regex, &str) -> std::option::Option<vm::api::Collect<impl std::iter::Iterator>>                                                                                     
right-hand side has type: for<'r, 's> fn(&'r std_lib::regex::Regex, &'s str) -> std::option::Option<vm::api::Collect<impl std::iter::Iterator>>                                                                  
  --> /home/jcd/.cargo/registry/src/github.com-1ecc6299db9ec823/gluon-0.16.1/src/std_lib/regex.rs:90:39                                                                                                          
   |                                                                                                                                                                                                             
90 |             captures => primitive!(2, std::regex::prim::captures),                                                                                                                                          
   |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^                                                                                                                                            
   |                                                                                                                                                                                                             
   = note: delayed at src/librustc_mir/transform/validate.rs:140:36                                                                                                                                              
                                                                                                                                                                                                                 
error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:2715 ~ gluon[bf1c]::std_lib[0]::regex[0]::load[0]::wrapper[3]), const_param_did: None }) (end of phase Optimized) at bb0[0]: 
encountered `Assign` statement with incompatible types:                                                                                                                                                          
left-hand side has type: fn(&std_lib::regex::Regex, &str) -> std::option::Option<vm::api::Collect<impl std::iter::Iterator>>                                                                                     
right-hand side has type: for<'r, 's> fn(&'r std_lib::regex::Regex, &'s str) -> std::option::Option<vm::api::Collect<impl std::iter::Iterator>>                                                                  
  --> /home/jcd/.cargo/registry/src/github.com-1ecc6299db9ec823/gluon-0.16.1/src/std_lib/regex.rs:90:39                                                                                                          
   |                                                                                                                                                                                                             
90 |             captures => primitive!(2, std::regex::prim::captures),                                                                                                                                          
   |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |                                                
   = note: delayed at src/librustc_mir/transform/validate.rs:140:36

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.47.0-nightly (6c8927b0c 2020-07-26) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: could not compile `gluon`.

It looks like the bound regions are preventing us from normalizing an opaque type, leading us to conclude that the LHS and RHS types are not actually equal.

@RalfJung

cc @RalfJung

@eddyb

Well I thought our subtyping check would catch such things? Cc @eddyb

It would be great to get a minimal testcase out of this.

I thought something like this could be used to reproduce the problem, but so far I could not get it to ICE:

struct Regex;

fn nested(x: (for<'r, 's> fn(&'r Regex, &'s str), String)) -> (fn(&Regex, &str), String) {
    x
}

fn main() {
    nested((|_x, _y| (), String::new()));
}

@RalfJung

It looks like the bound regions are preventing us from normalizing an opaque type, leading us to conclude that the LHS and RHS types are not actually equal.

@RalfJung You're missing the impl Iterator from the original. Here's a short repro:

fn iter_slice<'a, T>(xs: &'a [T]) -> impl Iterator<Item = &'a T> {
    xs.iter()
}

fn main() {
    iter_slice::<()> as fn(_) -> _;
}

For the record, the thing of note about primitive!(2, std::regex::prim::captures) is that it casts (twice, even, presumably accounting for the two errors), the function to primitive_cast!(2) (which is just fn(_, _) -> _)

The function is gluon's std::regex::prim::captures, with the signature:

fn captures<'a>(
    re: &Regex,
    text: &'a str,
) -> Option<Collect<impl Iterator<Item = Option<Match<'a>>>>>

You're missing the impl Iterator from the original. Here's a short repro:

Nice, a repro! So return-position impl-trait is crucial here. (We don't really need a bisect as we know that this got introduced by checking that MIR assignments are properly typed, so removing that label as well.)

Any proposal for how this could be handled? I don't even understand why it doesn't work, I thought we are deleting all the lifetimes, but clearly not enough of them.^^
Would moving back to a "type fold" (instead of this relator thing we are currently doing) help?

@lcnr

Reopening as the problem remains on beta.

@lcnr can you do a backport?

@RalfJung

@RalfJung #75443 is already beta-nominated, still this can be left open until we do the actual backport.

Oh I thought the beta PR would get nominated?
Clearly I do not know the process. Feel free to close again if that's the process. :)

Hm, when you say "beta PR" -- is there a dedicated PR intended for beta backport? Or is #75443 slated for beta backport? Whichever PR's commits should be cherry-picked onto beta should get nominated.

Oh gosh now I confused everyone.^^
What I thought would happen is that someone cherry-picks #75443 onto the beta branch, opens that PR, and then marks it as nominated for the team to discuss. But best to ignore me as I clearly have no idea how you are doing backports.^^

@RalfJung

@RalfJung the way it works is ... a PR that was made against master is labelled with beta-nominated requesting a backport for beta or stable-nominated requesting a backport for stable. During the following compiler weekly meeting members vote if the request should be accepted or rejected. If it is accepted a label beta-accepted or stable-accepted is added and at that point @Mark-Simulacrum ports that PR to the corresponding beta/stable branch. If it request is declined the beta-nominated or stable-nominated label is removed leaving the backport without effect.

We experienced a minor regression with the fix in PR #75443, but there are known workarounds.

The fix caused new "reached the type-length limit" compiler errors in our project. In our particular case, we didn't need the tracing::instrument spans that were creating the large types, so we deleted them (see ZcashFoundation/zebra#923).

This is a known issue in tracing tokio-rs/tracing#616 - they increase the type-length limit as a workaround.

It's also a known issue in rustc (#54540). I added the bisect-rustc regression report to that issue as #54540 (comment).

The fix seems to have been backported to beta. Can we close this?

What's the link to the beta PR?

Yes I think it can be closed then.

@RalfJung

@RalfJung #75722

Navigation Menu

Repository navigation

Panic when compiling gluon on 1.46 #75313

Code

Meta

Error output

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Panic when compiling gluon on 1.46 #75313

Description

Code

Meta

Error output

Activity

Aaron1011 commented on Aug 9, 2020

jonas-schievink commented on Aug 9, 2020

RalfJung commented on Aug 9, 2020

RalfJung commented on Aug 9, 2020

eddyb commented on Aug 9, 2020

RalfJung commented on Aug 9, 2020

24 remaining items

RalfJung commented on Aug 13, 2020

spastorino commented on Aug 13, 2020

RalfJung commented on Aug 13, 2020

Mark-Simulacrum commented on Aug 13, 2020

RalfJung commented on Aug 13, 2020

spastorino commented on Aug 13, 2020

teor2345 commented on Aug 19, 2020

emilyalbini commented on Aug 21, 2020

RalfJung commented on Aug 21, 2020

emilyalbini commented on Aug 21, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions