proc-caesar

一个用于对Rust源代码应用凯撒密码的过程宏。

示例

caesar! {

sa pnrfne_qrpbqr(f: &fge) -> Fgevat {
    erghea f.punef().znc(qrpbqr_pune).pbyyrpg();

    sa qrpbqr_pune(p: pune) -> pune {
        zngpu p {
            'a'...'z' => ebg(p, 'a'),
            'A'...'Z' => ebg(p, 'A'),
            _ => p,
        }
    }

    sa ebg(p: pune, onfr: pune) -> pune {
        fgq::pune::sebz_h32(((p nf h32 - onfr nf h32) + 13) % 26 + onfr nf h32).hajenc()
    }
}

}

#[test]
fn decoding_works() {
    assert_eq!(
        &caesar_decode("Ornhgvshy vf orggre guna htyl."),
        "Beautiful is better than ugly."
    )
}

为什么？

为了破坏代码补全。说真的，这个crate存在的唯一原因就是为了破坏IDE中的代码补全。

更具体地说，这是一个简单的示例，表明在宏调用内部提供IDE功能在一般情况下是不可能的。

考虑以下代码片段

use std::collections::HashMap;

lazy_static! {
    static ref HASHMAP: HashMap<u32, &'static str> = {
        let mut m = HashMap::new();
        m.insert(0, "foo");
        m.insert(1, "bar");
        m.insert(2, "baz");
        m
    };
}

fn main() {
    let entry = HASHMAP.get(&0).unwrap();
    println!("The entry for `0` is \"{}\".", entry);
}

"宏的IDE支持"这里有两层含义

• 在 main 内，IDE应该补全 HASHMAP
• 在 lazy_static! 内，IDE应该补全 HashMap

第一种情况是“容易的”：IDE需要“只是”展开宏并像往常一样处理产生的代码。

第二种情况，正如proc-caesar宏所证明的，在一般情况下是无法处理的：感叹号后的标记与展开代码之间的连接可能非常复杂。为了为 caesar! 宏内的代码提供正确的补全，IDE必须找出标识符的逆变换！

未来工作

目前这个crate使用的是一个特别弱的密码，所以一个足够聪明的AI驱动的IDE在理论上可以找出补全所需的逆变换。为了使这个宏对AI免疫，我们需要应用公钥密码学，以确保计算逆变换在计算上是不可行的。