<re_irc>
This triggers the error twice. Both point at the "Domain::new()" span.
<re_irc>
The notes differ. One note points at the closure parameters and the other points at the whole "async move {}" span
<re_irc>
<@diondokter:matrix.org> I use TAIT because I can't name that future
<re_irc>
<@dirbaio:matrix.org> what's the signature for the function that does "PERIPHERALS_DOMAIN.init"?
<re_irc>
<@dirbaio:matrix.org> the error is that it's now required to mention the "PeripheralDomain" type
<re_irc>
<@dirbaio:matrix.org> either in params or return value
<re_irc>
<@diondokter:matrix.org> Oh
<re_irc>
<@dirbaio:matrix.org> because _reasons_
<re_irc>
<@diondokter:matrix.org> Yeah, the function doesn't mention it
<re_irc>
<@diondokter:matrix.org> I have a lot op power domains and they are returned as "[&'static mut dyn DomainObject; 24]"
<re_irc>
<@diondokter:matrix.org> * of
<re_irc>
<@dirbaio:matrix.org> the reason is "ide-friendliness": so that IDEs have to typecheck less code when they want to get what the underlying type of a TAIT is
<re_irc>
<@diondokter:matrix.org> Hmmmm... Yeah ok I get why that'd be nice. But now I can't use it for static items anymore...?
<re_irc>
<@dirbaio:matrix.org> before it was "all functions under the parent mod", now it's "all functions under the parent mod that mention the type"
<re_irc>
<@diondokter:matrix.org> Ok, I don't like that. Doesn't make sense
<re_irc>
<@diondokter:matrix.org> Within a parent mod only was already a bit awkward
<re_irc>
<@dirbaio:matrix.org> like, making it typecheck less functions makes it faster, and the functions that constrain the TAIT are likely to mention it
<re_irc>
<@dirbaio:matrix.org> so as a heuristic, let's restrict to that
<re_irc>
<@dirbaio:matrix.org> yeah, "parent mod" has always made me uncomfortable too
<re_irc>
<@dirbaio:matrix.org> it has the tendency of causing strange compiler errors because it makes the defining scope too big
<re_irc>
<@diondokter:matrix.org> Purely looking at the language, it should be valid inside the entire crate
<re_irc>
<@dirbaio:matrix.org> but at least it was easy to explain
<re_irc>
<@diondokter:matrix.org> Well if this is kept, then they should at least improve the error message
<re_irc>
<@diondokter:matrix.org> Ok, but now what? I don't know how to fix this with these new rules
<re_irc>
<@dirbaio:matrix.org> now it's "defining site must be within the parent mod, within a function that mentions the TAIT in return value or arguments. If the function is nested within other functions, all functions in the chain must satisfy that"
<re_irc>
<@dirbaio:matrix.org> you have to extract that "PERIPHERALS_DOMAIN.init" to a fn that is "-> PeripheralDomain", and call that from the main fn
<re_irc>
<@dirbaio:matrix.org> so that it mentions the TAIT
<re_irc>
<@diondokter:matrix.org> Hmmm that might work
<re_irc>
<@dirbaio:matrix.org> or just pin to an older nightly :D
<re_irc>
<@diondokter:matrix.org> That only helps if it gets reverted in the future :P
<re_irc>
<@diondokter:matrix.org> Oh, didn't notice on my project just now
<re_irc>
<@dirbaio:matrix.org> it bloated "change a single line" compile time for my project from 13s to 1m43s 😂
<re_irc>
<@diondokter:matrix.org> Oof, that's bad
<re_irc>
<@dirbaio:matrix.org> i'm using "ekv" which seems to be particularly affected
<re_irc>
<@dirbaio:matrix.org> just to confirm, that fn has several TAITs like that, right?
<re_irc>
<@dirbaio:matrix.org> they're all different types
<re_irc>
<@dirbaio:matrix.org> so you can't just make it return "[&'static mut PeripheralDomain; 24]"?
<re_irc>
<@diondokter:matrix.org> Yep
<re_irc>
<@diondokter:matrix.org> Sadly no
<re_irc>
<@diondokter:matrix.org> Each power domain has an 'async closure' that is able to act on hardware. For example, one needs to control the buck-boost converter over SPI if its domain is turned on or off. Another one needs to set an enable or disable pin.
Dr_Who has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> I'm proposing to the Rust folks making TAIT require a "#[defines(MyTait)]" attribute on the defining fn instead
<re_irc>
<@dirbaio:matrix.org> so you control the defining scope explicitly, instead of leaving it up to a heuristic that falis half the time
<re_irc>
<@dirbaio:matrix.org> sometimes the heuristic makes the defining scope too big, causing funny errors lke typechecking cycles
<re_irc>
<@dirbaio:matrix.org> sometimes it makes the defining scope too small, like what you're seeing onw
<re_irc>
<@dirbaio:matrix.org> * now
<re_irc>
<@dirbaio:matrix.org> also "#[defines]" could be allowed anywhere within the crate, not just the parent mod.
<re_irc>
<@dirbaio:matrix.org> in my eyes, it solves literally all the problems with TAIT 😬
<re_irc>
<@diondokter:matrix.org> Explicit ownership of the definition would solve it I think yeah. And if you restrict that the crate that contains the TAIT must also do the attribute, then in theory it could also be made public and be used by dependents
<re_irc>
<@dirbaio:matrix.org> you can already make a TAIT public
<re_irc>
<@dirbaio:matrix.org> * public, not sure what you mean by that
<re_irc>
<@diondokter:matrix.org> Really? I remember trying that in the past and getting weird errors
<re_irc>
<@diondokter:matrix.org> But maybe that has improved
<re_irc>
<@diondokter:matrix.org> Any place where I can put my complaint that would strengthen your case?
<re_irc>
<@dirbaio:matrix.org> that thread I guess
<re_irc>
<@dirbaio:matrix.org> I've already made a mini-summary linking to the chatlog here
<re_irc>
<@dirbaio:matrix.org> if oyu have other experience reports of TAIT they'd be welcome too
<re_irc>
<@dirbaio:matrix.org> or if anyone else does
<re_irc>
<@dirbaio:matrix.org> please share!
<re_irc>
<@dirbaio:matrix.org> no matter whether TAIT just worked, or whether you ran into issues with the defining scope. The more data the better
<re_irc>
<@diondokter:matrix.org> Ok, I've refactored every initialization into its function (thanks Rust Analyzer!) and it compiles again
<re_irc>
<@dirbaio:matrix.org> I did some code search on github and found almost nothing other than embedded.
<re_irc>
<@dirbaio:matrix.org> we're the only major users of TAIT 😂
<re_irc>
<@diondokter:matrix.org> Well if I had a heap, I would not have had to put my domains into staticcells. It'd just box it to get the trait objects
<re_irc>
<@diondokter:matrix.org> So yeah, I can imagine haha
<re_irc>
<@dirbaio:matrix.org> yeah everyone else just boxes everything 🤪
IlPalazzo-ojiisa has joined #rust-embedded
chip has left #rust-embedded [Leaving...]
<re_irc>
<@burrbull:matrix.org> : I think they jusr waiting for stable
<re_irc>
<@burrbull:matrix.org> In reply to @dirbaio:matrix.org
<re_irc>
I think they just waiting for stable
<re_irc>
yeah everyone else just boxes everything 🤪
<re_irc>
<@mabez:matrix.org> Is there a way to see what optimizations lto does? I have some code that _only_ works with lto = true or lto = fat. I would like to see what it changes to actually make it work
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Suspected lto to be causing trouble a while ago, as well, and it turned out to prevent a stack overflow actually... Could that be the case for you?
<re_irc>
<@dirbaio:matrix.org> not really :(
<re_irc>
diffing the asm, but the diff will be huge
<re_irc>
<@mabez:matrix.org> : Yeah thats the stage I'm at now and the diffs are just insane, impossible to see what changes are actually relevant
<re_irc>
<@dirbaio:matrix.org> it's likely either timing or ub 🥲
<re_irc>
<@dirbaio:matrix.org> missing "#[inline]"s maybe, preventing cross-crate inlining which makes the code too slow to hit some deadline?
<re_irc>
<@mabez:matrix.org> This is for an Xtensa target so could also be a miscompilation 🥲
<re_irc>
<@mabez:matrix.org> : It's failing somewhere during interrupt handling, so it could be something like this
<re_irc>
<@diondokter:matrix.org> Timing is weird haha.
<re_irc>
Many years ago I had to do:
<re_irc>
} else {
<re_irc>
// normal code
<re_irc>
}
<re_irc>
asm(/* ... */); // Quite a lot of lines
<re_irc>
if debug {
<re_irc>
I just took the asm from the compiled release build :P
<re_irc>
This was the only time-critical interrupt and I needed to not optimize some things so I could debug my code better.
<re_irc>
Probably the most cursed thing I ever did
<re_irc>
<@diondokter:matrix.org> Later I found out the hardware (STM super advanced timer) had the capability to do it on its own hahaha
<re_irc>
<@diondokter:matrix.org> : Yep, very cool feature! But then I'd had to refactor the interrupt into its own crate haha
<re_irc>
<@mabez:matrix.org> Gah, I found the issue, some dodgy linker relocations. Somehow without LTO enable the linker places some constants in an invalid address space, or more likely incorrectly encodes the "l32r" instruction to point to invalid memory
<re_irc>
<@mabez:matrix.org> This is not going to be fun to track down 😭
<re_irc>
<@halfbit:matrix.org> : With xtensa maybe something like a register window overflow while interrupts are locked
<re_irc>
<@halfbit:matrix.org> with the inlining (lto) perhaps fewer asm call like instructions rotating registers
<re_irc>
<@halfbit:matrix.org> and I see you found some poor relocations, fun fun
<re_irc>
<@halfbit:matrix.org> so ignore the above, xtensa is just a bundle of joy /s
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
<re_irc>
<@roy.buitenhuis-tnl:matrix.org> Can I keep a reference to a future returned by embassy_net's udp_socket.recv_from(buf) in a struct? I don't have a allocator, so no Box::pin.
<re_irc>
<@dirbaio:matrix.org> kinda yes, using TAIT
<re_irc>
<@dirbaio:matrix.org> I'd strongly advise against it
<re_irc>
<@roy.buitenhuis-tnl:matrix.org> I am forwarding my UDP Socket trough a C library, On the Tasks's side I already have a Future that awaits my C function's call, which would return a non block if it's pending. Now I need to to the opposite on the other side where the C library is gonna call my embassy UDP socket. SO I think I need to store the future returned by recv_from in a struct forward through the c lib.
<re_irc>
<@roy.buitenhuis-tnl:matrix.org> I am forwarding my UDP Socket trough a C library, On the Tasks's side I already have a Future that awaits my C function's call, which would return a non block if it's pending. Now I need to to the opposite on the other side where the C library is gonna call my embassy UDP socket. SO I think I need to store the future returned by recv_from in a struct forward through the c lib. Then I can poll the future and...
<re_irc>
... convert the result to what the c lib wants.
<re_irc>
<@dirbaio:matrix.org> hah
<re_irc>
<@dirbaio:matrix.org> then maybe TAIT is the way to go yes
<re_irc>
<@dirbaio:matrix.org> perhaps a non-async "try_recv_from()" or "poll_recv_from()" would help?
<re_irc>
<@roy.buitenhuis-tnl:matrix.org> That would help
<re_irc>
<@dirbaio:matrix.org> PRs welcome then 🙃
<re_irc>
<@like2wise:matrix.org> Problem Report, Pull Request, Press Release? In that order? 😋
<re_irc>
<@roy.buitenhuis-tnl:matrix.org> : First need to look into what those TAITs are :) Thank's for the help.
<re_irc>
<@dirbaio:matrix.org> with try_recv_from / poll_recv_from you wouldn't need TAIT
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 260 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@boathouse:matrix.org> Why is gdb the recommended remote debugger, when rust uses llvm tools for most other things?
<re_irc>
<@boathouse:matrix.org> lldb
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@fuse117:matrix.org> probably a noob question, but is there anything special i need to do to use RTT with the nrf9160d. i keep hitting "Failed to attach to RTT" errors.
<re_irc>
<@therealprof:matrix.org> boathouse: Because (unfortunately) people care more about gdb than lldb.
<re_irc>
<@adamgreig:matrix.org> @room hi all, meeting time again! agenda is https://hackmd.io/SDGjnOmWQxWwJ616XINuSg, please add anything you want to announce or discuss and we'll start in a few minutes
<re_irc>
<@thejpster:matrix.org> I’ll grab my laptop. BRB.
<re_irc>
<@diondokter:matrix.org> Ugh, I still haven't looked into the cortex-m-rt PR of mine. Where oh where does the time go
<re_irc>
<@adamgreig:matrix.org> tell me about it, I'm always surprised every tuesday
<re_irc>
<@adamgreig:matrix.org> ok, let's start, only one announcement from me which is that rust 1.71 comes out thursday, I didn't spot anything especially embedded-relevant in the release notes yet though
<re_irc>
<@adamgreig:matrix.org> does anyone else have anything?
<re_irc>
<@thejpster:matrix.org> I put in a PR for bare-metal SPARC, for all the Leon3 fans in the house.
<re_irc>
<@thejpster:matrix.org> But don't tell anyone. It's a surprise for a conference in September.
<re_irc>
<@thejpster:matrix.org> (my first rust-lang/rust PR with actual code in it - but all my mistakes were in the Markdown :/ )
<re_irc>
<@therealprof:matrix.org> : ptr::read will be available in const. Might be handy.
<re_irc>
<@adamgreig:matrix.org> probably best avoided for most embedded use cases though :P
<re_irc>
<@adamgreig:matrix.org> OK, next up, I still need to organise the PRs for the cortex-a team updates, will do that this evening
<re_irc>
<@adamgreig:matrix.org> nothing new to report on bors front atm, and no update on the cortex-m hardfault trampoline yet
<re_irc>
<@adamgreig:matrix.org> have pinged tools team for the svd2rust per-periph steal, otherwise will merge that soon
<re_irc>
<@thejpster:matrix.org> who's joining the cortex-a team?
<re_irc>
<@adamgreig:matrix.org> last week opened https://github.com/rust-embedded/embedded-hal/pull/466 to add the embedded-io crate/traits to the embedded-hal repo as a step towards finishing the Serial traits for e-h 1.0
<re_irc>
<@adamgreig:matrix.org> CI passes so I think that's just waiting on sign-off from HAL team, we discussed it already last week
<re_irc>
<@dirbaio:matrix.org> ah no: "@speed_hz: Temporary override of the device's bitrate."
<re_irc>
<@dirbaio:matrix.org> perhaps you're suposed to set it in DT yes
<re_irc>
<@dirbaio:matrix.org> yea in that case linux-embedded-hal's SpiDevice impl would have to do nothing, the kernel would automatically use the correct freq for each device on the bus as defined in DT
<re_irc>
<@henrik_alser:matrix.org> : For example sdmmc sometimes needs to init at a lower freq than it can do in subsequent usage
<re_irc>
<@dirbaio:matrix.org> ahh that makes sense
<re_irc>
<@adamgreig:matrix.org> in that case you don't so much want a closure then, just be able to grab the bus back for a bit and remake the device I guess
<re_irc>
<@adamgreig:matrix.org> : is Read useable without ReadReady?
<re_irc>
<@adamgreig:matrix.org> I guess on threaded std you might well just block a thread on a read
<re_irc>
<@dirbaio:matrix.org> yes, it's just that it might block
<re_irc>
<@dirbaio:matrix.org> like "std::io::Read", yep
<re_irc>
<@adamgreig:matrix.org> so in practice I expect most drivers for embedded using them will use ReadReady too, but I guess that's OK
<re_irc>
<@dirbaio:matrix.org> perhaps except some ultra dumb single-threaded thing where you don't care about blocking forever?
<re_irc>
<@dirbaio:matrix.org> like if your device's UI is a serial console and you literally don't do anything in the backgrnd
<re_irc>
<@dirbaio:matrix.org> but yeah most people will probably use ReadReady. I guess that's fine?
<re_irc>
<@adamgreig:matrix.org> so long as most HALs end up implementing it
<re_irc>
<@adamgreig:matrix.org> if they're re-exported next to each other in e-h I expect they would?
<re_irc>
<@dirbaio:matrix.org> popular demand would make them impl it 😈
<re_irc>
<@dirbaio:matrix.org> it's literally just "return !self.ringbuf.is_empty()"
<re_irc>
<@dirbaio:matrix.org> +and it's easy to impl,
<re_irc>
<@adamgreig:matrix.org> my other point from last week is that saying "semantics are same as std" is fine but maybe a bit unclear
<re_irc>
<@adamgreig:matrix.org> specifically around when things might choose to block vs return 0 bytes
<re_irc>
<@adamgreig:matrix.org> especially if you're a hal wondering what semantics to implement, std's docs are basically a shrug
<re_irc>
<@dirbaio:matrix.org> agreed
<re_irc>
<@dirbaio:matrix.org> will send a followup PR expanding hte docs
<re_irc>
<@dirbaio:matrix.org> * the
<re_irc>
read:
<re_irc>
<@dirbaio:matrix.org> the tldr is:
<re_irc>
- if EOF, return 0
<re_irc>
- if tx buffer full, block
<re_irc>
- if bytes received, return N
<re_irc>
- if no bytes received, block
<re_irc>
write:
<re_irc>
- if space in tx buffer, return N
<re_irc>
- if pipe is closed or whatever, and will never be able to accept more bytes, return 0
<re_irc>
<@dirbaio:matrix.org> same as std::io, same as posix rea/dwrite
<re_irc>
<@dirbaio:matrix.org> * read/write
<re_irc>
<@adamgreig:matrix.org> sgtm
<re_irc>
<@dirbaio:matrix.org> also: reexport io traits from "embedded-hal"?
<re_irc>
<@dirbaio:matrix.org> my preference is "no"
<re_irc>
<@dirbaio:matrix.org> but i'm not sure
<re_irc>
<@dirbaio:matrix.org> I think reexports are in general confusing
<re_irc>
<@dirbaio:matrix.org> especially if we ever bump e-h or e-io to 2.0
<re_irc>
<@dirbaio:matrix.org> you got a 1.0 crate reexporting a 2.0 crate or vice versa, figuring out which io version you get is confusing if you use it through the reexport
<re_irc>
<@adamgreig:matrix.org> I think it was positively received last meeting but personally I'm also happy with just them being documented as recommended for serial traits in a way that shows up on docs.rs (maybe an empty serial module or something in the top level docs)
<re_irc>
<@adamgreig:matrix.org> perhaps let's discuss that next meeting?
<re_irc>
<@jannic:matrix.org> A re-export would be nice if something from e-h used types from e-io. That way, users won't need to manually import a compatible version.
<re_irc>
But otherwise, I agree that re-exports just complicate things.
<re_irc>
<@adamgreig:matrix.org> the current PR doesn't, right?
<re_irc>
<@dirbaio:matrix.org> I can't think why e-h would want to use types from e-io, but if we ever do that we can add the reexports then.
<re_irc>
<@adamgreig:matrix.org> yea, I don't expect anything in e-h itself to otherwise use e-io
<re_irc>
<@dirbaio:matrix.org> one example is e-nal-async uses e-io for tcp sockets
<re_irc>
<@dirbaio:matrix.org> that's higher leve stuff though, further away from hardware
<re_irc>
<@jannic:matrix.org> If there's no "natural" dependency, please don't add one artificially.
<re_irc>
<@dirbaio:matrix.org> : love that way to frame it
<re_irc>
<@dirbaio:matrix.org> 100% agreed
<re_irc>
<@adamgreig:matrix.org> ok, let's leave it there for this week then, thanks everyone!
<re_irc>
<@adamgreig:matrix.org> hackmd now has a weird separate area for the title and doesn't respect markdown # for it, boo
<re_irc>
<@adamgreig:matrix.org> can't copy-paste into text files as easily, or from old hackmds into new ones
<re_irc>
<@therealprof:matrix.org> : Hm, a while ago I would have considered that a feature.
<re_irc>
<@adamgreig:matrix.org> it's probably nice for most people's use cases
<re_irc>
<@adamgreig:matrix.org> but mine is a) copy old hackmd text into new new, which is now harder, and then b) copy text from the hackmd into a text file for git, which is also now harder
<re_irc>
<@adamgreig:matrix.org> awkward edge case
<re_irc>
<@dirbaio:matrix.org> "portable-atomic" 1.4.0 released, includes the "unsafe-assume-single-core" Cargo feature
<re_irc>
<@dirbaio:matrix.org> so embedded usage no longer requires "RUSTFLAGS=--cfg=blahblah"
<re_irc>
<@adamgreig:matrix.org> yay
<re_irc>
<@dirbaio:matrix.org> so i'm going to deprecate "atomic-polyfill"
<re_irc>
<@adamgreig:matrix.org> "Originally, we were providing these as cfgs instead of features, but based on a strong request from the embedded ecosystem, we have agreed to provide them as features as well."
<re_irc>
<@dirbaio:matrix.org> non-embedded people scared at Cargo features that can trigger UB
<re_irc>
<@dirbaio:matrix.org> while in embedded, simply using a crate can trigger UB :D
<re_irc>
<@dirbaio:matrix.org> like, use a nrf hal in an stm32 chip
<re_irc>
<@dirbaio:matrix.org> not even a feature
<re_irc>
<@dirbaio:matrix.org> +cargo
<re_irc>
<@adamgreig:matrix.org> We know how to have fun, right
dc740 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
Dr_Who has quit [Ping timeout: 252 seconds]
<re_irc>
<@gvelim:matrix.org> I have purchased the ESP32-C3-DevKit-RUST-1 and I just found out the board holes are too small for the pin headers I have (and which are fitting fine any other MCU board I have). Have looked around for pin stripes with thinner pin size but had no luck. Would be grateful if someone could give me some pointers
Dr_Who has joined #rust-embedded
<re_irc>
<@mygnu:matrix.org> gvelim try looking for round pin headers they will fit
<re_irc>
<@metajack:matrix.org> About 2 years ago I was working on Daisy Seed project, which is STM32H750v based. I had a bunch of stuff working but got distracted by other things. I decided to dust this off and make another go at it, but now I'm having trouble getting anything working. I've gotten the blinky stm32h7xx-hal example working from that repo (after changing the led pin to be the right one), however I can't seem to get my old code working due...
<re_irc>
... to weird RTT errors. I figured I'd backtrack to getting a basic empty project set up and ran the steps from the knurling-rs/app-template instructions. That compiles but gives me:
<re_irc>
(HOST) INFO flashing program (7 pages / 7.00 KiB)
<re_irc>
(HOST) INFO success!
<re_irc>
Error: An ARM specific error occured.
<re_irc>
Timeout occured during operation.
<re_irc>
Caused by:
<re_irc>
<@metajack:matrix.org> Any ideas what could be going wrong?
<re_irc>
<@metajack:matrix.org> (that's with the included hello.rs example which just calls defmt::println!
dc740 has quit [Remote host closed the connection]
<re_irc>
<@avery71:matrix.org> Why couldn't arduino have gone and used some well supported chip, like something from ST
jr-oss has quit [Ping timeout: 245 seconds]
<Darius>
because they were unobtanium?
<re_irc>
<@avery71:matrix.org> I guess they did make an rp2040 board, so my comaining isn't fully accurate
<re_irc>
<@adamgreig:matrix.org> hm, the cortex-m ci thing seems to be a nightly regression where it looks for "ld" when told to use a specific linker binary
<re_irc>
<@adamgreig:matrix.org> i don't have enough nightlies installed to bisect this 😭 someone should have a VM that just has all the nightlies installed...
<re_irc>
<@adamgreig:matrix.org> well, sometime between 2023-07-01 and 2023-07-06
<re_irc>
<@adamgreig:matrix.org> but that looks like it would have been very useful lol
<re_irc>
<@adamgreig:matrix.org> but it seems very likely to me
<re_irc>
<@adamgreig:matrix.org> : does that work when you need a target like thumbv6m-none-eabi installed too?
<re_irc>
<@dirbaio:matrix.org> yep
<re_irc>
<@adamgreig:matrix.org> well it agrees on the first failing nightly but is it about to clone rust and then build it for each pr to check...
<re_irc>
<@adamgreig:matrix.org> this might take a while lol
<re_irc>
<@dirbaio:matrix.org> no, it downloads prebuilt artifacts from CI
<re_irc>
<@adamgreig:matrix.org> it was just taking ages to clone the repo to find the commit ranges, I see
<re_irc>
<@dirbaio:matrix.org> it still needs to clone the repo to search which PRs are merged between the nightlies. there's an option to make it use the github api instead
<re_irc>
<@adamgreig:matrix.org> got it, how slick
<re_irc>
<@dirbaio:matrix.org> yeah it's awesome
<re_irc>
<@adamgreig:matrix.org> well I should know soon. wonder if it will confirm my suspicion
<re_irc>
<@adamgreig:matrix.org> though given it's a big pr that handles linker arguments, and the error is to do with linker arguments, I have a pretty strong hunch
<re_irc>
<@adamgreig:matrix.org> it was indeed, no surprise there
<re_irc>
<@adamgreig:matrix.org> nice work cargo-bisect-rustc though
<re_irc>
<@adamgreig:matrix.org> new rustc adds ""-fuse-ld=lld"" to the linker arguments
<re_irc>
<@adamgreig:matrix.org> that can't help lol