Skip to content

"typed" pretty printing mode fails with "unresolved name" for macros with variables #691

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
msullivan opened this issue Jul 14, 2011 · 0 comments

Comments

@msullivan
Copy link
Contributor

For example, in

fn main() {
  #macro([#mylambda(x,body), {fn f(int x) -> int { ret body }; f}]);
  assert(#mylambda(y,y*2)(8) == 16);
}

It will produce "unresolved name" errors for x, body, and y.
I'm not really sure if there is a good way to fix this. Typechecking depends on macro expansion but pretty printing after macro expansion is quite different from pretty printing before it...

@ghost ghost assigned paulstansifer Jul 14, 2011
pdietl pushed a commit to pdietl/rust that referenced this issue Apr 23, 2020
Add macros in extern blocks and new proc-macro support.
bors pushed a commit to rust-lang-ci/rust that referenced this issue Oct 26, 2020
Eg when the local is immutable **and** the type is freeze.

This makes the simple raytracer runtime benchmark 1% faster than cg_llvm
without optimizations. Before it was 2% slower.

cc rust-lang#691
cc rust-lang#684
bjorn3 added a commit to bjorn3/rust that referenced this issue Aug 6, 2021
In case of PassMode::Indirect, the ownership of the backing storage is
transfered to the callee. This means that the caller must copy the
argument if it wants to use it again later.

Fixes rust-lang#691
ZuseZ4 added a commit to EnzymeAD/rust that referenced this issue Mar 7, 2023
tgross35 added a commit to tgross35/rust that referenced this issue Jun 3, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants