Migrate to phf, add no-std support

[mkroening]

Closes #7.

This PR is structured as follows:

1. Migrate code generation from generate_table.py to build.rs.

   Before, generate_table.py was called once and the generated code was then committed to the repository.
   Now, build.rs generates the code from assets/code_tables.json on the fly for every user before the compilation. The resulting code is not saved persistently anywhere, and is regenerated after cargo clean.

   This step does not change the generated code or any dependencies.

2. Migrate to phf.

   This change migrates the code generation for hash maps from the manual lazy_static and ahash::AHashMap based code to a phf_codegen and phf::Map based one.

This commit and the following ones are for supporting no-std environments:

3. Enable Rust 2021 to enable Cargo resolver version 2.

   Without this, phf_codegen in build-dependencies enables the std
   feature for phf_shared in the normal dependencies scope as well.

   See https://doc.rust-lang.org/cargo/reference/features.html#feature-resolver-version-2

The next two commits are for refactoring all functionality that requires an allocator into one module for easier gating.

4. Move string functions into string module.

5. Move TableType string methods to string module.

6. Add no_std support.

   This makes all functionality depend on the alloc crate instead of std, making it suitable for no-std environments.
   Additionally, the alloc functionality can be disabled via Cargo features for no-std environments without alloc.

[tats-u]

Are you trying to rewrite generate_table.py in Rust? If the build.rs does just what generate_table.py, I think you should rename build.rs as generate_tables.rs for example. build is too generic.

[mkroening]

Are you trying to rewrite generate_table.py in Rust? If the build.rs does just what generate_table.py, I think you should rename build.rs as generate_tables.rs for example. build is too generic.

build.rs is a Cargo build script. It has to be called build.rs. It's executed before compilation of the source files, and I used it to replace generate_table.py in the first commit, since I deemed it most suitable for migrating to phf in the second commit.

I rebased on latest master and applied your early suggestions. I pushed it commit by commit to have CI runs for each one of them.
I'll also update the description of this PR and mark this as ready for review.

Would you like me to split this PR up or are you okay with keeping it this big?

[mkroening]

If the build.rs does just what generate_table.py, I think you should rename build.rs as generate_tables.rs for example. build is too generic.

I just found, that you can actually use a different name for the build script: package.build. I have never seen another name than build.rs before though, and I would find things easier myself, if we keep the name build.rs for the build script.

It's up to you to decide, though. :)

[tats-u]

I want a doc comment that shows this is parsed content of code_tables.json. This is just an draft.

/// Parsed code tables from `code_tables.json`
struct CodeTables {
    /// ISO 8601 Timestamp when tables in the JSON are created
    created: String,
    //// code tables main part
    ////
    //// `([code page], [table definition])`
    tables: Vec<(u16, Table)>,
}

The name ParsedCodeTablesJsonContent might be better because this is not tables itself and has also a timestamp.

Also could you tell me why you think the Vec of the tuple is better than a map (Map, HashMap, or something similar)?

[mkroening]

I called it CodeTables, because the file is called code_tables.json. I also wanted to avoid a long name.

I chose Vec, because I want the tables to be sorted and stable in the generated output.

[tats-u]

@mkroening Autocompletion by modern editors reduces a pain of typing long names a lot, though.

because I want the tables to be sorted and stable in the generated output.

Why not BTreeMap? Also you want to clarify a sort is needed in a comment.

[mkroening]

I was more concerned about reading, but if you want, I can rename it to ParsedCodeTablesJsonContent.

I chose Vec, because it is faster and simpler if we only sort it once and don't mutate it. BTreeMap would also work fine though and I can migrate to it if you want me to. :)

[tats-u]

@mkroening I'm glad to hear your opinion. You don't have to modify.

I chose Vec, because it is faster

BTreeMap has the same order $O(n \log n)$ as a sort of Vec, but I didn't know the combination of Vec and sort is faster.

[mkroening]

They should scale the same, and BTreeMap makes sure that the collection is kept sorted. Vec provides better cache locality, since its items are stored in a row. So it's about nice access patterns when iterating. For the BTreeMap, we'd jump around in memory a lot.

All of this is super irrelevant for our use case, since this is not at all performance sensitive, and benchmarks might prove me wrong in this case. So my choice was rather arbitrary and mainly out of habit. :)

[tats-u]

@mkroening I see, and you can go ahead (you can stick to build.rs) if you add sufficient comments.

[mkroening]

Sorry for taking so long. I addressed your concerns. :)

[tats-u]

This change is now available in 1.2.0. Sorry to keep you waiting for a long time.

[mkroening]

No worries! Thanks a lot! :)

[tats-u]

Sorry I'd like you to use 2.0.0(-beta.1) instead. I found this patch is a breaking change, contrary to my expectations.