Comments by workingjubilee

AHA, MY PLAN WAS TO TEST THE CANCEL FUNCTION ALL ALONG

alternatively leave a comment on it. anyone who works with this code will have to read the letters written in blood on the walls to get anything correct anyways.

:pensive: I was trying to violate assumptions in the opposite direction but LLVM said no.

I admit that

canonize_abi

function is bigger than I thought it would be.

That's the thing about an abstraction, it's bigger on the inside :^)

In addition, we have entirely removed support for Makefile-based tests. This test tests nothing, that's why it passes.

...Is the problem that you literally have 128TiB of RAM?

You would not expect the following to change the sign of the zero, would you?

[-0.0f32].into_iter().sum()

Why is it used?

Was this technology selected based on meeting a criteria, or based on vibes?

@cedkim wow you also deleted LLVM and GCC! no compiler survives, eh?

except

uh HotSpot, I guess?

The dividend isn't even zero. Why is clippy's "zero_divided_by_zero" lint firing on a division of not-zero by zero?

Both ff64.dll and nsccor0364.dll appear to be security software.

The security software appears to be insecure.

@bors r+ into your hands, I commend my spirit

I love how consistent the outputs of our testing infrastructure are /s

@T-Dark0 We, er, eliminated the data we could use to show that.

...I would prefer not to?

Oh wow I did a slightly further investigation and it definitely can't, LLVM does a UB if you reach that branch lol, we have to die on it.

I use Arch Linux.

Anyone using x32 is having a cursed time, but they definitely shouldn't be cursed by being forced to use an even older kernel version than needed.

I'm sorry but I have a huge and tedious nit that should be a tidy rule but isn't because Reasons.

hand me my hat, tonight's dinner has been picked for me

sigh!

r=me if undrafted

And anything which depends on an implementation in YamlScript is right the fuck out.

I can make this PR my entry in the most-files-in-tree-diffed-in-2024 competition, sure.

Note that I am deliberately ignoring that technically someone can shadow the implicit Rust prelude with their own Option, Result, Vec, etc. and break your code that way.

I assume that the mere act of having a glob-import from upstream is a willingness to subject yourself to deliberate horrors enacted by them.

Let this be a reminder to everyone that every miscompilation issue is its own unique, sparkling star, and it is possible for two such stars, alike in dignity yet still standing in distinction, to fall from the heavenly tapestry of fate and strike the Rust toolchain at about the same time.

no revert whammies?

undefined

We should not assume. We should panic, and submit a separate PR proposing to add the elf version to the

abi

I don't think anyone but me is crazy enough to rollup a PR that has "non-determinism" in the title, so you get the VIP treatment instead:

@bors rollup=never p=1

"well, my child, when a high surrogate and a low surrogate get together, they blow your code up stop doing that"

I like the gross

concat!

@knickish Have you read and understand the terms of https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html#tier-3-target-policy regarding target maintenance?

Briefly put: The ticket is free because the ride ain't got no safeties, no brakes, and no complaining.

As of https://github.com/rust-lang/rust/pull/135053 we now have a backtrace version that includes the libunwind change and builds, without immediately requiring us to enable ruzstd support (and thus without immediately addressing any performance questions).

This is a tier 3 target and thus I am entitled to ship a change recklessly to it without heed to whether it still builds¹. MUAHAHAHA!

@bors r+ rollup

Mmh. If we set

EF_MIPS_ARCH_32R2

Architecture::Mips64

panic!()

bug!()

oh, well, that's true, I guess I'm assuming the taking forever is almost a constant :^)

Ah, well, yes, I would agree, I just figured the answer from Arm was the obvious one ("it puts the frame pointer in the register or else it gets the hose again")

Ah, the answer is that the filter that matches nothing instead matches everything. Great.

@compiler-errors Oh, sorry, didn't see the try.

r? compiler

I have barely any idea about LTO besides "it happens and it involves dlopening a compiler and shoving its serialized data back in it" tbh soo

oh, lol, it won't actually take until after the merge because the base build is broken.

Has anyone tried just sending a patch to introduce the error?

assigning it to the usual suspects, since I suspect they will be most-capable of commenting on it.

Ah yeah, looking at the target docs, they specify a musl-specific toolchain: https://doc.rust-lang.org/nightly/rustc/platform-support/powerpc64-unknown-linux-musl.html#building-the-target

Classing this as working-as-intended (by not working).

Closing since any bug here is "I enabled verbose mode and I got an extremely chatty squawking parrot of a build system" which... yeah, Rust tooling tends to be chatty by default so verbose is asking for A Lot.

cogitating...

I wonder about

enum Never<T> {
    Say(!),
    Again<T>
}

The matter of what the "first" variant is probably gets funny when some are uninhabited...

Seems fine! If someone wants to

abort()

The CPU is an Intel i9-14900K.

...Yeah, okay, that CPU is known to run a risk of exploding into flames, but it should at least go really fast before it explodes! So it's definitely the compiler's fault here.

Congratulations! It landed! Your reward is more toil. Alas, the futility of humankind. :^)

It cannot be "because it would be a miserable pile of bikeshedding". We're just inflicting a miserable pile of bikeshedding on everyone every time they have to reimpl their own pile of float traits. Skipping numeric traits in std made sense in 2015 but it doesn't really make the same sense in 2025.

then on the ERROR down here we will prefix it. the current one will be

//[gnu]

//[musl]

// the path of the dylib.

// other stuff I can't comment on because GitHub reviews aren't great

//[gnu]~? ERROR couldn't load codegen backend /non-existing-one.so
//[musl]~? ERROR idk, you're the one making the PR

I wonder if we can enable deriving Default for unions if a default field value is given and that union variant selected via something like

#[default]

Nonetheless, it seems far better to simply yeet this unintended consequence and figure that sort of thing out later.

Yes, part of the reason I asked for this error is because LLVM only inconsistently emits that LLVM error. Some interrupt ABIs make no sense to call but LLVM just lets you YOLO it.

@sayantn Only touch the things you are touching now. Do not scope-creep this PR one iota or I will close it.

Then go implement it if you think it's such a good idea.

ah right I wound up unrewriting it when it became less necessary...

I would rather you just close my PR than pretend we're actually helping anyone by implementing a deprecation cycle for a feature no one really wants.

@Amanieu What authority would you defer to? Who is gonna specify that requirement? Should we ask Linus Torvalds?

no reason? k, I'll r+ it for you, past!jubilee

@bors r+ rollup

...just randomly fixed an ICE I guess?

die, hopefully

Well, I suppose it's not complicated in implementation, arguably even simpler, just... complicated in implications.

My apologies, I know this all might seem surprising and annoying, but, well, you see, 32-bit x86 exists, you know? So we all have to live with the consequences of its... very... organic development.

then I'm pro-yeet

righto then, leaving it

unsafe

The stack overflow appears to have been a spurious error.

I indeed concede defeat.

I have checked multiple windows 11 PCs same issue is observed.

Were all of these Windows PCs from the same vendor?

mmm, three versions of gimli in the repo... should fix that...

@no1wudi it's... not supported?

...but this is Arm we're talking about...?

( I'm pretty sure this makes the flag unsound again but hey it was unsound for years. )

As long as we have the ear of appropriate folks, then the safety conditions of this should be documented. When does this function trigger undefined behavior if you call it? Is it about certain arguments or does it just alternate every Tuesday? ...Probably the former.

I have opened a proposal to clarify we do not need that much process for this sort of additive change. I think that as long as it incorporates the current user-facing elements, it would unfortunately still be stuck on the process of agreeing we want to change the process to require less process. :^)

An alternative would be to, in fact, say "yes,

extern "rust-invalid"

Another option is to make the document comment correct by complicating the code with

slice.len()

If the answer is "no" then we should probably comment that we are explicitly saying "lol" to any error.

I'm mostly wondering to make sure we didn't just hit some weird inlining thresholds or anti-thresholds.

I think those are called "limits", Jubilee.

The documentation seems to be incorrect.

I'd also just like to see something higher than 16 and 32 for a test (or test revision). Let's get sillier. Have one of the values be outside the range of a u8, say.

Oh, wait, this is a HashMap in another crate... nevermind.

@RalfJung You are the Pope of Rust, or at least the Pope of Rust Safety Models. Whenever you say something, even if you say something blatantly wrong, almost no one calls you out on it. You are the proxy author and reviewer of all std code because everyone is reading everything you are writing and thinking about it when writing unsafe code. You are repeatedly cited in these discussions. If you repeatedly say something wrong, you can convince other people it's true, simply by repeating the wrong thing.

@Zalathar well... I think that saying both the pointer and the len should come from the same slice is a pretty safe bet? :thinking:

but yes you are right, please feel free to add this to any list of safety requirements:

/// - who knows? LLVM didn't exhaustively document it

what saethlin might call a "brave" rollup

@bors r+ rollup=never p=5

Because the neutral element of

<fNN as iter::Sum>

was changed to neg_zero, the documentation needed to be updated, as it was reporting incorrect information about what should be expected from the return.

And I must note, the documentation was not technically incorrect.

...You can say it was uselessly correct, of course.

+2,219 −65

oh dear

@RalfJung To be clear, codegen backends have miscompiled Rust code by dint of this intrinsic relying on data that can undermine Rust assumptions: https://github.com/rust-lang/rustc_codegen_cranelift/issues/1560

I am not sure "urgent" is the word but perhaps "should have been fixed yesterday"?

What kind of nondet are you thinking of?

I mean, we should probably try to reason a bit about the actual transformations that are allowed rather than just pulling floats out of a random number generator. Valid programs might still use mathematical reasoning (...with some appropriate error bars on either side, of course, to account for the differences between float-exact and real-exact computations).

One option I can think of is to flip a coin and then decide whether or not to compute the operation to an absurd precision?

?

It's also possible that the tests already exist and I was just too ferrisClueless.jpg to find them

@andrewoffenden what.

@SciMind2460 I seriously do not care if your commits are "verified" or not.

Well. I am going to nominate this for beta and let people decide it's not worth the trouble.

hmm, gotta be my own PR.

@Houtamelo I think you've Berenstein Beared yourself: rustc emits two warnings as far back as 1.0 as far as I can tell.

It seems we may have another

llvm_unreachable

...okay for most of those I see what youre saying but:

log2?

howso? pretend I am too lazy to go look at that issue (because I am)

literally was just pushing that :^)

@bors r=madsmtm

...damn, that codegen sucks ass?

Thanks! Sorry about the delay, meant to approve this before I wound up on the other side of the world!

@bors r+

ah, this is a "tomorrow" PR. poke me if I do not get to it then.

Cool. This now looks good at a glance, and I will approve and merge when the part of me that feels confident in that statement (or would have the gall to disagree? one of those) actually wakes up.

answer to jubilee: it's not, the commit was just not split and you haven't finished your coffee yet.

Let's not speculate if we don't have anything else to go on:

            Err(Box::new("thread terminated unexpectedly"))

watch me get bitten by some stack layout detail