Consider throwing away `infer_schema`

[nox]

There is no way rustc ever expected code to make database connections at compile-time. Why not just make an auxiliary tool that outputs Rust code that can then be included in the project? Why put such a heavy thing (database connections) at compile-time?

This means that we will never be able to enforce using miri or stuff like that to run proc macros.

[Eijebong]

It's already included in diesel print-schema.

Even when ignoring the technical details of that implementation, I think that infer_schema! is really confusing for people as we often have some questions about code not compiling because the database used for the compilation is wrong or migrations haven't been run yet.

[sgrif]

We recommend using diesel print-schema in the long run, but infer_schema! is still a very useful tool for prototyping when the schema file churns a lot.

[nox]

How is it more useful than using the print command? The more projects do fancy things at compile-time, the less freedom the Rust team will have to improve compile times, AFAICT.

[killercup]

I see your reasoning and I too want faster compile times, but I don't think this is something that's easy to fix. I'd really like to know what you have in mind :)

How is it more useful than using the print command?

More useful? Hard to say. More convenient? Yes: It literally is one less thing you need to do. You will never forget to run diesel print-schema > src/schema.rs after changing your DB.

There is no way rustc ever expected code to make database connections at compile-time.

That's a very weird argument. Proc macros and build scripts can do whatever they want. They are not required to be run in a sandbox and are written in a Turing complete language.

The more projects do fancy things at compile-time, the less freedom the Rust team will have to improve compile times, AFAICT.

What optimizations are we talking about?

• Memoization and caching for incremental compilation? Is there a way for you to detect proc macros to be pure, .e.g. by trying to run it with miri or something like that? If so, what stops you from falling back to the way things are currently done when that fails? Or requiring proc-macros to set a "pure" flag? (Funnily enough, as this is Diesel's repo, I can't help but think of how in Postgres you need to annotate functions with VOLATILE, STABLE, or IMMUTABLE.)
• Skip potentially costly LLVM-based compilation by interpreting the code in miri? Not sure how fast miri is. That may be an interesting tradeoff.

[nox]

My point was that we can't experiment with using MIRI for procedural macros if procedural macros do I/O and connect to databases and whatnot.

I've personally never expected people to do things like that, even though Rust is a Turing-complete language and used to implement them proc macros.

[sgrif]

The more projects do fancy things at compile-time, the less freedom the Rust team will have to improve compile times, AFAICT.

Given that proc macros are capable of running any arbitrary code, the Rust team will always need to assume that proc macros do anything, including network or Disk IO. Whether our project takes advantage of those capabilities is irrelevant.

I've personally never expected people to do things like that

Perhaps seeing these use cases in the wild will change your expectations. You may also be interested in embed_migrations!, which would also prevent things like using MIRI for proc macros.

[nox]

Given that proc macros are capable of running any arbitrary code, the Rust team will always need to assume that proc macros do anything, including network or Disk IO. Whether our project takes advantage of those capabilities is irrelevant.

That's because MIRI wasn't a thing when proc macros landed. If no one uses them in such dubious ways, the Rust team will be able to easily switch their evaluation to MIRI. If popular projects start relying on this behaviour, they won't be able to.

To me your justification of your usage of proc macros sound like people wanting Rust to enforce a specific order in HashMap to be able to rely on it.

Perhaps seeing these use cases in the wild will change your expectations. You may also be interested in embed_migrations!, which would also prevent things like using MIRI for proc macros.

No, I'll keep trying to make those disappear, because that's not where that code should run in the first place. I'll stop pursuing that objective here, though.

[sgrif]

If no one uses them in such dubious ways

Again, claiming that our project has any impact on that is ridiculous. It is impossible to know if anyone is using Rust in a certain way. You can say for sure that someone is using something, but unless you have access to everybody's closed source repositories, it is impossible to say that someone isn't using something.

that's not where that code should run in the first place

Frankly, I'm not sure what gives you the right to decide where other people's code should or shouldn't be run

[nox]

Again, claiming that our project has any impact on that is ridiculous. It is impossible to know if anyone is using Rust in a certain way. You can say for sure that someone is using something, but unless you have access to everybody's closed source repositories, it is impossible to say that someone isn't using something.

In general, Rust has never been quite afraid of changing behaviour after the fact if a Crater run ends up green.

Frankly, I'm not sure what gives you the right to say where other people's code should or shouldn't be run

Oops, I'm sorry I meant to add "in my book" after that and removed it after I rephrased the sentence. :(

[killercup]

Enforcing proc macros to not have side effects and not use external resources reduces their usefulness quite a bit. I'd personally be very disappointed if this limitation was introduced. Not that I think there is any way to introduce it—crater or no crater, this is a huge change of a stable feature! But wait: What is *actually* stopping us from experimenting with miri here? I've not dived deep into how miri does its thing, but I imagine that there is a way for it to give up, at which point you could fall back to the current way of executing them. Is this not possible? Is this in combination with a "this macro is pure" opt-in flag not sufficient?

…

Am 23.12.2017 um 16:00 schrieb Anthony Ramine ***@***.***>: My point was that we can't experiment with using MIRI for procedural macros if procedural macros do I/O and connect to databases and whatnot. I've personally never expected people to do things like that, even though Rust is a Turing-complete language and used to implement them proc macros. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.