[MIR] constant evaluation

[yigal100]

ok, I see now what you are talking about. In that case, the formulation is simply incorrect. inside a macro a let size = size_of::<T>() refer’s to the macro’s (i.e compiler’s HOST) type T. that means the macro generates code based on the macro’s environment. What you really want is the type T of the compiler’s TARGET. Therefore it needs to be an input to the macro.

Than you’d use it as let size = quote!(size_of::<$T>()) Does that answer your concerns?

edit: typo

[arielb1]

So you basically want a syntax extension that is JIT-ted from the source code?

The problem with syntax extensions is that they run on the host, and therefore they can’t easily access target things - including target types.

[eddyb]

But can the macro be triggered with an input from a generic?
That is, does your plan involve invoking magic! for every T an impl<T> Trait<magic!(T)> for T is used with?

[matthieum]

Ah! I see what you mean.

I actually envisaged the following scenario:

const MY_CONSTANT: &'static str = {
    const BUFFER: String = some_const_fn();
    &BUFFER[..]
};

which I would expect to work, and not require leaking.

I had not thought about leaking; while working I am afraid that this would further differentiate the fn and const fn realms: it would make the const fn less likely to be useful at runtime.

[eddyb]

That’s the same as:

const fn my_constant() -> &'static str {
    &some_const_fn()[..]
}

Which is a lifetime error, because you’re returning a reference to a stack value.

Maybe we could special-case const contexts to perform the leaking/“interning”, but again, you need to find a good rule for it (in this case, at the type-level).

EDIT: I was wrong, in this case the String would indeed be 'static, and its data not accessible except though a shared reference, so the whole Box::leak deduplication mechanism would work just as well here.

[eddyb]

I actually envisaged the following scenario:

const MY_CONSTANT: &'static str = {

    const BUFFER: String = some_const_fn();

    &BUFFER[..]

};

which I would expect to work, and not require leaking.

For what it’s worth, this would work just as well:

const MY_CONSTANT: &'static str = &some_const_fn();

[matthieum]

For what it’s worth, this would work just as well:

const MY_CONSTANT: &'static str = &some_const_fn();

That would be even much sweeter, indeed. I suppose this relies on the fact that rustc materializes temporaries in anonymous variables.

[eddyb]

Indeed, it would work the same way this does:

const FIVE: &'static i32 = &5;

What’s worrying is this:

const MY_CONSTANT: &'static String = &some_const_fn();

This can either be banned (on the premises of reaching a “dynamically allocated” memory region from a const, without a &str “chokepoint”), or allowed… but if it is allowed, should each mention of MY_CONSTANT leak a Box<String>?

If it’s deduplicated, you end up with life-before-main, which we also don’t want, although it’s not arbitrary code, only an allocation with constant bytes put into it.

[matthieum]

const MY_CONSTANT: &'static String = &some_const_fn();

This can either be banned (on the premises of reaching a “dynamically allocated” memory region from a const, without a &str “chokepoint”), or allowed… but if it is allowed, should each mention of MY_CONSTANT leak a Box<String>?

Why would mentioning MY_CONSTANT cause a leak?

I would expect the compiler to instantiate a unnamed variable of type 'static String for the result of some_const_fn, like it would do in a function scope, and then create a reference to it.

Is the plan to re-compute MY_CONSTANT each and every time it is mentioned?

I had thought that each constant would be evaluated once (and only once) and the evaluation cached in the MIR somehow, and thus it would only be codegen’d once too.

[eddyb]

But where do you codegen the runtime String allocation? This doesn’t have a trivial answer.

EDIT: Oh, since the destructor never runs, you may be able to have String point to a static allocation anyway.
I have not considered that outcome until now.

EDIT2: I’ve updated the original post with more details on dynamic allocations, given the fruitful discussion.
Thank you, everyone!

[matthieum]

EDIT: Oh, since the destructor never runs, you may be able to have String point to a static allocation anyway. I have not considered that outcome until now.

Oh sorry! It seemed the obvious strategy to me since the beginning (cannot allocate before main anyway) so I am afraid I never spelled it out

As you mention in your revised post, there seems be a division between what you evaluate (any const fn) and what you can store in a const item: UnsafeCell and the like¹. While an Arc could be used within the evaluation code, it cannot be stored in .rodata. This seems to mean that some types could be const and others not.

I do disagree slightly with the static BAD: Arc<Mutex<String>> = Arc::new(Mutex::new(String::from("foo")));, I think it should be okay if we let the static or const keyword determine the context of the memory allocations, and thus where they occur. In the case of static it would be in the .data segment, in the case of const in the .rodata segment.

As you mention though, there is at least one hitch: these memory areas are not handled by the memory allocator, and therefore attempting to query them through it is impossible. Unfortunately, instrumenting the call to behave differently when pointing inside .data or .rodata would introduce some overhead on all calls. This issue seems specific to static data though (could @Manishearth confirm?), so maybe just keeping using lazy_static! for such data is fine for now (I don’t personally have any strong urge to make global variables any cheaper or more ergonomic to use anyway).

¹ Determining the exact extent of “and the like” is left as an exercise to the poor implementer

[eddyb]

BAD was specifically bad because you had a mutable String initially pointing at non-runtime memory, the Arc is fine (hence the example with String::new() which does not point to anything).

That said, static support for “compile-time dynamic allocations” is entirely optional and will probably remain feature-gated for more time than the rest.

[Manishearth]

Unfortunately, instrumenting the call to behave differently when pointing inside .data or .rodata would introduce some overhead on all calls. This issue seems specific to static data though (could @Manishearth confirm?)

Probably yeah? We only use this for memory reporting so perf is not a major concern.

[matthieum]

What I am afraid of is introducing a performance overhead on all calls just so the allocator hooks work even for “compile-time dynamic allocations”. As @eddyb said though, for now this seems difficult to pull off so maybe we can just punt on it.

[eddyb]

FWIW, I never considered allocator hooks for preventing issues with CTFE “allocations” as an option, although the checks could be integrated into a complex allocator somehow.

[yigal100]

FYI - a few papers that explain the model I was advocating above.

1. http://www.cs.rice.edu/~taha/publications/journal/dspg04a.pdf
2. http://www.cs.rice.edu/~taha/publications/journal/tcs00.pdf

[arielb1]

Rust has a few issues with that model:

• host vs. target: ML has no notion of a host vs. target, Rust has.
• dynamic allocation: as you can understand from what me and eddyb were talking about, allocating free-able memory at compile-time is nontrivial. This is not an issue in “dynamically-loaded” languages like ML.
• trait-system: ML has no trait system, which creates implicit between-stage dependencies.

Basically, Rust compilation has 3 stages:

• all types are computed. constants may also be computed, but their memory placement is not
• all statics and constants are computed along with their memory placement
• run-time

[yigal100]

• host vs. target: ML has no notion of a host vs. target, Rust has.

True. Note though that this is just one example of implementing this model. I thought that a formal academic paper will be able to explain better than me. A more modern example to look at would be Nemerle.

Regarding cross-compilation, it indeed adds a complication. It means that ~.<libc::tm>. != libc::tm (hopefully I used the operators in the paper correctly). This means that if I evaluate the deferred expression libs::tm on a different target machine, it doesn’t have to be identical to libc::tm on the host machine. The responsibility to account for this is on the user but I do not believe it matters to the vast majority of code people put in macros.

• dynamic allocation: as you can understand from what me and eddyb were talking about, allocating free-able memory at compile-time is nontrivial. This is not an issue in “dynamically-loaded” languages like ML.

I agree with this as well. This is why I suggest to employ the Nemerle model - each stage is compiled separately. This does not allow an allocation to cross between stages or in other words, do not change the status quo we already have today in Rust.

Doing it manually requires the user to do the following actions:

1. Compile a macro definition into a shared object
2. Compile source code into executable by specifying the macro.dll as a plugin to the compiler.

I don’t see any benefit of supporting compile-time allocations as discussed other than the fact it will be more convenient to use a const Vec<T> over const [T; n] which indicates that we need to improve ergonomics for the latter instead of adding non-trivial support for the former.

• trait-system: ML has no trait system, which creates implicit between-stage dependencies.

Basically, Rust compilation has 3 stages:

• all types are computed. constants may also be computed, but their memory placement is not
• all statics and constants are computed along with their memory placement
• run-time

well, there’s another stage before the above - macro expansion.

[arielb1]

First, rustc const-eval (the original topic of this thread) explicitly runs on a virtual version of the target. That’s why it is nice to use - on an abstract level, it doesn’t matter when it is executed.

Host code mixed with target code is at the very least a severe portability hazard - not only libc::tm, but even usize can vary between the host and target. Similarly, code running on the host will see the libraries on the host - which are of course different from the ones on the target. One of the reasons syntax extensions are ugly is because they must work with this distinction.

Compile-time allocations are useful for creating data structures at compile time whose size is calculated dynamically - imagine having to guess the final size of a hash table.

well, there’s another stage before the above - macro expansion.

macro expansion is a second-class citizen. Macros can’t depend on types and for a good reason.

[yigal100]

Host code mixed with target code is at the very least a severe portability hazard

This claim is repeatedly given without any substantiation. What is a real-life use-case were this theoretical problem (which I agree exists!) hampers or complicates the code? Where does this affect a user in practice? What is the use case were there is need to use platform specific code at compile-time?

Compile-time allocations are useful for creating data structures at compile time whose size is calculated dynamically - imagine having to guess the final size of a hash table.

Again, same question as above, what is a real-life use-case for such compile-time data structures?

I’d argue that if we’re trying to optimize even the allocation itself of the DS by moving it to compile-time (storing the data in the program’s memory), than why not optimize away the DS itself as well? After all, we already have complete knowledge ahead of time of the DS. Instead of allocating a hash-table, generate a static array [T; n] and replace access to such a hash-table with direct access to said array.

macro expansion is a second-class citizen. Macros can’t depend on types and for a good reason.

macro expansion should not be IMO a second-class citizen. While I understand the complexity of allowing macros to depend on type-info I don’t think it is good reason enough to cripple macros so much. Plenty of real-life uses for this are demonstrated in other languages.