Incorrect Send implementation classification using complicated types

[jdm]

Sorry, not much concrete information here. Servo fails to build in confusing ways with small changes:

• add a new TestMsg(Sender<Sender<((), Receiver<Box<()>>)>>) variant to layout_interface::Msg (http://mxr.mozilla.org/servo/source/components/script/layout_interface.rs)
• add a dummy handler to LayoutTask::handle_script_request (http://mxr.mozilla.org/servo/source/components/layout/layout_task.rs)

Build Servo, get a bunch of errors relating to Send bounds on types, some of which call out layout_interface::Msg in particular.

• modify TestMsg to be the following: TestMsg(Sender<Sender<((), Receiver<()>)>>) (or get rid of the first tuple argument, or get rid of one level of Sender, etc.)

Build Servo again, see that it builds without any problems.

[nikomatsakis]

Sorry for the delayed report. I tracked this down before thanksgiving but forgot to take notes. The problem is that we are hitting the maximum recursion depth counter for the builtin bounds. The simplest fix then is to up this depth -- the whole idea was that the depth would be configurable per crate. However, I'm not sure that it actually is.

I guess I would say there are three problems here:

1. A clearer error report! Overflow is supposed to be clearly detected and "bubble up", but that got lost and it's now being kind of silently lumped into "failed to resolve". Bad.
2. Configurable limits. This should be pretty easy to implement if it doesn't exist already.
3. Recursion for builtin bounds doesn't technically need to increment the recursion counter in many cases; I considered this when implementing, but wasn't sure whether I wanted to take advantage of it, since it would make builtin bounds vary more than other types.

[nikomatsakis]

(I'll prepare a patch for configurable limits and a clearer error report ASAP)

[nikomatsakis]

PR that "fixes" this problem available in #19466

@jdm we may be able to find a workaround in servo for time being

[larsbergstrom]

@jdm Did you find a workaround for this issue? It's still listed in servo/servo#2853

[jdm]

Yep!