[HN Gopher] Usability Improvements in GCC 15
___________________________________________________________________
Usability Improvements in GCC 15
Author : dmalcolm
Score : 188 points
Date : 2025-04-10 14:03 UTC (8 hours ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| Night_Thastus wrote:
| I'm all up for better error messaging. :)
|
| Can't use Clang where I'm at, but I _do_ get to use fairly
| cutting-edge GCC, at least for Windows development. So I may get
| to see these improvements once they drop into MSYS.
| meisel wrote:
| The template error messages look great. I wonder if it's worth
| writing a translator from clang/gcc messages to these ones, for
| users of clang and older gcc (to pipe one's error messages to)
| charcircuit wrote:
| I mean why not show a proper image instead of doing fancier
| ASCII art. Or skip it entirely and have an LLM describe the
| issues and fix it for you.
| jmclnx wrote:
| I hope gcc remains the default in Linux due to the GPL. But I
| expect someday clang will become the default.
|
| Plus I heard COBOL was merged in with the compiler collection,
| nice!
| mort96 wrote:
| GCC can honestly only blame itself for its inevitable
| increasing obsolescence. LLVM only has the attention it has
| because it can be used as a building block in other compilers.
| GCC could've made a tool and library which accepts IR, performs
| optimizations and emits machine code, but the project avoided
| that for ideological reasons, and as a result created a void in
| the ecosystem for a project like LLVM.
| Tpt wrote:
| There is now libgccjit that aims at allowing to embed gcc
| https://gcc.gnu.org/onlinedocs/jit/
|
| There is an alternative backend to rustc that relies on it.
| aengelke wrote:
| 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.
| pjmlp wrote:
| The embedded compiler vendors, UNIX and consoles are quite
| happy with it.
|
| How much do you think they contribute back upstream regarding
| ISO compliance outside LLVM backend for their hardware and
| OS?
| mort96 wrote:
| 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.
| pjmlp wrote:
| And FOSS folks most likely would like to enjoy those
| patches as well on their installations.
| umanwizard wrote:
| And they do! You _can_ choose not to contribute your
| changes back to permissively-licensed software, but in
| actual practice most people do contribute them. It 's not
| like the Rust compiler is proprietary software with their
| own closed-source fork of LLVM...
| trelane wrote:
| > You can choose not to contribute your changes back to
| permissively-licensed software, but in actual practice
| most people do contribute them.
|
| They contribute _some_ things, sure. But the also _don
| 't_ contribute some things. It is hard to know how much
| because it's kept secret from all of us, even their own
| customers.
|
| > "It's not like the Rust compiler is proprietary
| software with their own closed-source fork of LLVM..."
|
| Rust no, hut there are a _lot_ of proprietary, semi-
| incompatible proprietary forks out there.
| mort96 wrote:
| I haven't advocated for re-licensing GCC to be
| permissively licensed. And patching GCC is necessarily
| going to be much easier for vendors than to build a new C
| front-end which generates GCC IR. So I'm not sure what
| difference you think what I'm proposing would make with
| regard to your concerns.
| vbezhenar wrote:
| gccrs is a rust implementation for gcc. Just because Rust
| developers don't want their users to be fully free
| doesn't mean there are any problems with gcc. And clang
| is developed by Apple which is a huge warning sign by
| itself.
| bigstrat2003 wrote:
| Rust developers don't "not want their users to be fully
| free", they disagree with you on which license is best.
| Don't deliberately phrase people's motivations in an
| uncharitable way, it's obnoxious as hell.
| mort96 wrote:
| And gccrs is not really very widely used and is not the
| "official" Rust compiler. The Rust project chose to base
| their compiler on LLVM, for good technical reasons.
| That's bad news for the GCC project.
| tmiku wrote:
| I thought that most FOSS projects took multiple compiler
| implementations as a sign of a healthy language
| environment, without much prestige associated with being
| the "premier" compiler and instead having more of an it-
| takes-a-village attitude. Granted, I'm mostly
| extrapolating from Go and Python here - is it a sharper
| divide in the Rust community?
| viraptor wrote:
| It's an early implementation of a part of rust. It's not
| even close to being able to use as the daily compiler.
| duped wrote:
| 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
| pjmlp wrote:
| The difference being that vendors forks not compliant
| with GPL can be legally asked for the changes they
| haven't sent upstream.
| bluGill wrote:
| Venders who use llvm quickly discover the cost of
| mainaining their own fork is too high and end up
| contributing back.
| pjmlp wrote:
| The point was the whole clang package, and no they don't,
| plenty of examples.
| duped wrote:
| With LLVM they don't need to fork it in the first place.
| But still, it doesn't matter because ISO compliance is a
| frontend problem.
|
| The one vendor who forks LLVM and doesn't contribute
| their biggest patches back is Apple, and if you want
| bleeding edge or compliance you're not using Apple Clang
| at all.
|
| If you say "isn't it great vendor toolchains have to
| contribute back to upstream?" I'm going to say "no, it
| sucks that vendor toolchains have to exist"
| mort96 wrote:
| Forcing vendors to contribute back upstream is an attempt
| at making vendor toolchains not exist.
|
| If a company makes a new MCU with some exciting new
| instruction set, they need to make a compiler available
| which supports that instruction set and make that
| compiler available to their customers.
|
| With LLVM as the base, the vendor could make their
| toolchain proprietary, making it _impossible_ to
| integrate it back into LLVM, which means the vendor
| toolchain will exist until the ISA gets wide-spread
| enough for volunteers to invest the time required to make
| a separate production-quality LLVM back-end from scratch.
|
| With GCC as the base, the vendor must at least make their
| GCC fork available to their customers under the GPL.
| This, in theory, allows the GCC community to "just"
| integrate the back-end developed by the vendor into GCC
| rather than starting from scratch.
|
| Now I don't know how effective this is, or how much it
| happens in practice that the GCC project integrates back-
| ends from vendor toolchains. But in principle, it's great
| that vendors have to make their toolchains FOSS _because_
| it reduces the need for vendor toolchains.
| pjmlp wrote:
| So are you aware how many contributions have actually
| been upstream by Sony, Nintendo, IBM, ARM, Green Hills,
| Codegear, TI, Microchip, Codeplay, NVidia, AMD, Intel,
| HP,.... ?
|
| Because Apple certainly isn't alone.
| trelane wrote:
| The question is less what's upstream than what's _not._
| uecker wrote:
| GCC has very good ISO compliance and ISO C23 is better
| supported than in Clang (which I expect to catch up soon
| though)
| bobmcnamara wrote:
| Apple, Arm, OpenBSD, FreeBSD have all switched to Clang.
| pjmlp wrote:
| Swichting wasn't the point.
| johnisgood wrote:
| Why did OpenBSD switch to clang? Licensing issues?
| umanwizard wrote:
| What exactly do you mean by "UNIX"? Commercial UNIX vendors
| other than Apple have basically a rounding error from 0% of
| market share.
| anthk wrote:
| Are you from 2001? Sorry, but Apple at servers' market
| it's non-existent. RH and Canonical make tons of money
| thanks to being THE platform of the ubiquituous internet.
| Support is not free.
| mort96 wrote:
| Are you calling Linux a UNIX? I mean GNU/Linux is
| certainly a UNIX-like system, but aren't "UNIXes"
| typically used to refer to operating systems which stem
| from AT&T's UNIX, such as the BSDs and Solaris and HP-UX
| and the like? GNU's Not UNIX after all
| johnisgood wrote:
| I have fond memories associated with OpenSolaris. Oracle
| ruined it.
|
| I have not tried OpenIndiana, however.
| anthk wrote:
| GNU isn't Unix as NT isn't Win32.
|
| Gnu promotes Unix, but also promotes Emacs on top. NT can
| run Win32 on top of it, but there's far more than Win32
| with NT systems. Just get ReactOS and open the NT object
| explorer under explorer.exe.
|
| Far more advanced than Windows 95/98.
| umanwizard wrote:
| Gnu/Linux and UNIX are not the same thing. Yes I
| understand that RHEL and Ubuntu are popular.
| pjmlp wrote:
| Yet IBM, Oracle, HP and POSIX RTOS vendors keep enough
| customers happy with that rouding error.
| dralley wrote:
| Yet another reason why I'm not a fan of Richard Stallman.
|
| Most of the decisions he made over the past 25 years have
| been self-defeating and led directly to the decline of the
| influence of his own movement. It's not that "the GCC
| project" avoided that for ideological reason, Stallman was
| personally a veto on that issue for years, and his personal
| objection led to several people quitting the project for
| LLVM, with a couple saying as much directly to him.
|
| https://gcc.gnu.org/legacy-ml/gcc/2014-01/msg00247.html
|
| https://lists.gnu.org/archive/html/emacs-
| devel/2015-01/msg00...
|
| (both threads are interesting reading in their entirety, not
| just those specific emails)
| knowknow wrote:
| 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
| dralley wrote:
| And Free Software does not benefit from a morass of
| mutually-incompatible copyleft licenses that may as well
| have been proprietary since you can't use them together.
|
| None of the permissive licenses have this problem.
| gkbrk wrote:
| Which open-source licenses can't be used together?
| dralley wrote:
| GPLv2 and GPLv3, for one example... It's sad when two
| licenses from the same organization are incompatible.
|
| GPLv2 and Apache.
| teddyh wrote:
| The number of significant software projects which are
| licensed as GPLv2- _only_ , and which are therefore
| incompatible with GPLv3, can probably be counted on one
| hand. _Normal_ GPLv2 projects are licensed - as
| instructed by the text in the license itself - as "GPLv2
| _or later_ ". Which means that any normal GPLv2-licensed
| software can be relicensed to GPLv3, and can therefore be
| combined with any other GPLv3-licensed program without
| any issue whatsoever.
| gus_massa wrote:
| For GPL v2 only, let's start the list with Linux and
| Git...
|
| The "or later" has been used in creative ways, like
| relicencing all the Wikipedia content, or the Affero to
| AGPL transition. Nothing shady, but unexpected.
|
| Do you trust RMS to avoid doing shady things in the later
| GPL licence? I do, but he is not longer in the FSF.
|
| Do you trust the current members of the FSF to avoid
| doing shady things in the later GPL licence? I don't know
| them.
|
| Do you trust the future members of the FSF to avoid doing
| shady things in the later GPL licence???
| CorrectHorseBat wrote:
| >Do you trust RMS to avoid doing shady things in the
| later GPL licence? I do, but he is not longer in the FSF.
|
| Yes he is: https://www.fsf.org/about/staff-and-board
| ndiddy wrote:
| Section 14 of the GPL says "The Free Software Foundation
| may publish revised and/or new versions of the GNU
| General Public License from time to time. Such new
| versions will be similar in spirit to the present
| version, but may differ in detail to address new problems
| or concerns." Given that the preamble to the GPL
| explicitly says "the GNU General Public License is
| intended to guarantee your freedom to share and change
| all versions of a program--to make sure it remains free
| software for all its users", I don't think that a judge
| would find that a hypothetical GPLv4 that was basically
| MIT or something is "similar in spirit" to the present
| version.
|
| If you're worried about the other direction (i.e. a
| hypothetical GPLv4 that had some bizarre restriction like
| "all users must donate to the FSF"), the "or any later
| version" means that as long as you don't decide to update
| the license you use yourself, people can continue to use
| it under the GPLv2 or v3 indefinitely.
| raverbashing wrote:
| Honestly at least Linus has his head in the right place
| kstrauser wrote:
| 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.
| dralley wrote:
| >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.
|
| He threw open-source developers under the bus in the
| process. As a result approximately nobody writes GCC
| plugins, open source or otherwise.
| kstrauser wrote:
| Alternatively, if you join a Stallman-led Free Software
| project and hope he'll accept your ideas for making life
| easier for proprietary vendors, you're gonna have a bad
| time. I mean, the GNU Emacs FAQ for MS Windows (https://w
| ww.gnu.org/software/emacs/manual/html_mono/efaq-w32...)
| says:
|
| > It is not our goal to "help Windows users" by making
| text editing on Windows more convenient. We aim to
| replace proprietary software, not to enhance it. So why
| support GNU Emacs on Windows?
|
| > We hope that the experience of using GNU Emacs on
| Windows will give programmers a taste of freedom, and
| that this will later inspire them to move to a free
| operating system such as GNU/Linux. That is the main
| valid reason to support free applications on nonfree
| operating systems.
|
| RMS has been exceedingly clear about his views for
| decades. At this point it's hard to be surprised that
| he'll make a pro-Free Software decision every time,
| without fail. That doesn't mean you have to agree with
| his decisions, of course! But to be shocked or
| disappointed by them is a sign of not understanding his
| platform.
| umanwizard wrote:
| But the person you're responding to never said he was
| shocked or disappointed by the views; he just said the
| views are bad/counterproductive.
| kstrauser wrote:
| But they're only bad/counterproductive when assessed
| against their own goals. They're a lot more reasonable if
| you assess them against Stallman's, where you could say
| "yeah, these actions kept GCC from becoming a handy tool
| for proprietary interests who don't want to share their
| work back with us".
| Keyframe wrote:
| I found out the older I get the more sense rms makes.
| johnisgood wrote:
| I mean, I think he is right. If everyone stopped
| supporting Windows, it would have long died out in favor
| of easy-to-install Linux distributions... probably.
| cherryteastain wrote:
| 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.
| azinman2 wrote:
| And then the world started moving on, with other licenses
| that gave even more freedom and flexibility.
|
| It was a great start, but you need to adapt or you
| perish.
| anthk wrote:
| When VSCode et all beging shipping DRM and who knows what
| in their extensions, then we'll se what with happens with
| these half-shareware semilibre projects.
|
| Specially when propietary dependencies kill thousands of
| projects at once.
| spookie wrote:
| Well, you are already unable to get most of the
| functionality out of vscode without Microsoft's extension
| store.
|
| I, for one, am happy that there are still a couple of
| people here and there that you can really trust on this
| stuff.
| trelane wrote:
| > other licenses that gave even more freedom and
| flexibility
|
| That gave _vendors_ more freedom and flexibility (to lock
| their software away from their customers.)
|
| As usual, customers got _less_ freedom and flexibility.
| azinman2 wrote:
| I disagree. They got software that's open under a
| different license that otherwise would have just been
| purely proprietary, or not created at all (due to the
| compounding effects of open source)
| trelane wrote:
| We are currently talking about GCC, where they _would_
| have gotten the source prior to LLVM.
|
| > They got software that's open under a different license
| that otherwise would have just been purely proprietary
|
| This is not a given, even outside of compilers. It's a
| heck of a cope there.
| azinman2 wrote:
| > 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.
|
| I was responding to this, which is more widespread than
| GCC (although it was one of the first wins of the GNU).
|
| There were various companies who wanted to add on
| backends and other bits to GCC, but wouldn't due to the
| license. That's one of the reasons LLVM is so popular.
| bluGill wrote:
| Bsd was long a thing proving you wrong. Yes gpl got more
| press but the other options existed for long.
| IshKebab wrote:
| I doubt that. People often say "without <person that
| started thing> we wouldn't have <thing>!" but it's
| nonsense. Someone else would have done it just slightly
| later.
| azinman2 wrote:
| The question is if that person would have dedicated their
| life in the same way.
| JoshTriplett wrote:
| 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.
| codeshaunted wrote:
| Is it still the case that the Linux kernel cannot be compiled
| using clang, or can you do that now?
| bombcar wrote:
| I believe clang has worked for years now.
| codeshaunted wrote:
| Why would anyone bother with GCC then? :P
| bombcar wrote:
| I believe GCC still wins _by far_ on support for weird
| CPUs and embedded systems.
| codeshaunted wrote:
| With LLVM I doubt this will remain true. LLVM makes
| custom code generation far too easy for GCC to remain
| viable imo.
| jcranmer wrote:
| I don't have much experience with writing a custom gcc
| backend, but my experience with LLVM is that its model
| ends up being a somewhat poor fit for smaller or weirder
| architectures. For example, LLVM has this annoying
| tendency to really aggressively promote the size of
| everything--if you have a 32-bit core with 64-bit memory
| indexing, LLVM tends to make anything that eventually
| becomes a memory index a 64-bit computation, even if it
| would be more efficient to keep everything as 32-bit.
| mort96 wrote:
| Hm, is it so much easier to write an LLVM back-end than a
| GCC back-end? I haven't looked into GCC's code gen
| infrastructure that much, but I looked into making a new
| back-end to LLVM some time ago and it seemed extremely
| complex and entirely undocumented. All guidance I found
| on it basically amounted to, "copy an existing back-end
| and bang it against a rock until you've made it generate
| the machine code you need". And it certainly wasn't a
| case of having clean and simple enough code to make
| documentation unnecessary. It would honestly surprise me
| if GCC is more difficult to add a back-end to.
| SubjectToChange wrote:
| The problem is that "weird CPUs and embedded systems" are
| not mainstream platforms, nor do they have a lot of money
| behind them (particularly for open source development).
| Hence, there is little motivation and/or resources for
| anyone to develop a new backend for LLVM when a mature
| GCC backend already exists. Moreover, the LLVM developers
| are weary to accept new backends for niche platforms when
| there is no guarantee that they will be maintained in the
| future.
| bombcar wrote:
| Exactly - often the GCC branch is barely maintained by
| whoever is selling the CPU/chip, and it is patches
| against a specific version that you must use, or it goes
| haywire.
|
| At least with GCC they can sometimes merge the patches.
| SubjectToChange wrote:
| GCC still for Linux distributions using glibc or any
| other library with many "GCCisms". Also, I'm not sure
| whether or not Clang is ABI compatible _enough_ for
| enterprise customers with some rather extreme backwards
| compatibility requirements. Still, I can imagine a future
| where glibc can be built with Clang, possibly even one
| where llvm-libc is "good enough" for many users.
| IshKebab wrote:
| Mainly because it was the default for so long, and Clang
| isn't _so_ much better that distros really need to
| switch.
| homebrewer wrote:
| 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.
| aengelke wrote:
| I'd add code quality as a reason. I find it much easier to
| understand and modify code in LLVM compared to GCC. Both have
| a fairly steep learning curve and not too much documentation,
| but often I (personally) find LLVM's architecture to be more
| thought out and easier to understand. GCC's age shows in the
| code base and it feels like many concepts and optimizations
| are just bolted on without "required" architectural changes
| for a proper integration.
| pxc wrote:
| > I expect someday clang will become the default [compiler for
| the Linux kernel].
|
| Why? I don't personally use GCC except to compile other
| people's projects in a way that's mostly invisible to me, but
| it seems like it's still widely used and constantly improving,
| thanks in part to competition with LLVM/Clang. Is the situation
| really so dire?
| wahern wrote:
| > Is the situation really so dire?
|
| I for one don't think so. From my perspective, there's at
| least as much momentum in GCC as clang/LLVM, especially on
| the static analysis and diagnostics front over the past 5 or
| so years. That was originally one of the selling points for
| clang, and GCC really took it to heart. It's been 10 years
| since GCC adopted ASAN, and after playing catchup GCC never
| stopped upping their game.
|
| Perhaps the image problem is that LLVM seems to be preferred
| more often for interesting research projects, drawing more
| eyeballs. But by and large these are ephemeral; the activity
| is somewhat illusory, at least when comparing the liveliness
| of the LLVM and GCC communities.
|
| For example, both clang/LLVM and GCC have seen significant
| work on addressing array semantics in the language, as part
| of the effort to address buffer overflows and improve static
| analysis. But GCC is arguably farther along in terms of
| comprehensive integration, with a clearer path forward,
| including for ISO standardization.
|
| 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.
| enasterosophes wrote:
| Unless you're talking about a compiler built into the kernel, I
| don't see that anyone is in a position to dictate to each
| distro what compilers they package.
| ahartmetz wrote:
| Clang:
|
| - has about the same quality of error messages as GCC now
|
| - is now almost exactly as slow (/fast) as GCC at compiling now
|
| - sometimes produces faster code than Clang, sometimes slower,
| about the same overall
|
| I see no reason why the default would change.
| mwkaufma wrote:
| Usability improvement request for this article: don't hijack the
| browser back button :P
| llm_nerd wrote:
| It's already egregious when a site adds history pushState
| entries for just clicking through a gallery or something, but
| wow adding them just for scrolling down on a page is simply
| bizarre, especially on a page about usability.
| nottorp wrote:
| It's in the spirit of adding emojis to compiler output...
| ender341341 wrote:
| 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.
| nottorp wrote:
| How do you grep for it without taking your hands off the
| keyboard?
| perching_aix wrote:
| Windows key + dot, then type in warning / if it was among
| the last ones you used, use the arrow keys, and hit Enter
| to insert it.
|
| If you use whatever OS other than Windows, I'm sure there
| are similar flows available if you search for it. And
| since it's just Unicode, I'm sure there are numpad based
| keybinds available too.
| nottorp wrote:
| why shouldn't i just type grep warning instead of
| bringing up some GUI that possibly takes forever to
| initialize?
|
| how does it work over ssh? :)
| johnisgood wrote:
| It makes too much sense.
| yazantapuz wrote:
| TIL that winkey+dot in kde launchs the emoji selector ...
| but it is copied into the clipboard, so more keystrokes
| nottorp wrote:
| At least i didn't get a link to an youtube tutorial as an
| answer :)
| optionalsquid wrote:
| In Firefox, you can prevent this by setting
| `browser.navigation.requireUserInteraction` via about:config.
| I've been told that it breaks some stuff, but to date I haven't
| noticed any downsides
| teddyh wrote:
| > _you can prevent this by setting
| `browser.navigation.requireUserInteraction`_
|
| Setting it to what?
| optionalsquid wrote:
| true
| budmichstelk wrote:
| Doesn't answer your question, but in Tor Browser it would
| decrease your anonymity set.
| DyslexicAtheist wrote:
| Usability improvement request for this site: don't promote a
| comment that isn't related to the content to the top :P
| perching_aix wrote:
| Not an issue with JS disabled ;)
| bigstrat2003 wrote:
| Browser makers should straight up remove the JS API for
| interacting with history. There are legitimate uses for it, but
| the malicious actors far outweigh the good ones at this point.
| Just remove it.
| Dracophoenix wrote:
| Ditto for unprompted redirects.
| bonzini wrote:
| Redirects are used for stuff like POST->GET or
| canonicalizing URLs (adding slashes on directories), would
| you get rid of that too?
| Calavar wrote:
| That's done with HTTP headers though, right? Not
| JavaScript.
| bonzini wrote:
| Ah, I see what you mean. The canonicalization is, whereas
| redirects after processing forms could be done in
| JavaScript from and on click or on submit handler.
| spookie wrote:
| same for clipboard events.
| panzi wrote:
| I mean, without `history.pushState()` and `window.onpopstate`
| things wouldn't be as nice. Ok, I guess one could do about
| everything with `location.hash = ...` and
| `window.onhashchange`, like in the before times. But the
| server will not get the hash part of the URL so a link to
| such an page can't be server side rendered and has to fetch
| the actual page content in JavaScript, evaluating the hash.
| When I browse things like image search it is really handy
| that you can use the browsers back button to close an opened
| image without loosing any dynamic state of the page and that
| the x button on the page will close the image and remove the
| history entry just the same way, so a later back won't re-
| open that image.
|
| For me the back button wasn't hijacked.
|
| But I am for disallowing the use of `history.go()` or any
| kind of navigation inside of `onpopstate`, `onhashchange`,
| `onbeforeunload` or similar or from a timer started from one
| of those.
| mort96 wrote:
| How about we just navigate to new pages by .. navigating to
| new pages? Browsers have perfectly functional history
| without javascript shenanigans
| nightfly wrote:
| This type of thinking is what doomed uBlock Origin. I
| strongly disagree.
| jenadine wrote:
| 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.
| nullc wrote:
| Ditto for rewriting anchor destinations onclick, allowing
| sites to show one destination for hover but send you
| somewhere else.
| codeshaunted wrote:
| Big fan of all of this except for the emojis in my console
| guenthert wrote:
| I actually appreciate a #\WARNING_SIGN, but then, why is there
| no #\STOP_SIGN ?
| staplung wrote:
| On the one hand I feel like the #WARNING_SIGN is a welcome
| addition. On the other, I'm sensitive to the idea that it will
| be totally obnoxious if you need to grep/search for it in
| whatever tool you're using.
|
| Was a little surprised to learn that the warning sign is
| generally considered an Emoji; I guess I don't think of it that
| way. Was even more surprised to learn that there is no great
| definition for what constitutes an Emoji. The term doesn't seem
| to have much meaning in Unicode. The warning sign - U+26A0 -
| goes all the way back to Unicode version 4.0 and is in the BMP,
| whereas most Emoji are in the SMP.
| codeshaunted wrote:
| How will it output on my VT100 serial terminal? :P
|
| Somewhat related fun fact, anyone can submit an emoji to the
| Unicode Consortium annually, submissions are actually open
| right now: https://unicode.org/emoji/proposals.html.
| Someone wrote:
| > Was even more surprised to learn that there is no great
| definition for what constitutes an Emoji. The term doesn't
| seem to have much meaning in Unicode
|
| The definition is messy, but the list of Unicode emojis is
| defined. Starting points:
| https://www.unicode.org/reports/tr51/,
| https://unicode.org/emoji/charts/full-emoji-list.html
| bonzini wrote:
| It's only an emoji if followed by the "emoji presentation
| selector" U+FE0F. Without it, it has no colors (but
| hackernews doesn't allow including it).
| high_na_euv wrote:
| Why?
| umanwizard wrote:
| Well, other than the fact that it's hard to search for,
| things should be kept as simple as possible to improve
| reliability/interoperability. Are you confident that multi-
| column-wide non-ASCII characters work reliably without
| causing rendering issues on every possible combination of
| terminal/shell/OS, including over SSH? I'm certainly not.
| gpderetta wrote:
| You can already put multi-column-wide non-ASCII characters
| in your source code, so the horse has left the barn
| already.
| umanwizard wrote:
| Of course you _can_. I 'd argue you shouldn't, but that's
| beside the point. There is clearly a difference between
| people being able to do something, and the compiler
| forcing it on them.
| IshKebab wrote:
| But the compiler isn't forcing it on anyone?
| dzaima wrote:
| 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.
| aseipp wrote:
| 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.
| codeshaunted wrote:
| Makes me feel like I'm writing JavaScript, if that makes any
| sense. Also I hate fun.
| javier_e06 wrote:
| I started putting emoji's in my bash scripts.
|
| gitk broke! Can't parse emojis
|
| I want emojis in my code. They are a superior form of
| communication (non-linear)
| nomel wrote:
| > I want emojis in my code.
|
| Then you will enjoy swift [1]!
|
| [1] Emoji driven development:
| https://www.swiftbysundell.com/special/emoji-driven-
| developm...
| dlachausse wrote:
| It should be easy to patch out or possibly add a command line
| switch to disable it if desired.
| cassepipe wrote:
| Already exists : -fdiagnostics-text-art-
| charset=[none|ascii|unicode|emoji]
| Karliss wrote:
| Few versions ago GCC added `-fdiagnostics-text-art-
| charset=[none|ascii|unicode|emoji]` so feel free to disable
| them.
|
| https://godbolt.org/z/bYc7EqYWE
| pxc wrote:
| If you're using an OS that honors your font choices (i.e., not
| macOS), you can use a font like Symbola to provide emoji so
| that they're stylized, monochrome, and vectorized, rather than
| incongruous color bitmap images. That helps them play nice with
| terminal colorschemes and things like that.
|
| I'm not aware of any emoji fonts like Symbola which provide a
| monospace typeface, though. That would be a great option.
| wiseowise wrote:
| Already looking forward to `grep`ing warning emojis in output.
| What's next? Poop emoji for errors?
| johnisgood wrote:
| I do not want any emojis from my compiler's output, heck, in my
| terminal in general. Please, do not make it the default
| behavior.
|
| (BTW my terminal does not even support emojis.)
| aseipp wrote:
| Why wouldn't you just keep search for the "warning:" or
| "error:" anchor, like people (and editors) have been doing
| forever? Even if that wasn't true it's not like searching for
| emojis is hard anyway. If it takes longer than 2 seconds for
| you to open a picker then you should ask for a refund for your
| computer.
| db48x wrote:
| Why would you grep for the emoji? The actual pattern you want
| to match is the standard format of the error message that
| proceeds it, which hasn't changed in eons: my
| $line = "infinite-loop-linked-list.c:30:10: warning: infinite
| loop [CWE-835] [-Wanalyzer-infinite-loop]"; grammar gcc
| { token filename { <-[:]>+ }; token
| linenumber { \d+ }; token colnumber { \d+ };
| token severity { info|warning|error }; token
| message { .* $$ }; regex diagnostic {
| <filename> [\:] <linenumber>
| [\:] <colnumber> [\:]\s
| <severity> [\:]\s <message>
| }; token TOP { <diagnostic> }; }
| say gcc.parse($line);
|
| which when run produces the obvious output:
| [infinite-loop-linked-list.c:30:10: warning: infinite loop
| [CWE-835] [-Wanalyzer-infinite-loop]] diagnostic =>
| [infinite-loop-linked-list.c:30:10: warning: infinite loop
| [CWE-835] [-Wanalyzer-infinite-loop]] filename =>
| [infinite-loop-linked-list.c] linenumber => [30]
| colnumber => [10] severity => [warning]
| message => [infinite loop [CWE-835] [-Wanalyzer-infinite-loop]]
|
| I'll leave handling filenames containing colons as an exercise
| for the reader.
|
| The emoji just focus the reader's eye on the most critical line
| of the explanation.
| munificent wrote:
| Using a hierarchy to show template errors is brilliant and I'm
| sort of surprised compilers haven't always done that.
|
| I was investigating C++-style templates for a hobby language of
| mine and SFINAE is an important property to make them work in
| realistic codebases, but leads to exactly this problem. When a
| compile error occurs, there isn't a single cause, or even a
| linear chain of causes, but an potentially arbitrarily large
| _tree_ of them.
|
| For example, it sees a call to foo() and there is a template
| foo(). It tries to instantiate that but the body of foo() calls
| bar(). It tries to resolve that and finds a template bar() which
| it tries to instantiate, and so on.
|
| The compiler is basically searching the entire tree of possible
| instantiations/overloads and backtracking when it hits dead ends.
|
| Showing that tree _as a tree_ makes a lot of sense.
| eddd-ddde wrote:
| I really wish templates didn't work on a dumb "replace at call
| site until something compiles" manner.
|
| All template requirements should be verified at the function
| definition, not at every call site.
|
| There is concepts. But they are so unwieldy.
| munificent wrote:
| It's honestly a seriously hard problem.
|
| Yes, it's definitely nice to be able to typecheck generic
| code before instantiation. But supporting that ends up adding
| a _lot_ of complexity to the typesystem.
|
| C++-style templates are sort of like "compile-time dynamic
| types" where the type system is much simpler because you can
| just write templates that _try_ to do stuff and if the
| instantiation works, it works.
|
| C++ templates are more powerful than generics in most other
| languages, while not having to deal with
| covariance/contravariance, bounded quantification, F-bounded
| quantification, traits, and all sorts of other complex
| machinery that Java, C#, etc. have.
|
| I still generally prefer languages that do the type-checking
| before instantiation, but I think C++ picks a really
| interesting point in the design space.
| jenadine wrote:
| C++0x concepts tried to achieve that but that didn't work.
|
| (But Rust traits works like that)
| budmichstelk wrote:
| I like a these modernization efforts in GCC, a lot of old niggles
| are gone now, and they've made a lot of new improvements I didn't
| think were possible/easy!
| brcmthrowaway wrote:
| What is the status of GCC plugins?
| o11c wrote:
| Is there any reason to ask this? GCC plugins have been good
| since 4.8. 4.5 lacked some essential features; 4.6 would be
| fine if not for the annoyance of trying to support a plugin
| that works across the C++ transition. Of course, you can just
| use the Python plugin to save yourself a lot of sanity ...
| aseipp wrote:
| They work. You can use them? They haven't gone anywhere and the
| Linux kernel relies on them extensively, among other things.
| porphyra wrote:
| With GCC error messages usually the only part I wanna see is
| "required from here" and yet it spams zillions of "note: ...".
| With the nesting enabled, it's way easier to read --- just look
| at the top indentation level. Hooray!!!
| levodelellis wrote:
| Please gcc, let me have a `~/.config/gcc` config file or an ENV
| variable so I can ask for single lined error messages.
|
| I literally do not need ascii art to point to my error, just tell
| me line:col and a unique looking error message so I can spend no
| more than 1 second understanding what went wrong
|
| Also allow me to extend requires with my own error messages. I
| know it'll be non standard but it would be very nice tyvm
| kazinator wrote:
| I can't imagine a piece of software easier to use than gcc 3.4.6,
| sorry.
|
| We are now entering a Rococo period of unnecessarily ornate
| compiler diagnostics.
|
| Getting these elaborate things to work is a nice puzzle, like
| Leetcode or Advent of Code --- but does it have to be merged?
___________________________________________________________________
(page generated 2025-04-10 23:00 UTC)