Usability Improvements in GCC 15

How so? I'd really like to see an example. If you can't explain what requirements your function has before calling it then how do you know it even does what you expect?

There were lots of politics evolved, moreso than technical issues.

While not perfect concepts lite, alongside compile time evaluation do the job.

The difference is that uBlock Origin is an extension you intentionally trust and install, while the JS API we talk about are something any websites (untrusted) can use.

To be fair, uBlock Origin has always been a special case. It's so good and so important and so trusted that it should have access to browser internals that normal extensions can't access.

Honestly, uBlock Origin shouldn't be an extension to begin with, it should be a literally built in feature of all browsers. Only reason it's not is we can't trust ad companies to maintain an ad blocker.

Perhaps the users should be given an option to opt out (enabled by default) for such APIs on a per-site basis. That way, users can intervene when they're abused, while their fair use will remain transparent.

How is uBlock Origin "doomed" ?

Redirects are used for stuff like POST->GET or canonicalizing URLs (adding slashes on directories), would you get rid of that too?

Like I said: I recognize there are legitimate uses. But unfortunately, they are majorly outnumbered by people doing things like overwriting my history so that when I hit "back", it stays on the site instead of going back to my search engine. I would love to live in the world where malicious dark patterns didn't exist, and we could have nice things. But we don't, and so I would rather not have the functionality at all.

How about we just navigate to new pages by .. navigating to new pages? Browsers have perfectly functional history without javascript shenanigans

true

I actually quite like the emojis they put in the output, it helps alleviate the balance of providing enough context while also giving a clear visual indicator for the actual error message.

They aren't going overboard on it, they just put a warning emoji in front of the error message.

> More importantly, the "competition" between GCC and clang/LLVM is mutually beneficial. GCC losing prominence would not be good for LLVM long-term, just as GCC arguably languished in the period after the egcs merger.

You're right to note that "competition" here is more like inspiration than a deathmatch. But I vaguely remember two things that seem similar to motivation via competitive pressure to me: (1) when GCC 5 came out, it had way nicer error messages, and I immediately thought "Oh, they wanted to make GCC nice like Clang" and (2) IIRC the availability of a more modular compiler stack like LLVM/Clang essentially neutralized Stallman's old strategic argument against more a more pluggable design, right?

ld.lld works with any compiler, and anyway, mold is even faster and also works with any compiler.

Embedded compiler vendors and UNIXes want a possibly slightly patched C or C++ compiler, maybe with an extra back-end bolted on. I'm talking about use-cases like Rust and Zig and Swift, projects which want a solid optimizing back-end but their own front-end and tooling.

What exactly do you mean by "UNIX"? Commercial UNIX vendors other than Apple have basically a rounding error from 0% of market share.

Apple, Arm, OpenBSD, FreeBSD have all switched to Clang.

It's not like GCC or the embedded toolchains are a shining beacon of ISO compliance... and if you mean video game consoles, are any of them using GCC today? Sony and Nintendo are both LLVM and Microsoft is Microsoft

I believe clang has worked for years now.

https://static.lwn.net/kerneldoc/kbuild/llvm.html

I do remember reading about LTO not working properly, you're either unable to link the kernel with LTO, or get a buggy binary which crashes at runtime. Doesn't look like much effort has been put into solving it, maybe it's just too large a task.

There are a few distros that use Clang as the system compiler (SerpentOS and Chimera Linux for two).

libgccjit is, despite its name, just another front-end for GIMPLE. The JIT-part is realized through compiling the object file to a shared library and using dlopen on this.

One big problem with libgccjit, despite its fairly bad compile-time performance, is that it's GPL-licensed and thereby makes the entire application GPL, which makes it impossible to use not just in proprietary use-cases but also in cases where incompatible licenses are involved.

I think that's an unreasonable lens for viewing his work. Of course he values purity over practicality. That's his entire platform. His decision making process always prioritizes supporting Free Software over proprietary efforts, pragmatism be damned.

Expecting Stallman to make life easier for commercial vendors is like expecting PETA to recommend a good foie gras farm. That's not what they do.

Don't forget that the LLVM folks actually went to GNU and offered it to them, and they failed to pay attention and respond. (It's not even that they responded negatively; they just dropped it on the floor completely.) There's an alternate history where LLVM was a GNU project.

With the benefit of hindsight, I'm glad that that didn't happen, even though I have mixed feelings about LLVM being permissively licensed.

Without GNU, GPL and Richard Stallman, FOSS would not exist in the first place. The GPL forced companies to make FOSS a thing, whether they liked it or not.

Kind like how GPL 3 makes it infeasible for most companies to use/support free software. At least Stallman gets to feel morally superior though

Indeed. Emoji are just characters, rendered via some font just like any text character. On non-Apple operating systems, you can select emoji sets via font configuration.

You can do it on macOS as well, but you have to disable SIP and modify/replace the files for the Apple Color Emoji font, because some widely used GUI libs are hardcoded to use it.

Idr the situation on Windows except that emoji glyphs are inherited from your other font choices, if your chosen font includes emoji. But on Linux it's generally easy to configure certain font substitutions only for some groups of characters, like emoji.

You can already put multi-column-wide non-ASCII characters in your source code, so the horse has left the barn already.

They are quite easy to search for actually, because they are sparse and you tend to not get so many spurious results due hitting things that contain your query as a substring. Even then, the glyphs appear inline in the warning message, they are not the anchor, you could still just search for "warning:" like you or your editor have been doing for years. Every operating system comes with an emoji picker, it takes like 2 seconds to use. I'm not sympathetic, tbqh.

If anything, an emoji is easier to search for, as less things would be using it than a general "warning" (or whatever would make sense, as the emoji'd thing isn't the warning itself). Do have to get a copy from somewhere to search for though. It's also much easier to "visually" search for it.

At least in the blog there are a two spaces after the emoji so it can freely draw past its boundaries rightwards without colliding with anything for a good bit; and nothing to its right is used assuming monospace alignment. So at worst you just get a half-emoji.

> I want emojis in my code.

Then you will enjoy swift [1]!

[1] Emoji driven development: https://www.swiftbysundell.com/special/emoji-driven-developm...