HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dtolnay
cargo-expand
Rust2018–2023
dtolnay / cargo-expand

cargo-expand

Subcommand to show result of macro expansion

4Distinct people
4Mentions
0Explicit recommenders
3.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Subcommand to show result of macro expansion

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2018-11-19 15:08:11 UTC to 2023-12-10 20:27:44 UTC.

012018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

What Hacker News says

4 sources
I apologize. I skimmed your post and the response and fit it into some stereotypes. Your question is actually a lot more interesting than I thought. I couldn't figure it out reading the docs on my phone. When I first tried to reproduce your issue, I got that `try_new` didn't exist. It's been removed in the latest version of lol_html. Replacing it with `new`, your issue didn't reproduce. I was able to reproduce with v0.2.0, though. Since the issue had to do with code generated by macros, I tried `cargo expand` (something you need to install, see [1]). Here's what `let handlers = ...` expanded to in v0.2.0: let handlers = <[_]>::into_vec(box [( &"a[href]".parse::<::lol_html::Selector>().unwrap(), ::lol_html::ElementContentHandlers::default().element(|el| { let href = el.get_attribute("href").unwrap().replace(
Read the rest
"http:", "https:"); el.set_attribute("href", &href).unwrap(); Ok(()) }), )]); and here's what it expands to in v0.3.0 let handlers = <[_]>::into_vec(box [( ::std::borrow::Cow::Owned("a[href]".parse::<::lol_html::Selector>().unwrap()), ::lol_html::ElementContentHandlers::default().element(|el| { let href = el.get_attribute("href").unwrap().replace("http:", "https:"); el.set_attribute("href", &href).unwrap(); Ok(()) }), )]); Ignore the first line, it's how the macro vec! expands. The second line shows the difference in what the versions generate. The first takes a borrow of the result of parse, the second takes a Cow::Owned of it. (Cow stands for copy on write, but it's more generally useful for anything where you want to be generic over either the borrowed or owned version of something.). So the short answer is the macro used to expand to something that wasn't owned, and now it does. As for why it worked without a separate assignment, that's because Rust automatically created a temporary variable for you. > When using a value expression in most place expression contexts, a temporary unnamed memory location is created initialized to that value and the expression evaluates to that location instead, except if promoted to a static https://doc.rust-lang.org/reference/expressions.html#tempora... Initially rust created multiple temporaries for you, all valid for the same-ish scope, the scope of the call to try_new. When you break out the vector to its own assignment the temporary created for element! is only valid for the scope of the vector assignment. I took a look at the git blame[2] for the element! macro in lol_html, and they made the change because someone opened an issue with essentially your problem. So I'd say this is a bug in a leaky abstraction, not an issue with your understanding of rust. [1]: https://github.com/dtolnay/cargo-expand [2]: https://github.com/cloudflare/lol-html/commit/e0eaf6c4234af8...
In Things you can’t do in Rust (and what to do instead)

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.