Closed Bug 1472001 Opened Last year Closed Last year

cubeb-pulse-rs doesn't build with Rust Nightly

Categories

(Core :: Audio/Video: cubeb, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox63 --- fixed

People

(Reporter: kats, Assigned: kinetik)

Details

The searchfox indexing run today failed with this build error:

37:58.87    Compiling cubeb-pulse v0.2.0 (file:///index/mozilla-central/gecko-dev/media/libcubeb/cubeb-pulse-rs)
37:59.66 error[E0061]: this function takes 0 parameters but 1 parameter was supplied
37:59.66    --> media/libcubeb/cubeb-pulse-rs/src/backend/stream.rs:441:36
37:59.66     |
37:59.66 441 |                 let bytes = r_usec.to_bytes(&self.output_sample_spec);
37:59.66     |                                    ^^^^^^^^ expected 0 parameters
37:59.66 error[E0369]: binary operation `/` cannot be applied to type `[u8; 8]`
37:59.66    --> media/libcubeb/cubeb-pulse-rs/src/backend/stream.rs:442:20
37:59.66     |
37:59.66 442 |                 Ok((bytes / self.output_sample_spec.frame_size()) as u64)
37:59.66     |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
37:59.66     |
37:59.66     = note: an implementation of `std::ops::Div` might be missing for `[u8; 8]`
37:59.94 MOZSEARCH: /index/mozilla-central/gecko-dev /index/mozilla-central/analysis/ /index/mozilla-central/objdir/

It looks like the line at [1] is the problem, which makes sense because the get_time() function returns a Result<(u64)> and u64::to_bytes takes 0 arguments and produces a [u8; 8].

The weird thing is that this code has changed recently, so unless a rust nightly change started tripping over this I'm not sure why it just started failing. Also weird is that if you click on the to_bytes at [1], searchfox thinks it's calling the pulse::USecExt::to_bytes function. Presumably that's what it was doing before, and now it's calling u64::to_bytes? I don't really know.

Filing this bug because I have to head out soon and will be away until July 3rd so hopefully somebody else can look into it.

[1] https://searchfox.org/mozilla-central/rev/d2966246905102b36ef5221b0e3cbccf7ea15a86/media/libcubeb/cubeb-pulse-rs/src/backend/stream.rs#441
[2] https://searchfox.org/mozilla-central/rev/d2966246905102b36ef5221b0e3cbccf7ea15a86/media/libcubeb/cubeb-pulse-rs/pulse-rs/src/stream.rs#326
> The weird thing is that this code has changed recently

*hasn't* changed recently
I had seen warnings about this code with new rust nightly versions IIRC...
Ok, I did a local build with the latest rust nightly and it fails with the same error. So I guess this needs to be fixed in libcubeb somehow.

If that takes a while to fix we'll need to pin the version of rust that searchfox is using. I still have AMIs lying around using the mar-01 nightly version of rust which we should be able to use.

Steps to do that:
- log in to the AWS console and go to the AMI section for the EC2 resources
- delete the "indexer-16.04" and "web-server-16.04" AMIs
- then copy "indexer-16.04-pinned-mar01" to "indexer-16.04" and same for web-server

(you're not allowed to rename AMIs hence the delete+copy business. right now the indexer-16.04 AMI is a copy of the indexer-16.04-nightly AMI, which uses the latest nightly rust).
ni? to kinetik for the libcubeb bustage on nightly rust. I'm not sure who owns this and would be responsible for fixing it.
Flags: needinfo?(kinetik)
Simple fix is up at https://github.com/djg/cubeb-pulse-rs/pull/37
Flags: needinfo?(kinetik)
Pushed by mgregan@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e7986881407
Fix cubeb-pulse-rs build with current Rust nightly.  r=kamidphish
https://hg.mozilla.org/mozilla-central/rev/2e7986881407
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Assignee: nobody → kinetik
Component: Searchfox → Audio/Video: cubeb
Product: Webtools → Core
Summary: Indexing failure on Jun 28, perhaps caused by to_bytes resolving to something else → cubeb-pulse-rs doesn't build with Rust Nightly
You need to log in before you can comment on or make changes to this bug.