Item ordering

[m-mueller678]

Currently, the linkme macro accepts an usize sort key. Although it is not documented, I assume this controls the ordering of the elements in the final slice. I was planing to use this to guarantee a deterministic ordering of entries between builds by supplying a hash of the item as the sort key. Otherwise, I end up with different orderings between release and debug builds. Unfortunately, the sort key is limited to a maximum of 9999, which is too small to avoid hash collisions.

It would be neat to have more control over the ordering of items.

[BD103]

To add on to this, this feature should at least be documented if it is intended to be used by others.

[MarkusTieger]

Currently, the linkme macro accepts an usize sort key. Although it is not documented, I assume this controls the ordering of the elements in the final slice. I was planing to use this to guarantee a deterministic ordering of entries between builds by supplying a hash of the item as the sort key. Otherwise, I end up with different orderings between release and debug builds. Unfortunately, the sort key is limited to a maximum of 9999, which is too small to avoid hash collisions.

It would be neat to have more control over the ordering of items.

Actually I tried that, if I specify a sort key, it just isn't present in the array.

[oberrich]

I've tried the following on Windows:

#[distributed_slice]
pub static ITEM: [u32];

#[distributed_slice(ITEM, 2)]
static ITEM2: u32 = 2;
#[distributed_slice(ITEM, 1)]
static ITEM1: u32 = 1;

which expands to

#[link_section = ".linkme_ITEM$b0002"]
static ITEM2: u32 = {...};
#[link_section = ".linkme_ITEM$b0001"]
static ITEM1: u32 = {...};

According to Raymond Chen's Old New Thing the linker sorts items into the section according to the fragment on the right of the $ sign. As expected, the items are put into the section in correct order:

As for the limit of 9999, not sure if this is a linker restriction or an artificial limitation.
Which platform did you try it on? Maybe your platform has a different linker behavior.

[oberrich]

Actually there's two unexpected gotchas when using this facility:

• When mixing ordered slice elements with non-ordered ones, the non-ordered ones will always be sorted into the front of the slice.

#[distributed_slice]
pub static ITEM: [u32];

#[distributed_slice(ITEM, 2)] // .linkme_ITEM$b0002
static ITEM2: u32 = 2;
#[distributed_slice(ITEM, 1)] // .linkme_ITEM$b0001
static ITEM1: u32 = 1;
#[distributed_slice(ITEM)] // .linkme_ITEM$b
static ITEM3: u32 = 3;

fn main() {
    println!("{:?}", ITEM.iter());
}

yields Iter([3, 1, 2]) as opposed to Iter([1, 2, 3]) since .linkme_ITEM$b is lexicographically smaller than .linkme_ITEM$b0001.

• Reusing the same order for a slice element, will introduce an unordered sub-slice within said order.

#[distributed_slice(ITEM, 1)]
static ITEM1: u32 = 1;
#[distributed_slice(ITEM, 2)]
static ITEM2: u32 = 2;
#[distributed_slice(ITEM, 2)]
static ITEM3: u32 = 3;
#[distributed_slice(ITEM, 4)]
static ITEM4: u32 = 4;

yields Iter([1, 3, 2, 4]) while

#[distributed_slice(ITEM, 1)]
static ITEM1: u32 = 1;
#[distributed_slice(ITEM, 2)]
static ITEM3: u32 = 3;
#[distributed_slice(ITEM, 2)]
static ITEM2: u32 = 2;
#[distributed_slice(ITEM, 4)]
static ITEM4: u32 = 4;

yields Iter([1, 2, 3, 4]).