Skip to content

Possible bug in trait bounds evaluation #30262

@fizyk20

Description

@fizyk20

I'm encountering infinite recursion in trait bounds evaluation while trying to compile the following code: https://gist.github.com/anonymous/409eb6a2da7fdceafc45 (unfortunately, I haven't been able to compress it more, since I have no idea what exactly is the combination of factors that triggers the error).

The error and backtrace: https://gist.github.com/fizyk20/a4f644c920f00177d52e

Increasing the recursion limit doesn't help, hence my description of the issue as an infinite recursion.

There are a few aspects of the issue that puzzle me:

  • commenting either this line or this impl causes the error to disappear. The line multiplies Tensor by a f32, the impl regards Tensor * Tensor.
  • This impl causes the same problem, but switching impl<T, U> Mul<Tensor<T, U>> for Vector<T> to impl<T, U> Mul<Vector<T>> for Tensor<T, U> causes the problem to go away (with no changes to the bounds).

I'm aware that the code is long and I haven't provided much information - that's mostly because I have no idea where else to look for any clues. If there is something I can do to make this issue easier to analyze, please tell me and I'll do it.

I'll also mention that I have build the debug version of rustc 1.4.0 to check the debug logs, but I have no idea what to look for. If something from the debug logs is needed, I can also generate it (provided I know what to generate).

If this is not a bug, but just me doing something stupid, I'd also love to hear what I'm doing wrong.

I'd greatly appreciate any help or hint on how to debug this issue further :)

Update: I have just found that changing

let result: Vector<Test2> = vector1 * 5.0;

to

let result: Vector<Test2> = <Vector<Test2> as Mul<f64>>::mul(vector1, 5.0);

makes the code work. The same can be done to get multiplying vectors to work (click). I hope this will help.

Update 2: This doesn't work, either:

let result: Vector<Test2> = Vector::<Test2>::mul(vector1, 5.0);

This leads me to believe that something goes wrong when the compiler tries to choose the appropriate Mul implementation. Somehow this causes it to evaluate bounds for types it was never supposed to choose and overflow. I'm still not sure if this is a bug, but maybe there is a way to improve the algorithm :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-trait-systemArea: Trait systemC-bugCategory: This is a bug.P-lowLow priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions