gensym each test re-export module individually

[andrew-d]

Fixes #16597

I'm not 100% sure this is the correct way to handle this - but I wasn't able to find a better way without doing way more refactoring of the code that I was comfortable with. Comments and criticism are appreciated 😄

[alexcrichton]

If this just uses a dummy span, it should call bug instead of span_bug. It also looks like some of this module is conditionally executed, so could this bug possibly be triggered on something like an empty file?

[alexcrichton]

Could you add a test for #16597 as well?

[andrew-d]

Added, and an empty test too. The tests pass make check locally.

[alexcrichton]

cc @sfackler, the call to bug looks odd to me, but you may know more about whether it could be triggered or not.

[andrew-d]

I don't think it's possible for the call to bug() to trigger. From what I can see, the path is reached like so:

TestHarnessGenerator::fold_crate
             |
       mk_test_module
             |
          mk_tests
             |
       mk_test_descs
             |
   mk_test_desc_and_fn_rec

And the only way that mk_test_desc_and_fn_rec is called is if there's more than one item in cx.testfns. The only way THAT happens is if the Folder hits the test function here. If that function is hit, then the conditional here can't be false, and we should always hit the assignment.

All that being said: another pair of eyes would be welcome 😆

[andrew-d]

@alexcrichton @sfackler Looks like this error is because the pretty-printer doesn't like gensym'd things? I can fix this by // ignore-pretty in the test, or by switching to another method of generating module names - for example, an AtomicUint and names of the form __test_reexports_1234. Thoughts?

[sfackler]

// ignore-pretty seems reasonable to me. It's something that should really be fixed in the pretty printer itself at some point.

[andrew-d]

@sfackler Done :-) Can I get another r+?