17 Apr 2025

feedPlanet Mozilla

Chris H-C: Perfect is the Enemy of Good Enough

My Papa, my mother's father, C. J. Mortimer died in Saint John, New Brunswick in 2020. Flying through the Toronto and Montreal airports in September to his funeral was one of the surreal experiences of my life, with misting tunnels of aerosolized alcohol to kill any microbe on your skin, hair, clothes, and luggage; airport terminals with more rodent traps than people; and a hypersensitivity to everyone's cough and sniffle that I haven't been able to shake.

I was angry, then. I'm still angry. Angry that I couldn't hug my grandmother. Angry that weeping itself was complicated and contagious. Angry that I couldn't be together or near or held. Angry that I was putting my family at home at risk by even going. Angry that we didn't hold the line on the lockdowns long enough to manage the disease properly. Angry at the whiners.

This isn't a pandemic post, though. Well, no more than any post I've made since 2020. No more than any post I will make for the foreseeable.

This is a post about what my grandfather gave to me.

Y'see, I'm not the first computer nerd in the family. My Grampy, my father's father, was and my father is a computer nerd. Grampy's memoirs were typed into a Commodore 64. Dad is still fighting with Enterprise Java, of all things, to help his medical practice run smoothly.

And Papa? In the 60s he was offered lucrative computer positions at Irving Oil in Saint John and IBM in the US. Getting employment in the tech industry was different in those days, not leastwise because the tech industry didn't really exist yet. You didn't get jobs because you studied it in school, because there weren't classes in it. You didn't get jobs because of your experience in the field, because the most experienced you could be was the handful of years they'd been at it. You didn't get jobs because of your knowledge of a programming language, because there were so few of them and they were all so new (and proprietary).

So what was a giant like International Business Machines to do? How could it identify in far-flung, blue-collar Atlantic Canada a candidate computer programmer? Because though the tech industry didn't exist in a way we'd necessarily recognize, it was already hungrier for men to work in it than the local markets could supply.

In my Papa's case, they tested his aptitude with the IBM Aptitude Test for Programmer Personnel (copyright 1964):

Logo and explanation from the front cover of a "IBM Aptitude Test for Programmer Personnel" with directions that read "1. Do not make any marks in this booklet. 2. On the separate answer sheet print your name, date, and other requested information in the proper spaces. 3. Then wait for further instructions.". The design is geometric and bland but not unpleasant.

Again, though, how do you evaluate programmer aptitude without a common programming language? Without common idioms? Without even a common vocabulary of what "code" could mean or be?

IBM used pattern-matching questions with letters:

Instructions reading "In Part I you will be given some problems like those on this page. The letters in each series follow a certain rule. For each series of letters you are to find the correct rule and complete the series. One of the letters at the right side of the page is the correct answer. Look at the example below." The provided example, marked "W." reads "a b a b a b a b" followed by five possible numbered answers "a b c d e".

And pattern-matching questions with pictures:

Instructions reading "In Part II you will be given some problems like those on this page. Each row is a problem. Each row consists of four figures on the left-hand side of the page and five figures on the right-hand side of the page. The four figures on the left make a series. You are to find out which one of the figures on the right-hand side would be the next or the fifth one in the series. Now look at example X". Example X is four squares, each with a single quadrant shaded. In order, top-right, bottom-right, bottom-left, top-left. The five possible answers labeled A through E are squares with one quadrant shaded (A bottom-right, B top-right, C bottom-left, D top-left), and a square with no quadrant shaded (E).

And arithmetic reasoning questions:

Instructions reading "In Part III you will be given some problems in arithmetical reasoning. After each problem there are five answers, but only one of them is the correct answer. You are to solve each problem and indicate the correct answer on the answer sheet. The following problems have been done correctly. Study them carefully." followed by "Example X: How many apples can you buy for 80 cents at the rate of 3 for 10 cents? (a) 6 (b) 12 (c) 18 (d) 24 (e) 30"

And that was it. For the standardized portion of the process, at least.

Papa delivered this test to my siblings and I when I think I was in Grade 9, so about 15 years of age. Even my 2- and 4-year-younger siblings performed well, and I and my 2-year-older sibling did nearly perfectly. Apparently the public education system had adapted to turning out programming personnel of high aptitude in the forty years or so since the test had been printed.

I was gifted Papa's aptitude test booklet, some IBM flowcharting and diagramming worksheets, and a couple example punchcards before his death. I was thrilled to be entrusted with them. I had great plans for high-quality preservation digitization. If my Brother multi-function's flatbed scanner wouldn't do the trick, I'd ask the local University's library for help. Or the Internet Archive itself!

The test booklet sat on my desk for years. And then Papa died. I placed the bulletin from the funeral service next to it on my desk. They both sat on my desk for further years.

I couldn't bring myself to start the project of digitizing and preserving these things. I just couldn't.

Part of it was how my brain works. But I didn't need a diagnosis to develop coping mechanisms for projects that were impossible to start. I bragged about having it to my then-coworker Mike Hoye, the sort who cared about things like this. Being uncharacteristically prideful in front of a peer, a mentor, that'd surely force me to start.

They sat on my desk for years more.

We renovated the old spare room into an office for my wife and moved her desk and all her stuff out so I could have the luxury of an office to myself. We repainted and reorganized my office.

I looked at the test booklet.

I filed it away. I forgot where. I gave up.

But then, today, I read an essay that changed things. I read Dr. Cat Hicks' Why I Cannot Be Technical. Not only does she reference Papa's booklet ("Am I the only person who is extremely passionate about getting their hands on a copy of things like the IBM programmer aptitude tests from the 60s?") but what she writes and how she writes reminds me of what drew me to blogging. What I wanted to contribute to and to change in this industry of ours. The feeling of maybe being a part of a movement, not a part of a machine.

I searched and searched and found the booklet. I looked at the flatbed scanner and remembered my ideas of finding the ideal digitization. The perfect preservation.

I said "Fuck it" and put it on the ground and started taking pictures with my phone.

To hell with perfect, I needed good enough.

I don't remember what else was involved in IBM's test of my Papa. I don't even know if they conducted it in Canada or flew him to the States. He probably told me. I'm sorry I don't remember.

I don't know why he never kept up with programming. I don't remember him ever working, just singing beautifully in the church choir, stuttering when speaking on the telephone, playing piano in the living room. He did like tech gadgets, though. He converted all our old home movies to DVD without touching a mouse or keyboard. I should've asked him why he never owned a minicomputer.

I do know why he didn't choose the IBM job, though. Sure, yes, he could stay closer to his family in Nova Scotia. Sure, he wouldn't have to wear quite as many suits. But the real crux was the offer that Irving gave him. IBM wanted him as a cog in their machine. Another programming person to feed into their maw and… well, who knows what next. But Irving? Well, Irving _also_ wanted that, true. They needed someone to operate their business machines for payroll and accounts and stuff.

But when the day's work was done? And all the data entry girls (because of course they were all women) were still on the clock? And there were CPU cycles available?

Irving offered to let my Papa input and organize his record collection.1

My recollection of my grandfather isn't perfect. But perhaps it's good enough.

:chutten

  1. Another thing I have in my good enough memory is that, to have the mainframe index his 78s, Papa needed to know the longest title of all the sides in his collection. It's a war song. And prepare your historical appreciation goggles because it's sexist as hell in 2025. But I may never forget 1919's "Would You Rather Be A Colonel With an Eagle on Your Shoulder or a Private With a Chicken on Your Knee?" ↩︎

17 Apr 2025 8:56pm GMT

The Mozilla Blog: Mozilla’s CEO weighs in on U.S. v. Google

The CEO of Mozilla, Laura Chambers, provided insights about the U.S. v. Google LLC case on search competition ahead of the trial slated to begin April 21, 2025.

"As the CEO of Mozilla, I often have conversations about the future of this company. Most times these conversations are tied to how we build a better Internet that is accessible to everyone. It's never about maximizing profits because we aren't owned by billionaires and our lone shareholder is a non-profit whose mission is to build an open and secure internet ecosystem that places privacy, security and the rights of individuals over the bottom line.

At this moment our mission is particularly top of mind. The Court presiding over the Department of Justice's search monopolization case against Google will soon convene a long-awaited remedies hearing that has the potential to significantly alter the industry and the open web.

Some of the remedies proposed in the case risk the future of our Firefox browser and Gecko browser engine-the last remaining non-Big Tech browser engine.

In the coming weeks, we hope to see a shift to focus on remedies that can improve search competition without harming the pro-competitive role that Firefox and other independent browsers play in the ecosystem.

I speak for many small and independent companies like Mozilla when I say that the benefits we deliver to consumers and competition can't be measured by our market share because we regularly punch above our weight.

We fully support the Department of Justice's efforts to improve competition in various digital markets, but we're concerned that the proposed remedies in the search case will do much more harm than good and unnecessarily seek to promote search competition at the expense of browser and browser engine competition. If the Department of Justice truly wants to fix competition, they can't solve one problem by creating another.

The outcome of this case isn't just about one company, it's about the future of the internet and the stakes couldn't be higher.

There are only three main browser engines left and only one engine-Mozilla's Gecko-is not owned by a Big Tech company. Browser engines shape how the web works. Gecko powers Firefox (and other independent browsers) and puts privacy and people first.

If it disappears, so does the open web.

Independent browsers like Firefox drive privacy innovation, security advancements, and offer people real choice. For over 25 years, Mozilla has fought for an open, competitive landscape where businesses can thrive, and consumers have real alternatives. We hope the remedies adopted by the Court enable us to continue this fight for many more years to come."

The post Mozilla's CEO weighs in on U.S. v. Google appeared first on The Mozilla Blog.

17 Apr 2025 12:10pm GMT

16 Apr 2025

feedPlanet Mozilla

This Week In Rust: This Week in Rust 595

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Miscellaneous

Crate of the Week

This week's crate is wgpu, a cross-platform graphics and compute library based on WebGPU.

Despite a lack of suggestions, llogiq is pleased with his choice.

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Let us know if you would like your feature to be tracked as a part of this list.

RFCs
Rust
Rustup

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

Updates from the Rust Project

480 pull requests were merged in the last week

Compiler
Library
Cargo
Rustdoc
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

Relatively small changes this week, nothing terribly impactful (positive or negative).

Triage done by @simulacrum. Revision range: e643f59f..15f58c46

1 Regressions, 3 Improvements, 3 Mixed; 2 of them in rollups 35 artifact comparisons made in total

Full report here

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Other Areas

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2025-04-16 - 2025-05-14 🦀

Virtual
Asia
Europe
North America
Oceania

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

IEEE 754 floating point, proudly providing counterexamples since 1985!

- Johannes Dahlström on rust-internals

Thanks to Ralf Jung for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, U007D, joelmarcey, mariannegoldin, bennyvasquez, bdillo

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

16 Apr 2025 4:00am GMT

15 Apr 2025

feedPlanet Mozilla

Mitchell Baker: The Ethos of Open Source

A couple of months ago I started posting about how I want to build a better world through technology and how I'll be doing that outside of Mozilla going forward. The original post has many references to "open" and "open source." It's easy to think that we all understand open source and we just need to apply it to new settings. I feel differently: we need to shape our collective understanding of the ethos of open source.

Open source has become mainstream as a part of the software development process. We can rightly say that the open source movement "won." However, this isn't enough for the future.

The open source movement was about more than convenience and avoiding payment. For many of us, open source was both a tool and an end in itself. Open source software allows people to participate in creating the software that has such great impact on our lives. The "right to fork" allows participants to try to correct wrongs in the system; it provides a mechanism for alternatives to emerge. This isn't a perfect system of course, and we've seen how businesses can wrap open source and the right to fork with other systems that diminish the impact of this right. So the past is not "The Perfect Era" that we should aim to replicate. The history of open source gives us valuable learning into what works and what doesn't so we can iterate towards what we need in this era.

The practical utility of open source software has become mainstream. The time is ripe to reinforce the deeper ethos of participation, opportunity, security and choice that drove the open source movement.

I'm looking for a good conversation about these topics. If you know of a venue where such conversations are happening in a thoughtful, respectful way please do let me know.

15 Apr 2025 9:23pm GMT

12 Apr 2025

feedPlanet Mozilla

Don Marti: picking up cheap shoes in front of a steamroller

Here's another privacy paradox for people who collect them.

There's an expression in finance: Picking Up Nickels In Front Of A Steam Roller. For some kinds of investing decisions, the investor is more likely to make a small gain than to lose money in each individual trade. But the total expected return over time is negative, because a large loss is an unlikely outcome of each trade. The decision to accept personalized ads or try to avoid them might be a similar bet.

For example, a typical positive outcome of getting personalized ads might be getting better shoes, cheaper. There's a company in China that is working the personalized ad system really well. Instead of paying for high production value ads featuring high-profile athletes in the USA, they're just doing the incremental data-driven marketing thing. Make shoes, experiment with the personalized ad system, watch the numbers, reinvest in both shoe improvements and improvements to the personalized ads. For customers, the shoe company represents the best-case scenario for turning on the personalized ads. You get a pair of shoes from China for $40 that are about as good as the $150 shoes from China that you would get from a a big-name brand. (The shoes might even be made by the same people out of the same materials.) I don't need to link to the company, just turn on personalized ads and if you want the shoes they'll find you.

That example might be an outlier on the win-win side, though. On average, personalized (behaviorally targeted) ads are likely to be associated with lower quality vendors and higher product prices compared to competing alternatives found among search results. (Mustri et al.) but let's pretend for a minute and say you figured out how to get targeted in the best possible way and come out on the winning side. That's pretty sweet-personalized ads save you more than a hundred bucks on shoes, right?

Here comes the steamroller, though.

In recent news, Baltimore sues 2 sportsbooks over alleged exploitative practices. Some people are likely to develop a gambling problem, and if you don't know in advance whether or not you're one of them, should you have the personalized ads turned on? You stand to lose a lot more than you would have gained by getting the cheap shoes or other miscellaneous stuff. It is possible that machine learning on the advertising or recommended content side could know more about you than you do, and the negative outcomes from falling for an online elder fraud scheme tend to be much larger than the positive outcomes from selecting the best of competing legitimate products.

The personalized advertising system can facilitate both win-win offers like the good shoes from an unknown brand or win-lose offers like those from sports betting apps that use predatory practices. The presence of both win-win and win-lose offers in the market is a fact that keeps getting oversimplified away by personalized advertising's advocates in academia. In practice, ad personalization gives an advantage to deceptive sellers. Another good example comes from the b2b side: malware in search ads personalized to an employee portal or SaaS application. From the CIO point of view, are you better off having employees get better-personalized search ads at work, or better off blocking a security incident before it starts?

People's reactions to personalization are worth watching, and reflect more widely held understanding of how information works in markets than personalized ad fandom does. The fact that Google may have used this data to conduct focused ad campaigns targeted back to you was disclosed as if it was a security issue, which makes sense. Greg Knauss writes, Blue Shield says that no bad actor was involved, but is that really true? Shouldn't a product that, apparently by default, takes literally anything it can-privacy be damned-and tosses it into the old ad-o-matic not be considered the output of a bad actor? Many people (but not everybody) consider being targeted for a personalized ad as a threat in itself. More: personalization risks

Bonus links

What If We Made Advertising Illegal? by Kōdō Simone. The traditional argument pro-advertising-that it provides consumers with necessary information-hasn't been valid for decades. In our information-saturated world, ads manipulate, but they don't inform. The modern advertising apparatus exists to bypass rational thought and trigger emotional responses that lead to purchasing decisions. A sophisticated machine designed to short-circuit your agency, normalized to the point of invisibility. (Personally I think it would be hard to come up with a law that would squeeze out all incentivized communication intended to cause some person to purchase some good or service, but it would be possible to regulate the information flows in the other direction-surveillance of audience by advertiser and intermediaries-in a way that would mostly eliminate surveillance advertising as we know it: Big Tech platforms: mall, newspaper, or something else?)

Meta secretly helped China advance AI, ex-Facebooker will tell Congress by Ashley Belanger. In her prepared remarks, which will be delivered at a Senate subcommittee on crime and counterterrorism hearing this afternoon, Wynn-Williams accused Meta of working hand in glove with the Chinese Communist Party (CCP). That partnership allegedly included efforts to construct and test custom-built censorship tools that silenced and censored their critics as well as provide the CCP with access to Meta user data-including that of Americans. (And if they're willing to do that, then the elder fraud ads on Facebook are just business as usual.)

Protecting Privacy, Empowering Small Business: A Path Forward with S.71 (A privacy law with private right of action gets enforced based on what makes sense to normal people in a jury box, not to bureaucrats who think it's normal to read too many PDFs. Small businesses are a lot better off with this common-sense approach instead of having to feed the compliance monster.)

This startup just hit a big milestone for green steel production by Casey Crownhart. Boston Metal uses electricity in a process called molten oxide electrolysis (MOE). Iron ore gets loaded into a reactor, mixed with other ingredients, and then electricity is run through it, heating the mixture to around 1,600 °C (2,900 °F) and driving the reactions needed to make iron. That iron can then be turned into steel. Crucially for the climate, this process emits oxygen rather than carbon dioxide…

12 Apr 2025 12:00am GMT

11 Apr 2025

feedPlanet Mozilla

Spidermonkey Development Blog: Shipping Temporal

The Temporal proposal provides a replacement for Date, a long standing pain-point in the JavaScript language. This blog post describes some of the history and motivation behind the proposal. The Temporal API itself is well docmented on MDN.

Temporal reached Stage 3 of the TC39 process in March 2021. Reaching Stage 3 means that the specification is considered complete, and that the proposal is ready for implementation.

SpiderMonkey began our implementation that same month, with the initial work tracked in Bug 1519167. Incredibly, our implementation was not developed by Mozilla employees, but was contributed entirely by a single volunteer, André Bargull. That initial bug consisted of 99 patches, but the work did not stop there, as the specification continued to evolve as problems were found during implementation. Beyond contributing to SpiderMonkey, André filed close to 200 issues against the specification. Bug 1840374 is just one example of the massive amount of work required to keep up to date with the specification.

As of Firefox 139, we've enabled our Temporal implementation by default, making us the first browser to ship it. Sometimes it can seem like the ideas of open source, community, and volunteer contributors are a thing of the past, but the example of Temporal shows that volunteers can still have a meaningful impact both on Firefox and on the JavaScript language as a whole.

Interested in contributing?

Not every proposal is as large as Temporal, and we welcome contributions of all shapes and sizes. If you're interested in contributing to SpiderMonkey, please have a look at our mentored bugs. You don't have to be an expert :). If your interests are more on the specification side, you can also check out how to contribute to TC39.

11 Apr 2025 6:00pm GMT

The Mozilla Blog: Inside the newsletter making layoffs feel less bleak and more like a group chat

A woman with wavy brown hair wearing an off-the-shoulder striped top sits in front of a red background, framed by colorful digital icons on a blue grid backdrop.

Here at Mozilla, we are the first to admit the internet isn't perfect, but we know the internet is pretty darn magical. The internet opens up doors and opportunities, allows for human connection, and lets everyone find where they belong - their corners of the internet. We all have an internet story worth sharing. In My Corner Of The Internet, we talk with people about the online spaces they can't get enough of, the sites and forums that shaped them, and how they would design their own corner of the web.

We caught up with Melanie Ehrenkranz, the writer and creative strategist behind Laid Off, a weekly newsletter interviewing people about job loss - and everything wrapped up in it. She talks about building a space that's "real, not bleak"; the forums and fan theories that keep her online; and how her inbox became one of her favorite places to hang out online.

What is your favorite corner of the internet?

I run a dedicated Discord for Laid Off - we just hit 800 members and it's the most supportive community. It's weird to say "we have fun" when referring to a space for people affected by layoffs, but we really do. There was a tight group of members that used to show up each week in the #severance channel to share live reactions to new episodes on Thursday nights. The rest of the week, people could talk about actual severance, that thing that you might get a few weeks or months of, if you're lucky.

What is an internet deep dive that you can't wait to jump back into?

The Yellowjackets subreddit after new episodes drop. The last two seasons have really gone off the rails, but I'm here til the end. I probably enjoy reading people's theories more than the actual episodes these days.

What is the one tab you always regret closing?

My former editor (and friend) Cooper Fleishman has written an incredible Survivor watch guide. I am extremely late to the fandom, but now I'm locked in.

What can you not stop talking about on the internet right now?

Layoffs. I started my Substack, Laid Off, in August of last year. I interview smart and cool people who have been laid off each week. I also work on ~quarterly trend reports to better understand the layoff landscape.

What was the first online community you engaged with?

It's a blur of AIM chat rooms, MySpace, and Neopets. A lot of huddling around my hunking my computer, setting moody away messages, checking changes in my friends' top eights, and saving up for new paint brushes. I miss how slow things were, and not just the actual lack of speed, but how unfazed I was by it. Downloading a Strokes song on Kazaa meant adding another 10 to 20 minutes of load time. I'd just throw on an away message and play outside while the page loaded.

If you could create your own corner of the internet, what would it look like?

That's the hope with Laid Off. I'm trying to build the coolest place on the internet to talk about being laid off. I want it to feel cathartic, not bleak, but no toxic positivity. A space that feels nonjudgmental and inclusive. No assholes. Treat everyone with kindness.

The newsletter and community isn't just for people who've been laid off, though they're at the heart of it. It's also meant to illuminate the cracks in our systems and how work, stability and identity are shifting for all of us. To help us understand what's broken, what's changing and what we might build next.

What articles and/or videos are you waiting to read/watch right now?

I discover the coolest reads and recs from some of my favorite Substacks - as seen on by Ochuko Akpovbovbo, Feed Me by Emily Sundberg, Read Max by Max Read, Bad Brain by Ashley Reese, Extracurricular by Tembe Denton-Hurst, You've Got Lipstick on Your Chin by Arabelle Sicardi, and Gen-Z Gov by Kate Glavan, and the Dirt universe.


I rarely go to a publication's homepage anymore - I'm either reading/clicking straight from my inbox or the Substack app. And with all the brands making their way to the platform, I'll be even more incentivized to hang out in my inbox.

Your Substack has created a space where people can be real about job loss. What's something surprising you've learned from these conversations?

I try to leave my assumptions at the door. What did surprise me was how many conversations are happening. I get notifications all day long of people starting new threads in the Substack Chat and on Discord, covering… everything and anything. People venting about how AI is screwing them over both in the job search process and within their actual careers. People wondering if it's normal for a hiring manager to ask them to take a personality test. Dissecting insensitive language of rejection emails, or swapping "getting ghosted" stories. Someone even dropped a photo of their redacted severance contract in a thread the other week for legal and negotiation advice.

Melanie Ehrenkranz is a writer and creative strategist focused on community, technology and power. She leads content and community for Sophia Amoruso's Business Class, a membership-based digital entrepreneurship community and course for founders, freelancers, solopreneurs, creators and side hustlers.

The post Inside the newsletter making layoffs feel less bleak and more like a group chat appeared first on The Mozilla Blog.

11 Apr 2025 3:54pm GMT

Mozilla Thunderbird: VIDEO: The New Account Hub

In this month's Community Office Hours, we're chatting with Vineet Deo, a Software Engineer on the Desktop team, who walks us through the new Account Hub on the Desktop app. If you want a sneak peak at this new streamlined experience, you can find it in the Daily channel now and the Beta channel towards the end of April.

Next month, we'll be chatting with our director Ryan Sipes. We'll be covering the new Thunderbird Pro and Thundermail announcement and the structure of MZLA compared to the Mozilla Foundation and Corporation. And we'll talk about how Thunderbird put the fun in fundraising!

March Office Hours: The New Account Hub

Setting up a new email account in Thunderbird is already a solid experience, so why the update? Firstly, this is the first thing new users will see in the app. Thus, it's important it has the same clean, cohesive look that is becoming the new Thunderbird design standard. It's also helpful for users coming from other email clients to have a familiar, wizard-like experience. While the current account setup works well, it's browser based. This makes it possible a user could exit out before finishing and get lost before they even started. This is the opposite of what we want for potential users!

Vineet and his team are also working to make the new Account Hub ready for Exchange. Likewise, they also have plans for a similar hub to set up new address books and calendars. We're proud of the collaboration between back and frontend teams, and designers and engineers, to make the Account Hub.

Watch, Read, and Get Involved

But don't take our word for it! Watch Vineet's Account Hub talk and demo, along with a Q&A session. If you're comfortable testing Daily, you can test this new feature now. (Go to File > New > Email Account to start the experience.) Otherwise, keep an eye on our Beta release channel at the end of April. And if you're watching this after Account Hub is part of the regular release, now you know the feature's story!

VIDEO (Also on Peertube):

Account-Hub-Community-Hours-1Download

Get Involved

The post VIDEO: The New Account Hub appeared first on The Thunderbird Blog.

11 Apr 2025 12:18pm GMT

The Rust Programming Language Blog: crates.io security incident: improperly stored session cookies

Today the crates.io team discovered that the contents of the cargo_session cookie were being persisted to our error monitoring service, Sentry, as part of event payloads sent when an error occurs in the crates.io backend. The value of this cookie is a signed value that identifies the currently logged in user, and therefore these cookie values could be used to impersonate any logged in user.

Sentry access is limited to a trusted subset of the crates.io team, Rust infrastructure team, and the crates.io on-call rotation team, who already have access to the production environment of crates.io. There is no evidence that these values were ever accessed or used.

Nevertheless, out of an abundance of caution, we have taken these actions today:

  1. We have merged and deployed a change to redact all cookie values from all Sentry events.
  2. We have invalidated all logged in sessions, thus making the cookies stored in Sentry useless. In effect, this means that every crates.io user has been logged out of their browser session(s).

Note that API tokens are not affected by this: they are transmitted using the Authorization HTTP header, and were already properly redacted before events were stored in Sentry. All existing API tokens will continue to work.

We apologise for the inconvenience. If you have any further questions, please contact us on Zulip or GitHub.

11 Apr 2025 12:00am GMT

10 Apr 2025

feedPlanet Mozilla

Mozilla Thunderbird: Thunderbird for Android March 2025 Progress Report

Hello, everyone, and welcome to the Thunderbird for Android March 2025 Progress Report. We're keeping our community updated on everything that's been happening in the Android team, which is quickly becoming a more general mobile team with some recent hires. In addition to team news, we're talking about our roadmap board on GitHub.

Team Changes

In March we said goodbye to cketti, the K-9 Mail maintainer who joined the team when Thunderbird first announced plans for an Android app. We're very grateful for everything he's created, and for his trust that K-9 Mail and Thunderbird for Android are in good hands. But we also said hello to Todd Heasley, our new iOS engineer, who started March 26. We also have just added Ashley Soucar, an Android/iOS engineer, who joined us on April 7. If all continues to go well, we'll also be adding another Android engineer in the next couple of weeks.

Our Roadmap Board

Our roadmap board is now available! We're grateful to the Council for their trust and support in approving it. As the board will reflect any changes in our planning, this is the most up-to-date source for our upcoming development. Each epic will show its objective and what's in scope - and as importantly, what's out of scope. The project information on the side will tell you if an epic is in the backlog or work in progress.

If you'd like to know what we're working on right now, check out our sprint board.

Contribute by Triaging GitHub Issues

One way to contribute to Thunderbird for Android is by triaging open GitHub Issues. In March, we did a major triage with over 150 issues closed as duplicates, marked with 'works for me,' or elevating them up to the efforts and features described in the roadmap above. Especially since we're a small team, triaging issues helps us know where to act on incoming issues. This is a great way to get started as a Thunderbird for Android contributor.


To start triaging bugs, have a look at the 'unconfirmed' issues. Try to reproduce the issue to help verify that the issue exists. Then add a comment with your results and any other information you found that might help narrow down the issue. If you see users generally saying "it doesn't work", ask them for more details or to enable logs. This way we know when to remove the unconfirmed label. If you have questions along the way or need someone to confirm a thought you had, feel free to ask in the community support channel.

Account Drawer

Our main engineering focus in March has been the account drawer we shared screenshots on in the January/February update. Given the settings design includes a few non-standard components, we took the opportunity to write a modern settings framework based on Jetpack Compose and make use of it for the new drawer. There will be some opportunities to contribute here in the future, as we'd like to migrate our old settings UI to the new system.

We have a few crashes and rough edges to polish, but are very close to enabling the feature flag in beta. If you aren't already using it and want to get early access, install our beta today.

I'd also like to call out a pull request by Clément, who contributed support for a folder hierarchy. The amazing thing here-our design folks were working out a proposal because we were interested in this as well, and without knowing, Clément came up with the same idea and came in with a pull request that really hit the spot. Great work!

Community Contributions

In addition to the folder hierarchy mentioned above, here are a few community activities in March:

This is quite a list, great work! When you think about Thunderbird for Android or K-9 Mail, what was the last major annoyance you stumbled upon? If you are an Android developer, now is a good time to fix it. You'll see your name up here next time as well 🙂

The post Thunderbird for Android March 2025 Progress Report appeared first on The Thunderbird Blog.

10 Apr 2025 4:06pm GMT

09 Apr 2025

feedPlanet Mozilla

The Mozilla Blog: How UEFA and Mozilla’s Anonym nailed TikTok campaigns without compromising user data

When UEFA's Men's Club Competitions Online Store (operated by Event Merchandising Ltd) set out to run a TikTok campaign during the 2024 finals, the goal was clear: engage passionate club fans and drive sales of official gear - without compromising the data privacy of their most loyal supporters and spectators.

Together with Anonym - a privacy-first data analytics and measurement solution harnessed by TikTok to balance campaign performance with user privacy - UEFA found a way to measure campaign performance while carefully safeguarding their fans' user data. With no complex integration or data science onboarding required, UEFA used Anonym's privacy-preserving tools to gain meaningful insights quickly and seamlessly - proving that strong results and privacy standards can go hand-in-hand.

This case study offers an amazing example of how brands can gain real performance insights from their campaigns, while also keeping user privacy front and center - a winning strategy straight out of Mozilla's privacy-preserving playbook.

Read on for the UEFA case study.

Private measurement provides UEFA with first look at performance

UEFA logo next to stats showing +93% lift in conversions, +94% lift in sales, and 99% statistical significance on a green background.

The objective

UEFA's Men's Club Competitions Online Store (operated by Event Merchandising Ltd), supporting fans of the massively popular UEFA Champions League and UEFA Europa League, chose TikTok to promote its clothing and accessories website during the 2024 finals. UEFA cares deeply about privacy and needed a solution that allowed it to measure the impact of its advertising on TikTok without sending any user personal information to the entertainment platform directly.

The solution

To accomplish this objective, UEFA and Event Merchandising, Ltd. partnered with Anonym, a sophisticated privacy-first data analytics solution harnessed by TikTok to balance campaign performance with user privacy. UEFA leveraged Anonym Private Lift to measure the incrementality (or causal impact) of its three week campaign on TikTok across Europe. All processing occurred in Europe and results were delivered within days of the campaign end. No integration work was required from UEFA or Event Merchandising Ltd. They simply leveraged Anonym's drag-and-drop interface, ensuring all data was correctly formatted and encrypted.

Three vertical UEFA promo posters for 2024 finals: Athens for the Europa Conference League with a marble statue, London for the Champions League with a player in a locker room, and Dublin for the Europa League featuring a woman in a pub wearing team gear.

The results

After the campaign ended, Anonym matched hashed and encrypted sales data with hashed and encrypted impression data from TikTok within a confidential computing environment. The data was processed using a differentially private conversion lift algorithm. Differential privacy is a method that makes individual data points indistinguishable and actionable at the same time - simultaneously enhancing user privacy while allowing effective analysis of ad performance.

The results were impressive:

With Anonym's privacy-first measurement solution, UEFA and Event Merchandising, Ltd. unlocked world-class insights into their TikTok campaign performance - delivering winning results off the pitch, while setting a new standard for protecting fan privacy.

A teal lock icon next to the bold text "Anonym" on a black background.

Performance, powered by privacy

Learn more about Anonym

The post How UEFA and Mozilla's Anonym nailed TikTok campaigns without compromising user data appeared first on The Mozilla Blog.

09 Apr 2025 10:20pm GMT

The Mozilla Blog: Data ethics in action: Zenjob, TikTok and Mozilla’s Anonym show a better way to measure

Let's face it - measuring ad performance is challenging in a shifting privacy landscape. With tightening regulations and data sharing under a well-deserved microscope, advertisers are under more pressure than ever to prove their campaigns can work without crossing privacy lines.

That was the exact puzzle Zenjob had to solve. As a platform connecting people to flexible work, they wanted to make the most of a key hiring season in 2024 with a fresh TikTok campaign. They also wanted to do it right by keeping user privacy front and center, a goal that we at Mozilla passionately, operationally and increasingly technologically share.

In pursuit of a campaign that successfully derived valuable insights without exposing user-level data, Zenjob teamed up with Mozilla's Anonym, a privacy-first data analytics solution harnessed by TikTok to balance campaign performance with user privacy. Together, Zenjob, TikTok and Anonym found a way to measure what really matters - like campaign impact and attribution - without exposing any user-level data.

Why is this story worth a read? Because it proves insights and integrity can coexist. Zenjob didn't just run a high-performing campaign - they saw a serious lift in signups and walked away with a crystal clear view of what worked, all while keeping sensitive user data secure and private.

If you're wondering how to balance performance with privacy, this case study is a great place to start.

Private measurement provides Zenjob with proof of incremental performance on iOS

The objective

Zenjob, the innovative platform connecting job seekers with flexible work opportunities, chose TikTok to promote its services during a key hiring season in 2024. As a platform, TikTok connects billions of users on a global scale. Zenjob's aim was to expand the reach of their job-matching marketplace while simultaneously maintaining its deep commitment to protecting user privacy. This required a solution that allowed them to measure the effectiveness of their TikTok app-focused advertising campaigns without sharing any user-level data directly with the platform.

The solution

To accomplish this objective, Zenjob, Ltd. partnered with Anonym, a privacy-first data analytics solution harnessed by TikTok to seamlessly integrate advanced privacy-preserving protections with campaign efficiency and performance measurements. Zenjob leveraged Anonym's Private Lift to measure the incrementality (or causal impact) of its four-week campaign on TikTok across Germany, and Private Attribution to determine what levers to use to optimize its campaigns (e.g. creative, geotargeting, etc.) All processing occurred in Europe and results were delivered within days of the campaign end. No integration work was required from Zenjob - they simply leveraged Anonym's drag-and-drop interface, ensuring all data was correctly formatted and encrypted.

Three young women in different indoor settings talk about finding flexible student jobs in Germany; text overlays include phrases like "Jobs in Germany 🇩🇪", "ZENJOB", and "OF A JOB NOW".

The results

After the campaign ended, Anonym matched hashed and encrypted sales data with hashed and encrypted impression data from TikTok within a confidential computing environment. The data was processed using differentially private algorithms for lift and attribution. Differential privacy is a method that adds noise to data sets, making individual data points indistinguishable to enhance user privacy - while simultaneously allowing effective, actionable analysis of ad performance.

The results were impressive:

By rolling out Anonym's privacy-preserving measurement solution, Zenjob boosted visibility into campaign performance - while keeping data safe, user trust intact, and privacy at the heart of it all.

A teal lock icon next to the bold text "Anonym" on a black background.

Performance, powered by privacy

Learn more about Anonym

The post Data ethics in action: Zenjob, TikTok and Mozilla's Anonym show a better way to measure appeared first on The Mozilla Blog.

09 Apr 2025 10:20pm GMT

This Week In Rust: This Week in Rust 594

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tag us at @thisweekinrust.bsky.social on Bluesky or @ThisWeekinRust on mastodon.social, or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub and archives can be viewed at this-week-in-rust.org. If you find any errors in this week's issue, please submit a PR.

Want TWIR in your inbox? Subscribe here.

Updates from Rust Community

Official
Newsletters
Project/Tooling Updates
Observations/Thoughts
Rust Walkthroughs
Research
Miscellaneous

Crate of the Week

This week's crate is graft, a transactional storage engine optimized for lazy, partial, and strongly consistent replication.

Thanks to Carl Sverre for the self-suggestion!

Please submit your suggestions and votes for next week!

Calls for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization.

If you are a feature implementer and would like your RFC to appear in this list, add a call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Let us know if you would like your feature to be tracked as a part of this list.

Call for Participation; projects and speakers

CFP - Projects

Always wanted to contribute to open-source projects but did not know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

No Calls for participation were submitted this week.

If you are a Rust project owner and are looking for contributors, please submit tasks here or through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

CFP - Events

Are you a new or experienced speaker looking for a place to share something cool? This section highlights events that are being planned and are accepting submissions to join their event as a speaker.

If you are an event organizer hoping to expand the reach of your event, please submit a link to the website through a PR to TWiR or by reaching out on X (formerly Twitter) or Mastodon!

Updates from the Rust Project

451 pull requests were merged in the last week

Compiler
Library
Cargo
Rustfmt
Clippy
Rust-Analyzer
Rust Compiler Performance Triage

A busy week with lots of performance improvements. The largest performance improvement was from a revert of a previous week's regression just in time for the beta release. Another large improvement came to small tweaks in the query system showing that there still are opportunities for small, targeted performance improvements in the compiler.

Triage done by @rylev. Revision range: 2ea33b59..e643f59f

Summary:

(instructions:u) mean range count
Regressions ❌
(primary)		 0.8% [0.2%, 1.9%] 11
Regressions ❌
(secondary)		 8.4% [0.2%, 38.5%] 16
Improvements ✅
(primary)		 -1.0% [-35.1%, -0.2%] 206
Improvements ✅
(secondary)		 -1.8% [-8.6%, -0.1%] 155
All ❌✅ (primary) -0.9% [-35.1%, 1.9%] 217

2 Regressions, 9 Improvements, 5 Mixed; 4 of them in rollups 48 artifact comparisons made in total

Full report here.

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

Tracking Issues & PRs

Rust

Other Areas

Let us know if you would like your PRs, Tracking Issues or RFCs to be tracked as a part of this list.

New and Updated RFCs

Upcoming Events

Rusty Events between 2025-04-09 - 2025-05-07 🦀

Virtual
Asia
Europe
North America
Oceania

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

The moment I froze Doctest with a loop in a comment.

- /u/HaMMeReD describing their first Rust Whoa! moment on /r/rust

Despite a lack of suggestions, llogiq is content with his choice.

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, U007D, joelmarcey, mariannegoldin, bennyvasquez, bdillo

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

09 Apr 2025 4:00am GMT

08 Apr 2025

feedPlanet Mozilla

Mozilla Thunderbird: Thunderbird Monthly Development Digest – March 2025

Hello again Thunderbird Community! It's been almost a year since I joined the project and I've recently been enjoying the most rewarding and exciting work days in recent memory. The team who works on making Thunderbird better each day is so passionate about their work and truly dedicated to solving problems for users and supporting the broader developer community. If you are reading this and wondering how you might be able to get started and help out, please get in touch and we would love to get you off the ground!

Paddling Upstream

As many of you know, Thunderbird relies heavily on the Firefox platform and other lower-level code that we build upon. We benefit immensely from the constant flow of improvements, fixes, and modernizations, many of which happen behind the scenes without requiring our input.

The flip side is that changes upstream can sometimes catch us off guard - and from time to time we find ourselves firefighting after changes have been made. This past month has been especially busy as we've scrambled to adapt to unexpected shifts, with our team hunting down places to adjust Content Security Policy (CSP) handling and finding ways to integrate a new experimental whitespace normalizer. Very much not part of our plan, but critical nonetheless.

Calendar UI Rebuild

The implementation of the new event dialog is moving along steadily with the following pieces of the puzzle recently landing:

The focus has now turned to loading data into the various containers so that we can enable this feature later this month and ask our QA team and Daily users to help us catch early problems.

Keep track of feature delivery via the [meta] bug

Exchange Web Services support in Rust

We're aiming to get a 0.2 release into the hands of Daily and QA testers by the end of April so a number of remaining tasks are in the queue - but March saw a number of features completed and pushed to Daily

Keep track of feature delivery here.

Account Hub

This feature was "preffed on" as the default experience for the Daily build but recent changes to our Oauth process have required some rework to this user experience, so it won't hit beta until the end of the month. It's beautiful and well worth considering a switch to Daily if you are currently running beta.

Global Message Database

The New Zealand team completed a successful work week and have since pushed through a significant chunk of the research and refactoring necessary to integrate the new database with existing interfaces.

The patches are pouring in and are enabling data adapters, sorting, testing and message display for the Local Folders Account, with an aim to get all existing tests to pass with the new database enabled. The path to this goal is often meandering and challenging but with our most knowledgeable and experienced team members dedicated to the project, we're seeing inspiring progress.

The team maintains their documentation in Sourcedocs which are visible here.

In-App Notifications

A few last-minute changes were made and uplifted to our ESR version early this month so if you use the ESR and are in the lucky 2% of users targeted, watch out for an introductory notification!
We've also wrapped up work on two significant enhancements which are now on Daily and will make their way to other releases over the course of the month:

Meta Bug & progress tracking.

New Features Landing Soon

A number of requested features and important fixes have reached our Daily users this month. We want to give special thanks to the contributors who made the following possible…

As usual, if you want to see and use new features as they land, and help us squash some early bugs, you can try running daily and check the pushlog to see what has recently landed. This assistance is immensely helpful for catching problems early.

-

Toby Pilling

Senior Manager, Desktop Engineering

The post Thunderbird Monthly Development Digest - March 2025 appeared first on The Thunderbird Blog.

08 Apr 2025 1:31pm GMT

The Rust Programming Language Blog: March Project Goals Update

The Rust project is currently working towards a slate of 40 project goals, with 3 of them designated as Flagship Goals. This post provides selected updates on our progress towards these goals (or, in some cases, lack thereof). The full details for any particular goal are available in its associated tracking issue on the rust-project-goals repository.

Flagship goals

Bring the Async Rust experience closer to parity with sync Rust

Why this goal? This work continues our drive to improve support for async programming in Rust. In 2024H2 we stabilized async closures; explored the generator design space; and began work on the dynosaur crate, an experimental proc-macro to provide dynamic dispatch for async functions in traits. In 2025H1 our plan is to deliver (1) improved support for async-fn-in-traits, completely subsuming the functionality of the async-trait crate; (2) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (3) and improve the ergonomics of Pin, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.

What has happened? Generators. Initial implementation work has started on an iter! macro experiment in https://github.com/rust-lang/rust/pull/137725. Discussions have centered around whether the macro should accept blocks in addition to closures, whether thunk closures with an empty arguments list should implement IntoIterator, and whether blocks should evaluate to a type that is Iterator as well as IntoIterator. See the design meeting notes for more.

dynosaur. We released dynosaur v0.2.0 with some critical bug fixes and one breaking change. We have several more breaking changes queued up for an 0.3 release line that we also use plan to use as a 1.0 candidate.

Pin ergonomics. https://github.com/rust-lang/rust/pull/135733 landed to implement &pin const self and &pin mut self sugars as part of the ongoing pin ergonomics experiment. Another PR is open with an early implementation of applying this syntax to borrowing expressions. There has been some discussion within parts of the lang team on whether to prefer this &pin mut T syntax or &mut pin T, the latter of which applies equally well to Box<pin T> but requires an edition.

No detailed updates available.


Organize Rust All-Hands 2025

Why this goal? May 15, 2025 marks the 10-year anniversary of Rust's 1.0 release; it also marks 10 years since the creation of the Rust subteams. At the time there were 6 Rust teams with 24 people in total. There are now 57 teams with 166 people. In-person All Hands meetings are an effective way to help these maintainers get to know one another with high-bandwidth discussions. This year, the Rust project will be coming together for RustWeek 2025, a joint event organized with RustNL. Participating project teams will use the time to share knowledge, make plans, or just get to know one another better. One particular goal for the All Hands is reviewing a draft of the Rust Vision Doc, a document that aims to take stock of where Rust is and lay out high-level goals for the next few years.

What has happened?

  • Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.)
  • Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.)

Mara has asked all attendees for suggestions for guests to invite. Based on that, Mara has invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget.

  • Open the call for proposals for talks for the Project Track (on wednesday) as part of the RustWeek conference.

The Rust Project Track at RustWeek has been published: https://rustweek.org/schedule/wednesday/

This track is filled with talks that are relevant to folks attending the all-hands afterwards.

1 detailed update available.

Comment by @m-ou-se posted on 2025-04-01:

  • Invite more guests, after deciding on who else to invite. (To be discussed today in the council meeting.)
  • Figure out if we can fund the travel+hotel costs for guests too. (To be discussed today in the council meeting.)

I've asked all attendees for suggestions for guests to invite. Based on that, I've invited roughly 20 guests so far. Only two of them needed funding for their travel, which we can cover from the same travel budget.


Stabilize tooling needed by Rust for Linux

Why this goal? This goal continues our work from 2024H2 in supporting the experimental support for Rust development in the Linux kernel. Whereas in 2024H2 we were focused on stabilizing required language features, our focus in 2025H1 is stabilizing compiler flags and tooling options. We will (1) implement RFC #3716 which lays out a design for ABI-modifying flags; (2) take the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options; (3) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).

What has happened? Most of the major items are in an iteration phase. The rustdoc changes for exporting doctests are the furthest along, with a working prototype; the RFL project has been integrating that prototype and providing feedback. Clippy stabilization now has a pre-RFC and there is active iteration towards support for build-std.

Other areas of progress:

2 detailed updates available.

Comment by @nikomatsakis posted on 2025-03-13:

Update from our 2025-03-12 meeting (full minutes):

  • RFL team requests someone to look at #138368 which is needed by kernel, @davidtwco to do so.
  • -Zbinary-dep-info may not be needed; RFL may be able to emulate it.
  • rustdoc changes for exporting doctests are being incorporated. @GuillaumeGomez is working on the kernel side of the feature too. @ojeda thinks it would be a good idea to do it in a way that does not tie both projects too much, so that rustdoc has more flexibility to change the output later on.
  • Pre-RFC authored for clippy stabilization.
  • Active iteration on the build-std design; feedback being provided by cargo team.
  • @wesleywiser sent a PR to stabilize -Zdwarf-version.
  • RfL doesn't use cfg(no_global_oom_handling) anymore. Soon, stable/LTS kernels that support several Rust versions will not use it either. Thus upstream Rust could potentially remove the cfg without breaking Linux, though other users like Windows may be still using it (#t-libs>no_global_oom_handling removal).
  • Some discussion about best way forward for disabling orphan rule to allow experimentation with no firm conclusion.

Comment by @nikomatsakis posted on 2025-03-26:

Updates from today's meeting:

Finalizing 2024h2 goals

  • asm-goto is now stabilized! will be released in 1.87.
  • asm-const has a preliminary impl, gcc support is needed.
  • While not used in RFL, naked_asm is not on the list but it will be moving forward for stabilization. It suffers from the same LLVM bug as global_asm forgetting target feature flags.

ABI-modifying compiler flags

Extract dependency information, configure no-std externally (-Zcrate-attr)

Rustdoc features to extract doc tests

  • No update.

Clippy configuration

  • Pre-RFC was published but hasn't (to our knowledge) made progress. Would be good to sync up on next steps with @flip1995.

Build-std

  • No update. Progress will resume next week when the contributor working on this returns from holiday.

-Zsanitize-kcfi-arity

  • Added this as a new deliverable. These kind of "emerging codegen flag" requests can be expected from time to time. Notes available here and here.
  • The PR has been reviewed and is unblocked to land.


Goals looking for help

Promoting Parallel Front End

Help wanted: Help test the deadlock code in the issue list and try to reproduce the issues. If you'd like to help, please post in this goal's dedicated zulip topic.

1 detailed update available.

Comment by @SparrowLii posted on 2025-03-18:

  • Key developments: Several deadlock issue that remain for more than a year were resolved by #137731 The new test suit for parallel front end is being improved
  • Blockers: null
  • Help wanted: Help test the deadlock code in the issue list and try to reproduce the issue


Stabilize public/private dependencies

Help wanted: T-compiler people to work on the blocking issues #119428 and #71043. If you'd like to help, please post in this goal's dedicated zulip topic.

1 detailed update available.

Comment by @epage posted on 2025-03-17:

  • Key developments: @tgross35 got rust-lang/rust#135501 merged which improved which made progress on rust-lang/rust#119428, one of the two main blockers. In rust-lang/rust#119428, we've further discussed further designs and trade offs.
  • Blockers: Further work on rust-lang/rust#119428 and rust-lang/rust#71043
  • Help wanted: T-compiler people to work on those above issues.


Other goal updates

"Stabilizable" prototype for expanded const generics
1 detailed update available.

Comment by @BoxyUwU posted on 2025-03-17:

camelids PR has been merged, we now correctly (to the best of my knowledge) lower const paths under mgca. I have a PR open to ensure that we handle evaluation of paths to consts with generics or inference variables correctly, and that we do not attempt to evaluate constants before they have been checked to be well formed. I'm also currently mentoring someone to implement proper handling of normalization of inherent associated constants under mgca.

build-std
1 detailed update available.

Comment by @davidtwco posted on 2025-03-03:

A small update, @adamgemmell shared revisions to the aforementioned document, further feedback to which is being addressed.

Continue resolving `cargo-semver-checks` blockers for merging into cargo

Earlier this month, we completed one checkbox of the goal: #[doc(hidden)] in sealed trait analysis, live in cargo-semver-checks v0.40. We also made significant progress on type system modeling, which is part of two more checkboxes.

Additionally, cargo-semver-checks is participating in Google Summer of Code, so this month we had the privilege of merging many contributions from new contributors who are considering applying for GSoC with us! We're looking forward to this summer, and would like to wish the candidates good luck in the application process!

1 detailed update available.

Comment by @obi1kenobi posted on 2025-03-08:

Key developments:

  • Sealed trait analysis correctly handles #[doc(hidden)] items. This completes one checkbox of this goal!
  • We shipped a series of lints detecting breakage in generic types, lifetimes, and const generics. One of them has already caught accidental breakage in the real world!

cargo-semver-checks v0.40, released today, includes a variety of improvements to sealed trait analysis. They can be summarized as "smarter, faster, more correct," and will have an immediate positive impact on popular crates such as diesel and zerocopy.

While we already shipped a series of lints detecting generics-related breakage, more work is needed to complete that checkbox. This, and the "special cases like 'static and ?Sized", will be the focus of upcoming work.

Declarative (`macro_rules!`) macro improvements
No detailed updates available.
Evaluate approaches for seamless interop between C++ and Rust
1 detailed update available.

Comment by @tmandry posted on 2025-03-25:

Since our last update, there has been talk of dedicating some time at the Rust All Hands for interop discussion; @baumanj and @tmandry are going to work on fleshing out an agenda. @cramertj and @tmandry brainstormed with @oli-obk (who was very helpful) about ways of supporting a more ambitious "template instantiation from Rust" goal, and this may get turned into a prototype at some point.

Experiment with ergonomic ref-counting

There is now an early prototype available that allows you to write x.use; if the type of X implements UseCloned, then this is equivalent to x.clone(), else it is equivalent to a move. This is not the desired end semantics in a few ways, just a step along the road. Nothing to see here (yet).

1 detailed update available.

Comment by @nikomatsakis posted on 2025-03-17:

Update: rust-lang/rust#134797 has landed.

Semantics as implemented in the PR:

  • Introduced a trait UseCloned implemented for Rc and Arc types.
  • x.use checks whether x's type X implements the UseCloned trait; if so, then x.use is equivalent to x.clone(), otherwise it is a copy/move of x;
  • use || ...x... closures act like move closures but respect the UseCloned trait, so they will either clone, copy, or move x as appropriate.

Next steps:

  • Modify codegen so that we guarantee that x.use will do a copy if X: Copy is true after monomorphization. Right now the desugaring to clone occurs before monomorphization and hence it will call the clone method even for those instances where X is a Copy type.
  • Convert x.use to a move rather than a clone if this is a last-use.
  • Make x equivalent to x.use but with an (allow-by-default) lint to signal that something special is happened.

Notable decisions made and discussions:

  • Opted to name the trait that controls whether x.use does a clone or a move UseCloned rather than Use. This is because the trait does not control whether or not you can use something but rather controls what happens when you do.
  • Question was raised on Zulip as to whether x.use should auto-deref. After thinking it over, reached the conclusion that it should not, because x and x.use should eventually behave the same modulo lints, but that (as ever) a &T -> T coercion would be useful for ergonomic reasons.
Expose experimental LLVM features for GPU offloading
1 detailed update available.

Comment by @ZuseZ4 posted on 2025-03-25:

I just noticed that I missed my February update, so I'll keep this update a bit more high-level, to not make it too long.

Key developments:

  1. All key autodiff PRs got merged. So after building rust-lang/rust with the autodiff feature enabled, users can now use it, without the need for any custom fork.
  2. std::autodiff received the first PRs from new contributors, which have not been previously involved in rustc development! My plan is to grow a team to maintain this feature, so that's a great start. The PRs are here, here and here. Over time I hope to hand over increasingly larger issues.
  3. I received an offer to join the Rust compiler team, so now I can also officially review and approve PRs! For now I'll focus on reviewing PRs in the fields I'm most comfortable with, so autodiff, batching, and soon GPU offload.
  4. I implemented a standalone batching feature. It was a bit larger (~2k LoC) and needed some (back then unmerged) autodiff PRs, since they both use the same underlying Enzyme infrastructure. I therefore did not push for merging it.
  5. I recently implemented batching as part of the autodiff macro, for people who want to use both together. I subsequently split out a first set of code improvements and refactorings, which already got merged. The remaining autodiff feature PR is only 600 loc, so I'm currently cleaning it up for review.
  6. I spend time preparing an MCP to enable autodiff in CI (and therefore nightly). I also spend a lot of time discussing a potential MLIR backend for rustc. Please reach out if you want to be involved!

**Help wanted: ** We want to support autodiff in lib builds, instead of only binaries. oli-obk and I recently figured out the underlying bug, and I started with a PR in https://github.com/rust-lang/rust/pull/137570. The problem is that autodiff assumes fat-lto builds, but lib builds compile some of the library code using thin-lto, even if users specify lto=fat in their Cargo.toml. We'd want to move every thing to fat-lto if we enable Autodiff as a temporary solution, and later move towards embed-bc as a longer-term solution. If you have some time to help please reach out! Some of us have already looked into it a little but got side-tracked, so it's better to talk first about which code to re-use, rather than starting from scratch.

I also booked my RustWeek ticket, so I'm happy to talk about all types of Scientific Computing, HPC, ML, or cursed Rust(c) and LLVM internals! Please feel free to dm me if you're also going and want to meet.

Extend pubgrub to match cargo's dependency resolution
1 detailed update available.

Comment by @Eh2406 posted on 2025-03-14:

Progress continues to be stalled by high priority tasks for $DAY_JOB. It continues to be unclear when the demands of work will allow me to return focus to this project.

Externally Implementable Items
No detailed updates available.
Finish the libtest json output experiment
1 detailed update available.

Comment by @epage posted on 2025-03-17:

  • Key developments:
    • Between tasks on #92, I've started to refresh myself on the libtest-next code base
  • Blockers:
  • Help wanted:
Implement Open API Namespace Support
No detailed updates available.
Implement restrictions, prepare for stabilization
No detailed updates available.
Improve state machine codegen

We've started work on implementing #[loop_match] on this branch. For the time being integer and enum patterns are supported. The benchmarks, are extremely encouraging, showing large improvements over the status quo, and significant improvements versus -Cllvm-args=-enable-dfa-jump-thread.

Our next steps can be found in the todo file, and focus mostly on improving the code quality and robustness.

3 detailed updates available.

Comment by @folkertdev posted on 2025-03-18:

@traviscross how would we make progress on that? So far we've mostly been talking to @joshtriplett, under the assumption that a #[loop_match] attribute on loops combined with a #[const_continue] attribute on "jumps to the next iteration" will be acceptable as a language experiment.

Our current implementation handles the following

#![feature(loop_match)]

enum State {
    A,
    B,
}

fn main() {
    let mut state = State::A;
    #[loop_match]
    'outer: loop {
        state = 'blk: {
            match state {
                State::A =>
                {
                    #[const_continue]
                    break 'blk State::B
                }
                State::B => break 'outer,
            }
        }
    }
}

Crucially, this does not add syntax, only the attributes and internal logic in MIR lowering for statically performing the pattern match to pick the right branch to jump to.

The main challenge is then to implement this in the compiler itself, which we've been working on (I'll post our tl;dr update shortly)

Comment by @folkertdev posted on 2025-03-18:

Some benchmarks (as of march 18th)

A benchmark of https://github.com/bjorn3/comrak/blob/loop_match_attr/autolink_email.rs, basically a big state machine that is a perfect fit for loop match

Benchmark 1: ./autolink_email
  Time (mean ± σ):      1.126 s ±  0.012 s    [User: 1.126 s, System: 0.000 s]
  Range (min … max):    1.105 s …  1.141 s    10 runs
 
Benchmark 2: ./autolink_email_llvm_dfa
  Time (mean ± σ):     583.9 ms ±   6.9 ms    [User: 581.8 ms, System: 2.0 ms]
  Range (min … max):   575.4 ms … 591.3 ms    10 runs
 
Benchmark 3: ./autolink_email_loop_match
  Time (mean ± σ):     411.4 ms ±   8.8 ms    [User: 410.1 ms, System: 1.3 ms]
  Range (min … max):   403.2 ms … 430.4 ms    10 runs
 
Summary
  ./autolink_email_loop_match ran
    1.42 ± 0.03 times faster than ./autolink_email_llvm_dfa
    2.74 ± 0.07 times faster than ./autolink_email

#[loop_match] beats the status quo, but also beats the llvm flag by a large margin.

A benchmark of zlib decompression with chunks of 16 bytes (this makes the impact of loop_match more visible)

Benchmark 1 (65 runs): target/release/examples/uncompress-baseline rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          77.7ms ± 3.04ms    74.6ms … 88.9ms          9 (14%)        0%
  peak_rss           24.1MB ± 64.6KB    24.0MB … 24.2MB          0 ( 0%)        0%
  cpu_cycles          303M  ± 11.8M      293M  …  348M           9 (14%)        0%
  instructions        833M  ±  266       833M  …  833M           0 ( 0%)        0%
  cache_references   3.62M  ±  310K     3.19M  … 4.93M           1 ( 2%)        0%
  cache_misses        209K  ± 34.2K      143K  …  325K           1 ( 2%)        0%
  branch_misses      4.09M  ± 10.0K     4.08M  … 4.13M           5 ( 8%)        0%
Benchmark 2 (68 runs): target/release/examples/uncompress-llvm-dfa rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          74.0ms ± 3.24ms    70.6ms … 85.0ms          4 ( 6%)        🚀-  4.8% ±  1.4%
  peak_rss           24.1MB ± 27.1KB    24.0MB … 24.1MB          3 ( 4%)          -  0.1% ±  0.1%
  cpu_cycles          287M  ± 12.7M      277M  …  330M           4 ( 6%)        🚀-  5.4% ±  1.4%
  instructions        797M  ±  235       797M  …  797M           0 ( 0%)        🚀-  4.3% ±  0.0%
  cache_references   3.56M  ±  439K     3.08M  … 5.93M           2 ( 3%)          -  1.8% ±  3.6%
  cache_misses        144K  ± 32.5K     83.7K  …  249K           2 ( 3%)        🚀- 31.2% ±  5.4%
  branch_misses      4.09M  ± 9.62K     4.07M  … 4.12M           1 ( 1%)          -  0.1% ±  0.1%
Benchmark 3 (70 runs): target/release/examples/uncompress-loop-match rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          71.6ms ± 2.43ms    69.3ms … 78.8ms          6 ( 9%)        🚀-  7.8% ±  1.2%
  peak_rss           24.1MB ± 72.8KB    23.9MB … 24.2MB         20 (29%)          -  0.0% ±  0.1%
  cpu_cycles          278M  ± 9.59M      270M  …  305M           7 (10%)        🚀-  8.5% ±  1.2%
  instructions        779M  ±  277       779M  …  779M           0 ( 0%)        🚀-  6.6% ±  0.0%
  cache_references   3.49M  ±  270K     3.15M  … 4.17M           4 ( 6%)        🚀-  3.8% ±  2.7%
  cache_misses        142K  ± 25.6K     86.0K  …  197K           0 ( 0%)        🚀- 32.0% ±  4.8%
  branch_misses      4.09M  ± 7.83K     4.08M  … 4.12M           1 ( 1%)          +  0.0% ±  0.1%
Benchmark 4 (69 runs): target/release/examples/uncompress-llvm-dfa-loop-match rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          72.8ms ± 2.57ms    69.7ms … 80.0ms          7 (10%)        🚀-  6.3% ±  1.2%
  peak_rss           24.1MB ± 35.1KB    23.9MB … 24.1MB          2 ( 3%)          -  0.1% ±  0.1%
  cpu_cycles          281M  ± 10.1M      269M  …  312M           5 ( 7%)        🚀-  7.5% ±  1.2%
  instructions        778M  ±  243       778M  …  778M           0 ( 0%)        🚀-  6.7% ±  0.0%
  cache_references   3.45M  ±  277K     2.95M  … 4.14M           0 ( 0%)        🚀-  4.7% ±  2.7%
  cache_misses        176K  ± 43.4K      106K  …  301K           0 ( 0%)        🚀- 15.8% ±  6.3%
  branch_misses      4.16M  ± 96.0K     4.08M  … 4.37M           0 ( 0%)        💩+  1.7% ±  0.6%

The important points: loop-match is faster than llfm-dfa, and when combined performance is worse than when using loop-match on its own.

Comment by @traviscross posted on 2025-03-18:

Thanks for that update. Have reached out separately.

Instrument the Rust standard library with safety contracts
1 detailed update available.

Comment by @celinval posted on 2025-03-17:

We have been able to merge the initial support for contracts in the Rust compiler under the contracts unstable feature. @tautschnig has created the first PR to incorporate contracts in the standard library and uncovered a few limitations that we've been working on.

Making compiletest more maintainable: reworking directive handling
1 detailed update available.

Comment by @jieyouxu posted on 2025-03-15:

Update (2025-03-15):

  • Doing a survey pass on compiletest to make sure I have the full picture.
Metrics Initiative
1 detailed update available.

Comment by @yaahc posted on 2025-03-03:

After further review I've decided to limit scope initially and not get ahead of myself so I can make sure the schemas I'm working with can support the kind of queries and charts we're going to eventually want in the final version of the unstable feature usage metric. I'm hoping that by limiting scope I can have most of the items currently outlined in this project goal done ahead of schedule so I can move onto building the proper foundations based on the proof of concept and start to design more permanent components. As such I've opted for the following:

  • minimal change to the current JSON format I need, which is including the timestamp
  • Gain clarity on exactly what questions I should be answering with the unstable feature usage metrics, the desired graphs and tables, and how this influences what information I need to gather and how to construct the appropriate queries within graphana
  • gathering a sample dataset from docs.rs rather than viewing it as the long term integration, since there are definitely some sampleset bias issues in that dataset from initial conversations with docs.rs
    • Figure out proper hash/id to use in the metrics file names to avoid collisions with different conditional compilation variants of the same crate with different feature enabled.

For the second item above I need to have more detailed conversations with both @rust-lang/libs-api and @rust-lang/lang

Model coherence in a-mir-formality
1 detailed update available.

Comment by @nikomatsakis posted on 2025-03-17:

Update:

@tiif has been working on integrating const-generic effects into a-mir-formality and making good progress.

I have begun exploring integration of the MiniRust definition of MIR. This doesn't directly work towards the goal of modeling coherence but it will be needed for const generic work to be effective.

I am considering some simplification and cleanup work as well.

Next-generation trait solver
1 detailed update available.

Comment by @lcnr posted on 2025-03-17:

The two cycle handling PRs mentioned in the previous update have been merged, allowing nalgebra to compile with the new solver enabled. I have now started to work on opaque types in borrowck again. This is a quite involved issue and will likely take a few more weeks until it's fully implemented.

Nightly support for ergonomic SIMD multiversioning
1 detailed update available.

Comment by @veluca93 posted on 2025-03-17:

Key developments: Started investigating how the proposed SIMD multiversioning options might fit in the context of the efforts for formalizing a Rust effect system

Null and enum-discriminant runtime checks in debug builds
No detailed updates available.
Optimizing Clippy & linting
1 detailed update available.

Comment by @blyxyas posted on 2025-03-17:

Monthly update!

  • https://github.com/rust-lang/rust-clippy/issues/13821 has been merged. This has successfully optimized the MSRV extraction from the source code.

On the old MSRV extraction,Symbol::intern use was sky high being about 3.5 times higher than the rest of the compilation combined. Now, it's at normal levels. Note that Symbol::intern is a very expensive and locking function, so this is very notable. Thanks to @Alexendoo for this incredible work!

As a general note on the month, I'd say that we've experimented a lot.

  • Starting efforts on parallelizing the lint system.
  • https://github.com/rust-lang/rust-clippy/issues/14423 Started taking a deeper look into our dependence on libLLVM.so and heavy relocation problems.
  • I took a look into heap allocation optimization, seems that we are fine. For the moment, rust-clippy#14423 is the priority.
Prepare const traits for stabilization
1 detailed update available.

Comment by @oli-obk posted on 2025-03-20:

I opened an RFC (https://github.com/rust-lang/rfcs/pull/3762) and we had a lang team meeting about it. Some design exploration and bikeshedding later we have settled on using (const)instead of ~const along with some more annotations for explicitness and some fewer annotations in other places. The RFC has been updated accordingly. There is still ongoing discussions about reintroducing the "fewer annotations" for redundancy and easier processing by humans.

Prototype a new set of Cargo "plumbing" commands
No detailed updates available.
Publish first rust-lang-owned release of "FLS"
2 detailed updates available.

Comment by @JoelMarcey posted on 2025-03-14:

Key Developments: Working on a public announcement of Ferrous' contribution of the FLS. Goal is to have that released soon. Also working out the technical details of the contribution, particularly around how to initially integrate the FLS into the Project itself.

Blockers: None yet.

Comment by @JoelMarcey posted on 2025-04-01:

Key Developments: Public announcement of the FLS donation to the Rust Project.

Blockers: None

Publish first version of StableMIR on crates.io
2 detailed updates available.

Comment by @celinval posted on 2025-03-20:

We have proposed a project idea to Google Summer of Code to implement the refactoring and infrastructure improvements needed for this project. I'm working on breaking down the work into smaller tasks so they can be implemented incrementally.

Comment by @celinval posted on 2025-03-20:

I am also happy to share that @makai410 is joining us in this effort! 🥳

Research: How to achieve safety when linking separately compiled code
No detailed updates available.
Run the 2025H1 project goal program
2 detailed updates available.

Comment by @nikomatsakis posted on 2025-03-03:

Update: February goal update has been posted. We made significant revisions to the way that goal updates are prepared. If you are a goal owner, it's worth reading the directions for how to report your status, especially the part about help wanted and summary comments.

Comment by @nikomatsakis posted on 2025-03-17:

Update: We sent out the first round of pings for the March update. The plan is to create the document on March 25th, so @rust-lang/goal-owners please get your updates in by then. Note that you can create a TL;DR comment if you want to add 2-3 bullet points that will be embedded directly into the final blog post.

In terms of goal planning:

  • @nandsh is planning to do a detailed retrospective on the goals program in conjunction with her research at CMU. Please reach out to her on Zulip (Nandini) if you are interested in participating.
  • We are planning to overhaul the ping process as described in this hackmd. In short, pings will come on the 2nd/3rd Monday of the month. No pings will be sent if you've posted a comment that month. The blog post will be prepared on the 3rd Friday.
  • We've been discussing how to structure 2025H2 goals and are thinking of making a few changes. We'll break out three categories of goals (Flagship / Core / Stretch), with "Core" goals being those deemed most important. We'll also have a 'pre-read' before the RFC opens with team leads to look for cross-team collaborative opportunities. At least that's the current plan.
Rust Vision Document
1 detailed update available.

Comment by @nikomatsakis posted on 2025-03-17:

Update:

I've asked @jackh726 to co-lead the team with me. Together we pulled together a Rust Vision Doc action plan.

The plan begins by posting a blog post (draft available here) announcing the effort. We are coordinating with the Foundation to create a survey which will be linked from the blog post. The survey questions ask about user's experience but also look for volunteers we can speak with.

We are pulling together the team that will perform the interviewing. We've been in touch with UX reseearchers who will brief us on some of the basics of UX research. We're finalizing team membership now plus the set of focus areas, we expect to cover at least users/companies, Rust project maintainers, and Rust global communities. See the Rust Vision Doc action plan for more details.

rustc-perf improvements
1 detailed update available.

Comment by @davidtwco posted on 2025-03-03:

A small update, @Jamesbarford aligned with @kobzol on a high-level architecture and will begin fleshing out the details and making some small patches to rustc-perf to gain familiarity with the codebase.

Scalable Polonius support on nightly
1 detailed update available.

Comment by @lqd posted on 2025-03-24:

Here are the key developments for this update.

Amanda has continued on the placeholder removal task. In particular on the remaining issues with rewritten type tests. The in-progress work caused incorrect errors to be emitted under the rewrite scheme, and a new strategy to handle these was discussed. This has been implemented in the PR, and seems to work as hoped. So the PR should now be in a state that is ready for more in-depth review pass, and should hopefully land soon.

Tage has started his master's thesis with a focus on the earliest parts of the borrow checking process, in order to experiment with graded borrow-checking, incrementalism, avoiding work that's not needed for loans that are not invalidated, and so on. A lot of great progress has been made on these parts already, and more are being discussed even in the later areas (live and active loans).

I have focused on taking care of the remaining diagnostics and test failures of the location-sensitive analysis. For diagnostics in particular, the PRs mentioned in the previous updates have landed, and I've fixed a handful of NLL spans, all the remaining differences under the compare-mode, and blessed differences that were improvements. For the test failures, handling liveness differently in traversal fixed most of the remaining failures, while a couple are due to the friction with mid-points avoidance scheme. For these, we have a few different paths forward, but with different trade-offs and we'll be discussing and evaluation these in the very near future. Another two are still left to analyze in-depth to see what's going on.

Our near future focus will be to continue down the path to correctness while also expanding test coverage that feels lacking in certain very niche areas, and that we want to improve. At the same time, we'll also work on a figuring out a better architecture to streamline the entire end-to-end process, to allow early outs, avoid work that is not needed, etc.

Secure quorum-based cryptographic verification and mirroring for crates.io
No detailed updates available.
Stabilize cargo-script
1 detailed update available.

Comment by @lqd posted on 2025-03-26:

This project goal was actually carried over from 2024h2, in https://github.com/rust-lang/rust-project-goals/pull/294

SVE and SME on AArch64
2 detailed updates available.

Comment by @davidtwco posted on 2025-03-03:

A small update, we've opened a draft PR for the initial implementation of this - rust-lang/rust#137944. Otherwise, just continued to address feedback on the RFCs.

Comment by @davidtwco posted on 2025-03-18:

  • We've been resolving review feedback on the implementation of the Sized Hierarchy RFC on rust-lang/rust#137944. We're also working on reducing the performance regression in the PR, by avoiding unnecessary elaboration of sizedness supertraits and extending the existing Sized case in type_op_prove_predicate query's fast path.
  • There's not been any changes to the RFC, there's minor feedback that has yet to be responded to, but it's otherwise just waiting on t-lang.
  • We've been experimenting with rebasing rust-lang/rust#118917 on top of rust-lang/rust#137944 to confirm that const sizedness allows us to remove the type system exceptions that the SVE implementation previously relied on. We're happy to confirm that it does.
Unsafe Fields
No detailed updates available.
Use annotate-snippets for rustc diagnostic output
1 detailed update available.

Comment by @Muscraft posted on 2025-03-31:

While my time was limited these past few months, lots of progress was made! I was able to align annotate-snippets internals with rustc's HumanEmitter and get the new API implemented. These changes have not been merged yet, but they can be found here. As part of this work, I got rustc using annotate-snippets as its only renderer. During all of this, I started working on making rustc use annotate-snippets as its only renderer, which turned out to be a huge benefit. I was able to get a feel for the new API while addressing rendering divergences. As of the time of writing, all but ~30 tests of the roughly 18,000 UI tests are passing.

test result: FAILED. 18432 passed; 29 failed; 193 ignored; 0 measured; 0 filtered out; finished in 102.32s

Most of the failing tests are caused by a few things:

  • annotate-snippets right aligns numbers, whereas rustc left aligns
  • annotate-snippets doesn't handle multiple suggestions for the same span very well
  • Problems with handling FailureNote
  • annotate-snippets doesn't currently support colored labels and titles, i.e., the magenta highlight rustc uses
  • rustc wants to pass titles similar to error: internal compiler error[E0080], but annotate-snippets doesn't support that well
  • differences in how rustc and annotate-snippets handle term width during tests
    • When testing, rustc uses DEFAULT_COLUMN_WIDTH and does not subtract the code offset, while annotate-snippets does
  • Slight differences in how "newline"/end of line highlighting is handled
  • JSON output rendering contains color escapes

08 Apr 2025 12:00am GMT

07 Apr 2025

feedPlanet Mozilla

Frederik Braun: With Carrots & Sticks - Can the browser handle web security?

NB: This is the blog version of my keynote from Measurements, Attacks, and Defenses for the Web (MADWeb) 2025, earlier this year. It was not recorded.

In my keynote, I examined web security through the browser's perspective. Various browser features have helped fix transport security issues and increase HTTPS adoption …

07 Apr 2025 10:00pm GMT