Update working-groups/rls-2.0/NOTES.md

Co-Authored-By: matklad <aleksey.kladov@gmail.com>

Author: Xanewok

working-groups/rls-2.0/NOTES.md

@@ -64,7 +64,7 @@ In short, we decided to primarily work towards an end-to-end effort, which aims
 
 [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/MBE.20discussion)
 
-We've discussed current state and next steps for macro handling in rust-analyzer. One conclusion was that we are not going to shoot directly at librarifing macro expansion code and sharing it with rustc: we already have chalk and name resolution in-flight. Instead, the focus is explicitly on supporting the most common cases, so that we can check hypothesis that incremental IDE-style macro expansion is feasible.
+We've discussed current state and next steps for macro handling in rust-analyzer. One conclusion was that we are not going to shoot directly at librarifying macro expansion code and sharing it with rustc: we already have chalk and name resolution in-flight. Instead, the focus is explicitly on supporting the most common cases, so that we can check hypothesis that incremental IDE-style macro expansion is feasible.
 
 We also try to produce a "clean" interface for macro expansion, even if it means not handling all complexities of existing macro system. Specifically, both mbe and proc macros will use `TokenTree` abstract data type, modeled after `proc_macro2::TokenTree` for both input and output. In `TokenTree`, tokens have identities (u32 ids) and additional information about spans and hygiene is stored in side-tables keyed by these identities.