proc-macro-workshop: builder-9

// Does your macro still work if some of the standard library prelude item names
// mean something different in the caller's code?
//
// It may seem unreasonable to consider this case, but it does arise in
// practice. Most commonly for Result, where crates sometimes use a Result type
// alias with a single type parameter which assumes their crate's error type.
// Such a type alias would break macro-generated code that expects Result to
// have two type parameters. As another example, Hyper 0.10 used to define
// hyper::Ok as a re-export of hyper::status::StatusCode::Ok which is totally
// different from Result::Ok. This caused problems in code doing `use hyper::*`
// together with macro-generated code referring to Ok.
//
// Generally all macros (procedural as well as macro_rules) designed to be used
// by other people should refer to every single thing in their expanded code
// through an absolute path, such as std::result::Result.

use derive_builder::Builder;

type Option = ();
type Some = ();
type None = ();
type Result = ();
type Box = ();

#[derive(Builder)]
pub struct Command {
    executable: String,
}

fn main() {}

從程式碼結構上來看，我們就已經能夠猜到大致的考點

namespace

因為宏可能使用在任何地方，如果指定含義不明，那麼命名就會衝突。

這裡無需對程式碼做任何的改動，因為我們在書寫程式碼的時候始終嚴格使用絕對路徑。
因此這道題考點對我們毫無影響

這個在這裡就無需重複貼上了。

這裡之所以還提示一下，一方面是為了強調一下知識點；另一方面，就是正式的對builder做一個完整的結束宣告。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

proc-macro-workshop: builder-9

相關文章