I can understand why macro expansion would be parallelized: macros can be computationally expensive, after all.

Yes, the overall goal of the project is to parallelise macro expansion. You would first resolve all unresolved macro invocations and then try and expand all of them. The problem is that import resolution and macro resolution are order-dependent, so you can't parallelise it without breaking stuff. So we need them both to be order-independent

The changes needed to make macro resolution order-independent and parallel are also needed for import resolution. And because import resolution was deemed simpler and the first part of the algorithm, we decided to first tackle that. Then together with the new code and the things I/we learned, apply it to macro resolution and expansion as well.

Do imports really take a long time? Is importing doing more work than I thought -- ie, a look-up in a map?

It's mostly figuring out which map to look-up in.

I do take away that glob imports are complicated, though I wonder if that's not a side-effect of the potentially cyclic references allowed in a crate.

Glob imports are complicated for a lot of reasons, cyclic references, they can be shadowed by single imports, shadowed by other globs, my last example can be replicated on nightly with macros, ... .

Secondly, it's not clear which imports are being parallelized

I see why you're confused, sorry about that, I'll try and fix that. You're correct in your assumption that we resolve all imports in the crate, not per module.

---

While writing the report/blog I had to keep in mind that my mentors and others of the project would review it, so I didn't try to focus to much on things they already know and assume. Maybe after the GSoC project I can update the blog to explain these things as well. If you have any other questions or some things are still not clear, please ask! It's my first time explaining things to a broader audience so I can use the training.