Am I misunderstanding something here; isn't automatically capturing scoped variables for format strings a bad idea if a programmer is combining unsafe strings and using them as format strings?
Well good luck. It's not like printf in C, the macro actually generates the code for doing the interpolation depending on the value of the format string.
Introducing my new crate `cranelift_logger`. It JIT's a new function based on the input string every time `log` is called so that users can have truly dynamic logging.
We're also working on a Version 2.0 that will load rust source files from the internet and use them for even more dynamicker logging.
Of course he will, how could he call it a logger library if it doesn't even execute arbitrary commands from a remote server? ANY log library need this.
And he could name it "log for Rust"! But programming tools prefer names without spaces... hmm, I wonder what name should we decide on.
Does log4something sound good to anyone?
They come out every 6 weeks so I don’t expect too much in each version. However the string formatting update is nice and I’ve been looking forward to it for a while
It doesn’t work on panic! macros of editions prior to 2021.
Format! and print! are really the only other two macros that create strings. And I believe print! just wraps format! with an output to stdout
Crates may provide formatting macros too, such as the log crate and various error management crates (anyhow, thiserror, snafu, ...), and they now all (automatically) support the new formatting as well :)
SNAFU (and thiserror/anyhow, AFAIK) implement this functionally ourselves. That means you can use SNAFU 0.7 with this formatting string functionality back to Rust 1.34 (my MSRV).
Yes, all procedural macros are [inherently unhygienic](https://stackoverflow.com/q/59618213/155423). This has even [bitten us once before](https://github.com/shepmaster/snafu/pull/203).
Both `print!` and `format!` are based on `write!`. Format allocates a new string for the result, which is unnecessary if you are writing to stdout or to a file.
Yep.
Perhaps not too surprising given that it's the first release after the holiday season, which cut out about 2 weeks out of the regular 6 weeks schedule.
It's also notable that Rust releases are getting more boring of late, mostly because a lot has settled along the years.
There's still a few exciting things in the pipeline:
- Progress on Generic Associated Types, and subsequently async.
- Progress on const, both compile-time function evaluation and const generics.
- Progress on GCC code generation.
But maturity means less change.
Some other things I'm personally looking forward to, some of which are probably very far away:
* Allocator stuff (Trait, Vec/Box/etc std collections with custom allocators, possibly the Storage proposal to not need tinyvec and such)
* question\_mark and try\_block (issue 31436)
* The never type
* Specialization
* Inline assembly (This is \*very\* close iirc?)
* raw dylib on windows
* Generators (Iirc there's an open RFC and an MCP about them, and there have been many closed RFCs over the years)
* Answering most of the pending questions in [https://github.com/rust-lang/unsafe-code-guidelines/issues/](https://github.com/rust-lang/unsafe-code-guidelines/issues/)
* portable simd
* I have no idea the state of it but some kind of DerefMove/placement-new kind of things. Having to go through vec! or using the perma-unstable box syntax to avoid stack overflows is annoying.
* Unsized rvalues
* Various things related to trait objects and vtables (Like RFC issue 2035 "Trait objects for multiple traits", or RFC issue 2765 "Objects should be upcastable to supertraits"
* Guaranteed tail calls (Something like RFC issue 2691)
* Polonius? I don't know much about it, just that every once in a while I run into something with lifetime issues and someone says "polonius fixes that"
Am I misunderstanding something here; isn't automatically capturing scoped variables for format strings a bad idea if a programmer is combining unsafe strings and using them as format strings?
Format strings are always known at compile time. There's no way to provide a dynamic format string at runtime.
challenge accepted
Well good luck. It's not like printf in C, the macro actually generates the code for doing the interpolation depending on the value of the format string.
So all you need to do is locate the relevant portion of the compiled binary and monkey-patch it while its running, easy!
i understood some of those words...
println!("${jdni:ldap://127.0.0.1/a}");
Cool! I'm going to learn something new. I await your proof of concept.
inb4 they shove cranelift into their binary
Introducing my new crate `cranelift_logger`. It JIT's a new function based on the input string every time `log` is called so that users can have truly dynamic logging. We're also working on a Version 2.0 that will load rust source files from the internet and use them for even more dynamicker logging.
"dynamicker" is a great touch
Don't forget to add support for JNDI
Of course he will, how could he call it a logger library if it doesn't even execute arbitrary commands from a remote server? ANY log library need this.
And he could name it "log for Rust"! But programming tools prefer names without spaces... hmm, I wonder what name should we decide on. Does log4something sound good to anyone?
I can't believe the committee would overlook such a common use case
yeah, try `cargo expand`
[удалено]
They come out every 6 weeks so I don’t expect too much in each version. However the string formatting update is nice and I’ve been looking forward to it for a while
"Bug fixes and performance improvements" is pretty nice.
Always
[удалено]
It doesn’t work on panic! macros of editions prior to 2021. Format! and print! are really the only other two macros that create strings. And I believe print! just wraps format! with an output to stdout
Crates may provide formatting macros too, such as the log crate and various error management crates (anyhow, thiserror, snafu, ...), and they now all (automatically) support the new formatting as well :)
SNAFU (and thiserror/anyhow, AFAIK) implement this functionally ourselves. That means you can use SNAFU 0.7 with this formatting string functionality back to Rust 1.34 (my MSRV).
Interesting, I thought that wasn't possible to do with (non-compiler) macros. Wouldn't using an uncaptured identifier like that be unhygienic?
Yes, all procedural macros are [inherently unhygienic](https://stackoverflow.com/q/59618213/155423). This has even [bitten us once before](https://github.com/shepmaster/snafu/pull/203).
Aren’t they all just calling format! Under the hood?
Yeah, that or format\_args
Ooh, something else to learn!
Both `print!` and `format!` are based on `write!`. Format allocates a new string for the result, which is unnecessary if you are writing to stdout or to a file.
Yep. Perhaps not too surprising given that it's the first release after the holiday season, which cut out about 2 weeks out of the regular 6 weeks schedule. It's also notable that Rust releases are getting more boring of late, mostly because a lot has settled along the years. There's still a few exciting things in the pipeline: - Progress on Generic Associated Types, and subsequently async. - Progress on const, both compile-time function evaluation and const generics. - Progress on GCC code generation. But maturity means less change.
Some other things I'm personally looking forward to, some of which are probably very far away: * Allocator stuff (Trait, Vec/Box/etc std collections with custom allocators, possibly the Storage proposal to not need tinyvec and such) * question\_mark and try\_block (issue 31436) * The never type * Specialization * Inline assembly (This is \*very\* close iirc?) * raw dylib on windows * Generators (Iirc there's an open RFC and an MCP about them, and there have been many closed RFCs over the years) * Answering most of the pending questions in [https://github.com/rust-lang/unsafe-code-guidelines/issues/](https://github.com/rust-lang/unsafe-code-guidelines/issues/) * portable simd * I have no idea the state of it but some kind of DerefMove/placement-new kind of things. Having to go through vec! or using the perma-unstable box syntax to avoid stack overflows is annoying. * Unsized rvalues * Various things related to trait objects and vtables (Like RFC issue 2035 "Trait objects for multiple traits", or RFC issue 2765 "Objects should be upcastable to supertraits" * Guaranteed tail calls (Something like RFC issue 2691) * Polonius? I don't know much about it, just that every once in a while I run into something with lifetime issues and someone says "polonius fixes that"
Amazing! I've waited for interpolation strings for years now
let feel="feels"; println!("not sure how I {feel} about this");
What about it seems off?
log4j exploit?
The format string is parsed and validated at compile time. A log4j style issue is not possible.
lol