Since we might want to add more information than just the crate name, I suggest to produce a json file (or any other structured format), which also yields the attributes given to the extern crate item. This is important for things like macro imports and compiler plugins.

This can be used for the first iteration, since you can now check for #[macro_use] attributes.

Please elaborate in the detailed design why this is so (maybe add a workflow of calls to rustc that uses crates that have macros)

What's unclear about it?

You are just stating that it is essential, not why.

A build system needs a dependency graph to know where to start compiling.

That's what I meant with add a workflow of calls (maybe the motivation would be a better place than the design)

1. rustc -Z parse-only -Z emit-crate-deps $file
2. find dependencies, run this entire process on the dependencies
3. rustc -Z no-analysis -Z emit-crate-deps $file
4. find new dependencies, run this entire process on the new dependencies
5. compile $file by passing the dependencies

make the life easier for readers of your RFC, right now your idea of this process is scattered at random through the RFC

The process is not part of the RFC. If you want to suggest a process, keep it in the comments. I've already done so myself in the first comment.

it can be part of the motivation, so the detailed design can be understood. And you are stating things like

the problem can be mitigated by tracking only the generated statements separately in the build system

and

first round of dependency resolution in the build system.

which are very much statements relating to the process

Every macro that takes an expression can potentially contain extern crate items in the expression (if it contains a block). for example:

println!("foo: {:?}", { extern crate chrono; chrono::UTC::now() } );

Yes, that's what it says in this paragraph.

I would include that in the detailed design, instead of the drawbacks. I don't think your system should be best-effort, but either do this for all possible rust code or not at all

That is impossible as I've explained in this section.

sure it is. The macro expansion -> new dependency game can't be continued forever, even inside rustc + cargo with explicitly stating the dependencies:

// main.rs in blub
#[macro_use]
extern crate blarg;
fn main() {
    let x = blarg!();
}

// lib.rs in blarg
#[macro_export]
macro_rules! blarg {
    () => {{
        #[macro_use] extern crate foo;
        foo!();
    }}
}

// lib.rs in foo
#[macro_export]
macro_rules! foo {
    () => {5}
}

and you get an error while compiling blub:

macro undefined: 'foo!'

1. Macro expansion is, in general, not deterministic so it's impossible to give precise results.

2. You've already given an example where your algorithm fails for different reasons.

Macro expansion is, in general, not deterministic so it's impossible to give precise results.

Well it is deterministic between runs if there are no compiler plugins involved.

You've already given an example where your algorithm fails for different reasons.

I have? Everything that works right now would still work with my algorithm, because rustc cannot handle macros that expand to exter crate items that add new macros.

I have?

Yes, steps 3 and 4 must be run in a loop since macro expansion can reveal new dependencies which can allow more macros to expand which reveal new dependencies etc.

I don't think it's worth discussing a more complicated process that allows the compiler to emit such a file once it encounters the first error at this time. I have no idea how such a process would be implemented but I know that the process I've described can be implemented in about 100 lines of code. And while such simple code cannot solve the 100% case, it can solve the 99% case and allows the other 1% to be handled downstream.

It's also not productive to spend more time writing comments here until those who rule over us have signaled whether they might add this feature (in one form or the other) or not. Like I said, I'm already using this feature in my driver and maintaining 100 loc every two months isn't that much work.

As I showed in my example, rustc doesn't allow macros to add dependencies that add macros, so there's no need to support it in a build system.

This is with the current macro system. Does this still hold with the new one? From what I know, the new macro system will perform macro resolution lazily which would allow macros to add new dependencies.

Buf if you're working under the assumption that it does not, then I don't see the point of your comments since the system suggested in this RFC already supports the 100% case via your algorithm.

The current behavior seems to be considered a bug by some: rust-lang/rust#33936

Why is this detail important?

Ah, nevermind, it is explained below.

Also, macro expansion may remove extern crate statements, naturally. (Since it e.g. applies #[cfg] directives.)