text:
Support [memo] attribute

We should support the [memo] attribute in the llvm backend. Essentially, we need a cache that maps from term to term and is really fast to look up and update. I think we should start by trying out std::unordered_map and then seeing if that provides adequate performance.
We don't currently have a use case for this, so it's not urgent, but I wanted to make an issue tracking it because it is necessary for performance in some cases.

@dwightguth is this still something we want to implement?
It seems like it should be easy enough to do if so, when we emit the code for evaluating a function symbol - wrap up the symbol and run-time arguments as the cache key, then look up the result / compute it and store in the cache. I presume the GC would also then need to know about the cache?

Yes, as a matter of fact, we are using it in KPlutus.
Em seg., 21 de nov. de 2022 às 13:23, Bruce Collie @.***>
escreveu:

@ChristianoBraga https://github.com/ChristianoBraga I think I recall
you were interested in this at some point. Is that still the case?
—
Reply to this email directly, view it on GitHub
https://github.com/runtimeverification/llvm-backend/issues/247#issuecomment-1322322958,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNNCEILY5VC3PVABQW6EO3WJOOXRANCNFSM4I6TW7BA
.
You are receiving this because you were mentioned.Message ID:
@.***>

If people would find value in it then yeah, it's absolutely fine to implement this.

Thanks both. I'll take a look at implementing for the LLVM backend given that it's being used.

authors: Baltoli ChristianoBraga dwightguth

repo: runtimeverification/llvm-backend


text:
[BUG] Sidebar sections don't auto expand on search.

Description
When we search on LinksHub, it displays the result. However, the sidebar accordion under which the result is present, does not expand unless we manually click and expand it. It should auto expand lest it delivers a bad UX.
Moreover, when we expand one section, it should not close the other one. The reason is same - bad UX.
Screenshots
https://github.com/rupali-codes/LinksHub/assets/73349037/21e09079-ba8f-4041-b8d1-0e5eaae87612
Any additional information?
No response
What browser are you seeing the problem on?
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[ ] I am a GSSoC'23 contributor

@shoebilyas123 I am a gssoc'23 contributor and I want to work on this issue.
Would you please assign it to me!?

@shoebilyas123 I am a gssoc'23 contributor and I want to work on this issue. Would you please assign it to me!?

Hey Isha, it's great to have you, but please read CONTRIBUTING guidelines carefully. When author of the issue is willing to work on the issue we can not assign the issue to anyone else. You can look for any other issue :)

@shoebilyas123 I am a gssoc'23 contributor and I want to work on this issue. Would you please assign it to me!?

Hey Isha, it's great to have you, but please read CONTRIBUTING guidelines carefully. When author of the issue is willing to work on the issue we can not assign the issue to anyone else. You can look for any other issue :)

Okay, No problem

Hello everyone, Just commenting that we don't go back and forth on this feature. Please read this issue #513 and the PR #669 that has been recently merged. This behavior was a feature request and not a bug. I still think that we should keep the only one tab normally but if search is enabled we can disable one tab behavior. @Isha988 @rupali-codes @shoebilyas123 . Please check it before merging.

Thank you! I'll make sure to check thoroughly before creating any issue,

Hello everyone, Just commenting that we don't go back and forth on this feature. Please read this issue #513 and the PR #669 that has been recently merged. This behavior was a feature request and not a bug. I still think that we should keep the only one tab normally but if search is enabled we can disable one tab behavior. @Isha988 @rupali-codes @shoebilyas123 . Please check it before merging.

Thanks

source: gharchive/issue

repo: rupali-codes/LinksHub

license: MIT

license_type: permissive

license_source: github-api


text:
If GameObject is disabled, copied hierarchy is also disabled

Hi, thanks for your awesome tools. I have just one problem that is easy reproduceable, but really annoying:
If I copy everything over from one avatar to the other, and there are disabled GameObjects, if those GameObjects have other Objects underneath them, they get copied, but get also disabled (but they are enabled in the source hierarchy).
That makes it really annoying if you use that for logic or similar things.
I hope it's not a limitation of the Tools, and just a bug :/
Cheers

tschaerni

Sounds like a bug. I might have overlooked this when I added code to disable game objects that were disabled at the source. It used to always copy everything as enabled. I'll try to fix this in the next update

Good to hear, I'm looking forward to your bugfix, because it's getting more and more annoying the more complex my Avatars become ;)
Cheers

tschaerni

Fixed. Will be out in the next update later today. Thanks!

Thanks!
You do a great job mate (:

authors: rurre tschaerni

repo: rurre/PumkinsAvatarTools


text:
Extract primitive parsers from generated code

When we generate rest-xml services, each service gets its own collection of primitive parsers/deserializers.  We could reduce the number of lines of code by extracting them to a common file and use those as needed.  Should help with https://github.com/rusoto/rusoto/issues/513 .
@adimarco 's comments:

I think we could put the primitive parsers in a non-codegen library in rusoto/src and just have the primitives in the codegen look like type MyStringyParser = rusoto::primitives::StringParser; and be done with it.

Per @adimarco there's some existing work in this area already in xmlutils.rs: https://github.com/rusoto/rusoto/blob/master/src/xmlutil.rs#L87

@adimarco is this completed in https://github.com/rusoto/rusoto/pull/541 ?

Sure is.

authors: adimarco matthewkmayer

repo: rusoto/rusoto

license: mit

license_source: bigquery


text:
fix: address Time::now deprecation warning

Removes the Time::now() deprecation warning in S3 integration tests.
Fixes #1716

Thank you!

source: gharchive/pull-request

authors: drexler iliana


text:
Remove use of feature flag in credentials that we don't use any more.

This should fix our broken nightly builds.

This change wasn't sufficient.
This issue should get it sorted: https://github.com/huonw/travis-cargo/issues/33 .

Personally I would re-instate a blank unstable feature instead, because that attribute is intended to ensure that we don't allow warnings on stable and beta, and I think it'd be best to keep it.
Adding an empty unstable = [] to the Cargo.toml should fix the problem.

Ah, my understanding of it wasn't nuanced enough.  I thought if we removed the line it'd enforce deny_warnings by default since that's probably what we want.
Added the feature back into the Cargo file.

Nightly is "fixed."  It's now failing on the well-know "out of memory" issue: https://github.com/rusoto/rusoto/issues/513 .


text:
Update libraries for rusoto_credential

It's intentional to use reqwest 0.6.2 instead 0.7, currently the latest version. Reqwest 0.6.2 is the last version that depends on Hyper 0.10, which is used by other rusoto_* packages. I think it's better to make them share the same version of Hyper to minimize compilation cost as possible.

Thanks for the PR!  I'm giving it a test now with cargo test --features all to run the integration tests. 😄

authors: Kroisse matthewkmayer


text:
Added automatic variables :)

Added automatic variables!

I'm sorry, buddy, but this doesn't work in current form. :(

authors: frankyn russellfolk


text:
thread '' panicked at 'index out of bounds: the len is 1 but the index is 1', crates/hir/src/semantics.rs:934:36

rust-analyzer version: 7a52f8370 2022-01-16 nightly
rustc version: rustc 1.60.0-nightly (ec4bcaac4 2022-01-15)
What's happening: VSCode keeps saying A request has failed. See the output for more information. when scrolling or triggering highlight in a file containg some code snippet.
Code to reproduce this:
#[cfg_attr(feature = "whatever", repr(C))]
#[derive(Clone)]
pub struct Test;

Backtrace:
[Error - 7:08:07 PM] Request textDocument/semanticTokens/full failed.
  Message: server panicked: index out of bounds: the len is 1 but the index is 1
  Code: -32603
Panic context:
>
version: 7a52f8370 2022-01-16 nightly
request: textDocument/semanticTokens/range SemanticTokensRangeParams {
    work_done_progress_params: WorkDoneProgressParams {
        work_done_token: None,
    },
    partial_result_params: PartialResultParams {
        partial_result_token: None,
    },
    text_document: TextDocumentIdentifier {
        uri: Url {
            scheme: "file",
            cannot_be_a_base: false,
            username: "",
            password: None,
            host: None,
            port: None,
            path: "************",
            query: None,
            fragment: None,
        },
    },
    range: Range {
        start: Position {
            line: 0,
            character: 0,
        },
        end: Position {
            line: 7,
            character: 0,
        },
    },
}

thread '<unnamed>' panicked at 'index out of bounds: the len is 1 but the index is 1', crates/hir/src/semantics.rs:934:36
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_bounds_check
   3: hir::semantics::SemanticsImpl::resolve_derive_ident
   4: ide::syntax_highlighting::highlight::token
   5: ide::syntax_highlighting::highlight
   6: std::panicking::try
   7: rust_analyzer::handlers::handle_semantic_tokens_range
   8: std::panicking::try
   9: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Information maybe useful:
This panic only happens when #[cfg_attr] is placed in front of a #[derive]. If the order is reversed then everything works. I also found a colorized tokenization difference:

#[derive] is placed in front of #[cfg_attr]. Everything works and VSCode's Inspect editor tokens and scopes works properly.

#[cfg_attr] is placed in front of #[derive]. This will cause a panic and Inspect editor tokens and scopes does not work either.

Ah, ye this seems to happen with cfg_attrs that have their feature flag not set, that brings indices out of order in a specific code path...

Ye the problem is this here https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/hir_def/src/attr.rs#L87-L93
we index via the ast_index into the attribute slice, but the attribute slice doesn't contain the attributes behind a cfg_attr if they a disabled obviously

The panic was fixed by https://github.com/rust-analyzer/rust-analyzer/pull/11334

authors: Veykril f32by jonas-schievink

repo: rust-analyzer/rust-analyzer


text:
record struct defined in function is invisible to type inference

fn main() {
    struct My {
        field: i32
    }

    let v = [My { field: 0 }];
}

If we move the definition of My above main, or make My a tuple or unit struct, type inference works.
rust-analyzer version: 2020-07-20 (c9c518e)

Duplicate of https://github.com/rust-analyzer/rust-analyzer/issues/1559.

authors: crumblingstatue lnicola


text:
Normalize associated types in types coming from Chalk

Fixes #3232.

I should actually apply the snapshot :man_facepalming:

bors merge

authors: flodiebold matklad


text:
internal: prepare for lazy diagnostics

bors r+
🤖

Is this going to use the proposed LSP pull model?

No, that's just exiting ability to defer computation of edits for code actions. I probably should look into the pull model though, yeah.

authors: kjeremy matklad


text:
Automated daily update to rustc (to nightly-2024-07-28)

Automated update to Github CI workflow rust.yml by create-pull-request GitHub action

Pull Request Test Coverage Report for Build 10136612573
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 83.192%

Totals

Change from base Build 10134789758:
0.0%

Covered Lines:
19660

Relevant Lines:
23632

💛  - Coveralls

authors: apoelstra coveralls

repo: rust-bitcoin/rust-bitcoin


text:
Use ryu for float serialization

... supposedly pulling in the advantages of ryu (speed, code size?) over core::fmt.
The bigger and likely more valuable task would be deserialization and replacing ::from_str by something else. As mentioned in #12, last time I tried, lexical_core's atof wasn't easy.

Ok, could you add an entry to the changelog, squash all commits into one and rebase to the master branch?

authors: eldruin jordens

repo: rust-embedded-community/serde-json-core


text:
Rewrite ch09

This PR is not quite done yet it's still missing magnitutde and calibration. However there is a thing that is confusing me. Both take 1 and 2 work perfectly on the micro:bit v2. On my micro:bit v1 however the X value of the magnetometer always stays negative...is this a mistake from my side or do I have to calibrate it?

:warning: Warning :warning:

Pull requests are usually filed against the master branch for this repo, but this one is against rewrite. Please double check that you specified the right target!

I don't think its related to orientation or something...I turned 360 degrees around with the micro:bit v1 and the x values kept staying always negative which does not make sense at all...something weird is going on with the chip here.

I don't think its related to orientation or something...I turned 360 degrees around with the micro:bit v1 and the x values kept staying always negative which does not make sense at all...something weird is going on with the chip here.

Depending on the version of v1 you are using you might have a different magnetometer, although most likely your program shouldn't work at all in that case.
But since V1.3 is using a Freescale MAG3110 ( https://tech.microbit.org/hardware/1-3-revision/#magnetometer ), we should maybe make it clear that only v1.5 and v2 are supported here or that another feature needs to be enabled to use the mag3110 lib instead?

The main issue here is with the calibration of the magnetometer on the micro:bit, depending on how its configured per default the values it outputs can wildly differ from other once which is why it should be properly calibrated in your current location before using it. I did that in MicroPython with the default micro:bit stuff and that got me quite accurate results so next step is to port that to Rust which is what I'm on at the moment.

The code is now in a working state (along with the calibration)
There is one thing I am not quite sure yet, the magnitude of the magnetig field. The docs of the lsm303 crate as well as its datasheet agree that the data being outputted is in milli gauss so so the magnitude of the field vector should be in milli gauss as well. However the values are too large by that by the factor of 100 (which is exactly the conversion factor from nano tesla to milli gauss). The micro:bit original driver code notes that they calculate the magnitude in nano tesla and trying it out on my microbit they produce almost identical values so it would seem the values are being measured in nano tesla?
Since I more or less blindly took over the micro:bit calibration code maybe the conversion is coded somehwere in there as well, I am not 100% certain about that yet.
It would be very nice if someone could verify I translated the calibration code correctly and also clear up the unit question regarding nano tesla or milli gauss.
Apart from that (minus the merge conflicts) this should be ready to review and then merge.

Is this ready for merge now, then?

We'd have to update the link to the lsm303agr docs that I use to justify the nT since its still saying mG but we can do that after your new minor release as well so basically yeah ready to merge and then I'll just have to clean it up once the release is there.

Now its mergable.

authors: caemor eldruin hargoniX rust-highfive

repo: rust-embedded/discovery


text:
Some questions regarding this project.

Hi I have some questions regarding this project.
Is this a "write once run everywhere" project? That means that if I write code for the Arduino, the exact same code would work on a Raspberry Pi, for example if I wanted to make an LED blink I can use the exact same code, the only difference is that the binary output after compiling would be very different between the two devices?
If I had to different Arduino models, would the code be exactly the same?

The code will not be exactly the same, you have different device initialization on each devices.
This crate provide common traits to write generic code. It's mainly useful when writing drivers.
For example, if you want to make a driver "Led", you need one pin, this pin will be "PA1" on stm32, "D13" for arduino, ..., but your driver can be generic on "OutputPin".
For example this driver is compatible with all crates that provide the traits from embedded-hal :
struct Led<P: OutputPin> {
    pin: P
}

impl<P: OutputPin> Led<P> {
    fn new(pin: P) -> Self {
        Self {
            pin,
        }
    }

    fn on(&mut self) {
        self.set_high();
    }

    fn off(&mut self) {
        self.set_low();
    }
}```

struct Led<P: OutputPin> {
pin: P
}
impl<P: OutputPin> Led {
fn new(pin: P) -> Self {
Self {
pin,
}
}
fn on(&mut self) {
    self.set_high();
}

fn off(&mut self) {
    self.set_low();
}

}```
So if I wrote this for both the Arduino and Raspberry Pi, this code can remain exactly the same to control an LED, am I understanding you correctly?

This part of code yes, but the way you have to initialize the GPIO no

@Fomys Hey man sorry for the late reply.
So in regards to a blinking led program for both a raspbierry pi pico and arduino.
Here is an example of avr/arduino
    loop {
        led.toggle();
        arduino_hal::delay_ms(100);
        led.toggle();
        arduino_hal::delay_ms(100);
        led.toggle();
        arduino_hal::delay_ms(100);
        led.toggle();
        arduino_hal::delay_ms(800);
    }

And an example for the raspberry pi pico
    loop {
        led_pin.set_high().unwrap();
        // TODO: Replace with proper 1s delays once we have clocks working
        delay.delay_ms(500);
        led_pin.set_low().unwrap();
        delay.delay_ms(500);
    }

as you can see they are different. Is there a way they can be written generically?

Your snippets don't do exactly the same thing.
Both of the crate you linked already implements traits from embedded-hal, but not the same version, so it is not possible to make generic code. You can try to bump the version in avr-hal to make have the same version.
If the both crates uses the same embedded-hal version you can create this kind of generic function:
fn blink_loop<P: OutputPin>(led: P) {
    loop {
        led.setHigh().unwrap();
        for _ in 0..1000000 {}
        led.setLow().unwrap();
        for _ in 0..1000000 {}
    }
}

And in your executable:
fn main() {
    // ... specific code for your target board
    let led = /* specific code for your target board */ .into_push_pull_output();

    blink_loop(led);
}

The first method is generic, so you can use it with anything that implement the traits from embedded-hal crate.

Right, so like what does toggle() do compared to set_high()/set_low() don't they both turn on and off the pin?
They both blink the leds, but not at the same speed. toggle() means "change the output state to the oposite one"
Another question, does embedded-hal support as many various gpio sensors/devices (such as LED, ultrasonic sound distance sensor etc) as the Arduino IDE code/library does?
I think not, but you can search on crates.io if someone already write a driver for your device.

You may be able to find even more HAL implementation crates and driver crates by searching for the keywords embedded-hal-impl, embedded-hal-driver and embedded-hal on crates.io.

Right i see thanks mate :)

The original question seems solved. Thanks @Fomys! Closing.

authors: Fomys Raj2032 eldruin

repo: rust-embedded/embedded-hal


text:
ERROR: __sanitizer_reset_coverage is not defined. Exiting.

Starting at some point in the past month or so, I am no longer able to run cargo fuzz. For example, with https://github.com/rust-fuzz/targets:
$ cargo fuzz --version
cargo-fuzz 0.5.2
$ rustc -vV
rustc 1.25.0-nightly (3ec5a99aa 2018-02-14)
binary: rustc
commit-hash: 3ec5a99aaa0084d97a9e845b34fdf03d1462c475
commit-date: 2018-02-14
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 6.0
$ ./run-fuzzer.sh httparse parse_request
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `/home/dwrensha/src/rust-fuzz-targets/target/x86_64-unknown-linux-gnu/debug/parse_request /home/dwrensha/src/rust-fuzz-targets/httparse/corpus /home/dwrensha/src/rust-fuzz-targets/httparse/seeds`
WARNING: Failed to find function "__sanitizer_get_total_unique_coverage".
WARNING: Failed to find function "__sanitizer_reset_coverage".
INFO: Seed: 3689636734
ERROR: __sanitizer_reset_coverage is not defined. Exiting.
Did you use -fsanitize-coverage=... to build your code?

My guess is that this is related to the recent LLVM update: https://github.com/rust-lang/rust/pull/47828

Relevant issue and pull request. I haven't had much time to review them though...

https://github.com/rust-fuzz/libfuzzer-sys was just updated to support LLVM6 which should fix this issue. so just do a cargo update in the same dir as the cargo.toml that specifies libfuzzer-sys, probably fuzz/

Thanks!

authors: dwrensha frewsxcv

repo: rust-fuzz/cargo-fuzz


text:
breaking change introduced in 0.7.1

See: https://github.com/Gekkio/imgui-rs/issues/42#issuecomment-279703432
In particular, it looks like https://github.com/rust-lang-nursery/bitflags/commit/67e4485d20ac79128843fb14abd3e8df742fcfae introduced a new set method that can break consumers if they had defined their own set method.
Perhaps we can yank 0.7.1 and release 0.8?

Sorry for the breakage!

Could we yank 0.8 and think again about how to do u128 support correctly? 0.8 includes a major regression where types that are locally imported cannot be used anymore as the flags type. This has already been broken in the past, and it would be nice if it didn't come back. Cf. https://github.com/rust-lang-nursery/bitflags/pull/51.

Never mind, I didn't notice that the commit that broke that was reverted in the very same PR that introduced it.

authors: BurntSushi alexcrichton nox

repo: rust-lang-nursery/bitflags


text:
Added clippy support to bitflags, and cleaned up some lints

Ran across some lints in another project that depends on bitflags.  Couldn't get them allowed easily, so added clippy as an optional dependency here and cleaned up the lints.

@CraZySacX - is this pull request in the state that you intended?  It looks as though it contains a bunch of changes not meant for this repository eg renaming the crate...

It is not, forgot to close this.

authors: CraZySacX dimbleby


text:
If rename fails, try to copy.

Fix #2.
r? @glandium

So this seems fine, but maybe we should use a different location for TempDir? We could create it somewhere in ~/.rustup which would avoid this problem entirely (and probably make the tool faster, generally speaking).
This looks fine though at least as a stop-gap.

Could not move tempdir into destination: the source path is not an existing regular file

@Mark-Simulacrum Yes, looks like using ~/.rustup/tmp/ (which already exists) is a better solution.

r? @glandium again.
Now we use ~/.rustup/tmp to store the temporary files as suggested in https://github.com/rust-lang-nursery/cargo-bisect-rustc/pull/4#issuecomment-375497759.

This works properly. You may also want to add something that cleans up those files when bisect-rustc is interrupted with ctrl-c.

Thanks for checking @glandium 🙂. Installing a signal handler for Ctrl+C would be a big feature, please file another issue for this.

authors: Mark-Simulacrum glandium kennytm

repo: rust-lang-nursery/cargo-bisect-rustc


text:
Update to new futures_api

This PR covers changes by https://github.com/rust-lang/rust/pull/59119 and https://github.com/rust-lang/rust/pull/59733.
cc #1518 (I initially intended to close it with this PR, but in fact it might be better to close it when the next version is released.)

Is there an ETA when we could land this? The changes have landed in the latest nightly, and currently a good amount of packages are broken until we can land this.

(Landing it now does not mean that we can immediately release the next version.)

Also, https://github.com/rust-lang/rust/pull/59733 is already approved, so It will break again in a few days.

Possibly a ignorant question, but would this fix land (pending time/availability from people, naturally) when/if https://github.com/rust-lang/rust/commit/df25d79a33b0c82b716699a75a41bfdc6089850a is part of a nightly release?

@cramertj @Nemo157 Could you review this PR?
Considering FCP takes more than a week, I think that it is preferable to land this at this timing.

Updating to nightly today still gave me another error:
error[E0507]: cannot move out of borrowed content
   --> /futures-rs/futures-core/src/task/__internal/atomic_waker.rs:244:17
    |
244 |                 waker.wake();
    |                 ^^^^^ cannot move out of borrowed content

Not entirely sure that this should be dealt with in this pull request, but I think it's because of the waker by ref last minute changes before stabelization. Cloning it here was my fast braindead fix, but I don't know whether that's the best way to solve this.

@najamelan See https://github.com/rust-lang-nursery/futures-rs/pull/1514/commits/265ca12195c56e7e6b3968b58ce659dc1c3c7736.

@taiki-e Oh, sorry, you're awesome. I had missed the extra commit... compiles fine. Thanks

(for others that want to start experimenting off this, here's a block you can copy-paste into your Cargo.toml to set all the overrides):
[patch.crates-io]
futures-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-core-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-util-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-sink-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-channel-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-executor-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-io-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }
futures-test-preview = { git = "https://github.com/taiki-e/futures-rs", branch = "futures_api" }

Thanks again :heart:, hopefully we can get a release out soon with these fixes in (maybe even one worth promoting to beta).

Thanks for working to get this landed! All the help is extremely appreciated. I'll get a new release out ASAP.

@cramertj Could you please take a look at #1524 at first? google/tarpc may miss the new release otherwise.

@vorot93 merged! :) (In the future, cc'ing me or adding me as a reviewer will get my attention quicker, though I try to scan the repo for PRs every once in a while)

authors: Nemo157 cramertj davidbarsky najamelan taiki-e vorot93 yoshuawuyts

repo: rust-lang-nursery/futures-rs


text:
Change set_logger to panic on error

There might be more things to fix. But just wanted to get feedback if I am on right track!
Fix to issue #146

I don't understand what am I doing wrong in this function due to which the build fails.
In env/lib.rs:
pub fn init(&mut self) {
let logger = self.build();
let filter = logger.filter();
let logger = Box::new(logger);
log::set_logger(logger, filter);
}
It seems correct to me.

@alisha17 the builder actually points to line 397, which is in the Logger::init function, not your new Builder::init function. That function expects Builder::init to return a Result, though, and now it just returns a ().
Not sure what the preferred fix is: maybe Logger should get the same treatment the Builder did (try_init and init)?
@brson probably knows better than me

I agree with @mrhota.

The build is failing. The commit here and the commit in the build do not match. They are different. Is it possible that the test is not triggered for this commit?

Indeed, both Travis and AppVeyor seem stunningly confused, and I can't seem to unconfuse them.

@brson  Should I create an entirely new PR for this issue?

No I don't think that will help. I pushed an empty PR to your branch to get the CI to test the new commit. If the tests succeed we can remove that commit again and merge.

@alisha17 OK, I understand what's happening.
The CI on this repo seems to be set up to merge with master before testing. If you look at the commit it tested, one of the parents is your commit.
The errors it is reporting are legit. Something on master has invalidated one of the test cases when merged with your branch.
What you need to do is rebase your branch on top of the master branch, run the test suite again and fix that error, then force push back to your setlogger branch.
The rebase commands will look something like
git fetch origin
git rebase origin/master
... fix tests ...
git push alisha17 HEAD:setlogger

Here's some documentation about git rebasing if you are not familiar: https://www.atlassian.com/git/tutorials/rewriting-history

Okay. Done with the rebasing.
When I run the test suite, all tests do pass. It shows no error(with the current commit changes).

@alisha17 You'll need to do a force push to your 'setlogger' branch so that it shows up on this PR.

@brson when I force push to my setlogger branch, it shows 'Everything up-to-date'.

@alisha17 hm, if your local branch is rebased on upsteam master, then pushing to your setlogger branch shouldn't say everything is up to date. Your branch is on 088c5eb, and that is a descendant of a commit from May.
Here's what I see when I rebase your branch and run cargo test: https://gist.github.com/brson/a881e26af9b71b2d4cc981a72944dbb7
I get the same failure as travis does.

This lgtm now. @sfackler are breaking changes like this ready to be merged in now, or do they need to wait until you are ready for a version bump?

Let's just merge all of the breaking stuff into master - we'll cut an 0.3.x branch off of the last release to do the back compat stuff.

OK, as far as I can tell this looks right, so I'm merging it. Thanks for your perseverance @alisha17!

authors: alisha17 brson mrhota sfackler

repo: rust-lang-nursery/log


text:
Mention the literal macro matcher

This feature will soon stabilize in https://github.com/rust-lang/rust/pull/56072.

https://github.com/rust-lang/rust/pull/56072 got merged.
@ehuss I didn't fully understand your comments, but I tried to improve upon the former changes anyway. Perhaps you can pick up from there.

Thanks! :smile:

authors: da-x ehuss

repo: rust-lang-nursery/reference


text:
Many configuration options are "only available in nightly channel"

Just updated to 0.2.17:
>cargo fmt
Warning: can't set `fn_single_line = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports_in_group = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imported_names = true`, unstable features are only available in nightly channel.
Warning: can't set `match_block_trailing_comma = true`, unstable features are only available in nightly channel.
Warning: can't set `use_try_shorthand = true`, unstable features are only available in nightly channel.
Warning: can't set `fn_single_line = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports_in_group = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imported_names = true`, unstable features are only available in nightly channel.
Warning: can't set `match_block_trailing_comma = true`, unstable features are only available in nightly channel.
Warning: can't set `use_try_shorthand = true`, unstable features are only available in nightly channel.
Warning: can't set `fn_single_line = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports_in_group = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imported_names = true`, unstable features are only available in nightly channel.
Warning: can't set `match_block_trailing_comma = true`, unstable features are only available in nightly channel.
Warning: can't set `use_try_shorthand = true`, unstable features are only available in nightly channel.
Warning: can't set `fn_single_line = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports_in_group = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imported_names = true`, unstable features are only available in nightly channel.
Warning: can't set `match_block_trailing_comma = true`, unstable features are only available in nightly channel.
Warning: can't set `use_try_shorthand = true`, unstable features are only available in nightly channel.
Warning: can't set `fn_single_line = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imports_in_group = true`, unstable features are only available in nightly channel.
Warning: can't set `reorder_imported_names = true`, unstable features are only available in nightly channel.
Warning: can't set `match_block_trailing_comma = true`, unstable features are only available in nightly channel.
Warning: can't set `use_try_shorthand = true`, unstable features are only available in nightly channel.

If this is intended, I'd like to see some mention of what features are and aren't "nightly" at Configurations.md, as well as how to enable "nightly" execution mode.

OK, I found #1998. Going to write up and PR a patch so that Configurations.md mentions this.

Going to write up and PR a patch so that Configurations.md mentions this.

That would be great, thanks!

@nrc I'm really confused by #1998. To me it looks like a breaking change that should have been released as 0.3.

I filed https://github.com/rust-lang-nursery/rustfmt/pull/2232 for the options that already exist in the stable version of rustfmt.

To me it looks like a breaking change that should have been released as 0.3.

I guess it probably should. OTOH, pre-1.0, semver is more of a guideline than a rule.

I guess it probably should. OTOH, pre-1.0, semver is more of a guideline than a rule.

It is not in Cargo. With 0.y.z versions, y is the major version and z the minor. A foo = "0.2" dependency will not select a 0.3.z version.

I can't see to get them to work. rustup run nightly cargo fmt -- --unstable-options tells me that it didn't recognize the last argument (looks like it fails to pass stuff after -- to rustfmt as it states in its help message); rustup run nightly rustfmt --write-mode=overwrite --unstable-features src/lib.rs tells me that unstable features are only available on the nightly channel (which I'm clearly on).

Same here

It appears that unless you compile rustfmt with the CFG_RELEASE_CHANNEL set, you will never be able to use --unstable-features due to the code at https://github.com/tmahmood/rustfmt/blob/685c9d332fe728e58ccf1bb6df5c096faaa3c172/src/bin/rustfmt.rs#L72-L81
        let rust_nightly = option_env!("CFG_RELEASE_CHANNEL")
            .map(|c| c == "nightly")
            .unwrap_or(false);
        if unstable_features && !rust_nightly {
            return Err(FmtError::from(format!(
                "Unstable features are only available on Nightly channel"
            )));
        } else {
            options.unstable_features = unstable_features;
        }

option_env! is a compile time check so if CFG_RELEASE_CHANNEL is not set, it'll default to None, which will set rust_nightly to false at compile time.
I don't know if cargo sends that env var to rustc at compile time, but my hunch is that it doesn't, as I compile rustfmt with nightly and am also experiencing this issue.
IMO, unstable features should be hidden behind a compile time feature flag rather than a command line switch.  I also briefly looked for an easy way to check if you are running nightly at runtime, but was unable to find one.  I'm working on a PR with a quick fix (option_env! -> std::env::var) which should allow you to set CFG_RELEASE_CHANNEL before running rustfmt and use unstable features.

-- in cargo fmt seems to only be correctly handled when used via cargo +nightly fmt and not rustup run nightly cargo fmt.

Looks like I missed some open PRs on this #2228, #2249.   I've also put in a PR that changes the behavior to a runtime check (#2259).    My local build works now running cargo fmt -- --unstable features.  I also cannot get the rustup run nightly cargo fmt -- --unstable-features command to work.

This is quite a thing to find! Since I have everything defaulting to nightly, CFG_RELEASE_CHANNEL is never set. I guess for now we should just recompile rustfmt setting CFG_RELEASE_CHANNEL manually?

@YaLTeR @Eijebong @CraZySacX @daboross
I updated the OP here such that it should be clearer what the situation is here.
The TL;DR of it is that on 0.2.17 (current crates.io version), you need to set the environment variable CFG_RELEASE_CHANNEL to nightly. Then, you can either cargo +nightly fmt -- --unstable-features or just set unstable_features=true in your rustfmt.toml and cargo +nightly fmt.
Once a new build is published, you will no longer need to set CFG_RELEASE_CHANNEL at runtime, and it will be a compile time check. If #2249 is merged, you will be able to set unstable features when building with cargo, and if not, CFG_RELEASE_CHANNEL will need to be set when building rustfmt in order to enable unstable features.
IMHO, @nrc, we should yank 0.2.17 (since it had breaking changes, disabling configuration options), merge #2249 ASAP, and publish a new build as 0.3.0.

OK #2249 is merged and I've released 0.3.0 with the change. Hopefully things should be fixed with that. I'm not sure about yanking 0.2.17, it is pretty broken, but only if you're using unstable options, which should obviously have a weaker 'breaking changes' guarantee.

authors: CAD97 CraZySacX Eijebong YaLTeR daboross nox nrc

repo: rust-lang-nursery/rustfmt


text:
Add an unstable --output-format option to cargo rustdoc

Problem
rustdoc (on nightly) exposes an --output-format option to choose the format of the generated documentation: either HTML (the default) or JSON (the new unstable backend).
If you choose the JSON format, the output file of the unit is no longer /target/doc/<crate_name>/index.html; it becomes /target/doc/<crate name>.json.
Since there is no way to specify the output format as an option of cargo rustdoc itself, cargo assumes that the only possible output path for a doc unit is the HTML one. As a consequence, the JSON output is never considered "fresh" and we miss out on caching (see the test case in #12100, which fails on master).
Proposed Solution
Since cargo must remain unaware of the semantics of rustdoc's extra arguments, I suggest we add --output-format as an unstable cargo rustdoc argument, mimicking the semantics of the underlying --output-format option for rustdoc.
This would allow cargo to reason about it and take it into account in the fingerprinting logic.
Notes
No response

It might be good to list all the concerns that need to be considered for this. For example:

What happens with --open? Does that generate an error?
Is there any interaction with -Z rustdoc-scrape-examples? Does the JSON include the scraped data? Or should scraping be disabled when generating the JSON?
This mentions adding it to cargo rustdoc, would it also be added to cargo doc? If not, is there a reason?

If we do add this to cargo doc, would it also generate JSON files for all the dependencies?

Overall seems like a reasonable flag to add to me.

@obi1kenobi since you rely on rustdoc's output format, I'm curious on your thoughts on this issue.

Thanks for the ping @epage. I'm strongly in favor of this. It's a reasonable feature to have, and from my perspective, improving the rustdoc JSON cache hit rate is extremely worth it. Thanks to @LukeMathWalker for figuring this out.
Anything that improves rustdoc JSON performance would be hugely impactful for cargo-semver-checks, since that's by far the "long pole" in its perf graph right now.
For context, cargo-semver-checks v0.20 shipped a massive perf improvement: 109x faster checking time in tokio, 2354x in aws-sdk-ec2, etc. We've also added caching of the "baseline" rustdoc JSON which gives us another 2x speedup on top of those numbers.
Since we've significantly reduced the time taken by all the other steps, the "current" version's rustdoc JSON generation is easily 70-80% of cargo-semver-checks wall-clock time right now. In turn, our users report that cargo-semver-checks even after the optimizations can be up to 50% of their total CI time

the JSON filename is the crate name

This is ever so slightly imprecise, the filename is the lib target's name with all - chars turned into _. This bit cargo-semver-checks recently so I'm bringing it up so it doesn't bite anyone else.

-Z rustdoc-scrape-examples

I believe the JSON does not have an ability to include examples. It only includes doc comments that are explicitly set on items. For the time being, scraping can be disabled. I have no opinion at the moment on whether rustdoc JSON should include examples, and I think it's fine to decide on that later since the JSON format is unstable anyway.

--open

I'm fine with attempting to open the JSON file with the user's default viewer (mine would be VSCode), falling back to the browser if no default viewer is available. If this is complex to achieve on day 1, I'm also fine with this being an error for now.

cargo doc

Totally fine with adding it there too, it makes sense to me.

Is there any concern here that remains to be addressed? Or should we start sketching the implementation?

Most concerns seem to be answered. I got some minor questions here: How stable is the rustdoc JSON output? Does it make sense that a user wants to keep different versions of JSON output at the same time?
Apart from these trivial questions, I feel like the flag isn't something that cannot be rolled back, and It also won't affect major build workflow of Cargo. Thus I am happy to discuss the design and implementation.

How stable is the rustdoc JSON output? Does it make sense that a user wants to keep different versions of JSON output at the same time?

It is versioned (via the format_version field), but a specific rustdoc build can only emit a single version of the output.
Supporting multiple versions is primarily a "client-side" concerns, if you want your tool to be able to work across multiple nightly releases (e.g. what @obi1kenobi does for cargo-semver-checks).

Let's do a quick poll before starting.
@rfcbot fcp merge
Proposed solution

Since cargo must remain unaware of the semantics of rustdoc's extra arguments, I suggest we add --output-format as an unstable cargo rustdoc argument, mimicking the semantics of the underlying --output-format option for rustdoc.
This would allow cargo to reason about it and take it into account in the fingerprinting logic.

So long as this is unstable, I have no concern with this.  Once we have it,. it'll then also make it easier to explore the benefits and challenges with making it stable (assuming the rustdoc flag is stable)

There is no need to wait util FCP ends. People interested in doing it can start. The Cargo Team may not have a large capacity to mentor but for the review part we'll try our best.

I'll get started next week then 👍🏻 Thanks!

I'll get started next week then 👍🏻 Thanks!

Hi @LukeMathWalker , were you able to start working on this?

No, a few other things had to take priority.

No, a few other things had to take priority.

Can other folks(including me) give it a try? Else I believe it's better to assign it to yourself.

@rustbot claim

@obi1kenobi @LukeMathWalker
The --output-format flag for cargo rustdoc is available on nightly. It would be much appreciated if you can provide feedback on the cache story, or other UX issues :)

authors: LukeMathWalker charmitro ehuss epage obi1kenobi weihanglo

repo: rust-lang/cargo


text:
error: failed to run custom build command for wasmtime-runtime v8.0.1

Problem
Not able to build the rust application using the command "cargo build --bin test-app".
After adding this crate subxt to the cargo.toml.
Steps
1)adding this crate subxt to the cargo.toml.
2)cargo build --bin test-app
3) error.
Possible Solution(s)
Probably the subxt crate has something that is confusing the compiler.
Notes
This is an test application for a ESP32-c6 microcontroller. We are using the esp-idf-hal.
We have the test-app code in here.
Version
cargo 1.75.0-nightly (794d0a825 2023-10-03)
release: 1.75.0-nightly
commit-hash: 794d0a82547f3081044c0aca7b6083733ce51344
commit-date: 2023-10-03
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.3.0-DEV (sys:0.4.66+curl-8.3.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Ubuntu 22.04 (jammy) [64-bit]

Error
Running `/home/silveira/bluefreedom/test-app/target/debug/build/wasmtime-runtime-af8c978cc181d296/build-script-build`
The following warnings were emitted during compilation:

warning: cc: error: unrecognized argument in option ‘-mabi=ilp32’
warning: cc: note: valid arguments to ‘-mabi=’ are: ms sysv
warning: cc: error: unrecognized argument in option ‘-mcmodel=medany’
warning: cc: note: valid arguments to ‘-mcmodel=’ are: 32 kernel large medium small

error: failed to run custom build command for `wasmtime-runtime v8.0.1`

Caused by:
  process didn't exit successfully: `/home/silveira/bluefreedom/test-app/target/debug/build/wasmtime-runtime-af8c978cc181d296/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=src/helpers.c
  TARGET = Some("riscv32imac-esp-espidf")
  OPT_LEVEL = Some("z")
  HOST = Some("x86_64-unknown-linux-gnu")
  cargo:rerun-if-env-changed=CC_riscv32imac-esp-espidf
  CC_riscv32imac-esp-espidf = None
  cargo:rerun-if-env-changed=CC_riscv32imac_esp_espidf
  CC_riscv32imac_esp_espidf = None
  cargo:rerun-if-env-changed=TARGET_CC
  TARGET_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  RUSTC_LINKER = Some("ldproxy")
  cargo:rerun-if-env-changed=CROSS_COMPILE
  CROSS_COMPILE = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("a,c,m")
  cargo:rerun-if-env-changed=CFLAGS_riscv32imac-esp-espidf
  CFLAGS_riscv32imac-esp-espidf = None
  cargo:rerun-if-env-changed=CFLAGS_riscv32imac_esp_espidf
  CFLAGS_riscv32imac_esp_espidf = None
  cargo:rerun-if-env-changed=TARGET_CFLAGS
  TARGET_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None
  running: "cc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-march=rv32imac" "-mabi=ilp32" "-mcmodel=medany" "-Wall" "-Wextra" "-DCFG_TARGET_OS_espidf" "-DCFG_TARGET_ARCH_riscv32" "-o" "/home/silveira/bluefreedom/test-app/target/riscv32imac-esp-espidf/debug/build/wasmtime-runtime-d75f6ee2ec7ef9d7/out/src/helpers.o" "-c" "src/helpers.c"
  cargo:warning=cc: error: unrecognized argument in option ‘-mabi=ilp32’

  cargo:warning=cc: note: valid arguments to ‘-mabi=’ are: ms sysv

  cargo:warning=cc: error: unrecognized argument in option ‘-mcmodel=medany’

  cargo:warning=cc: note: valid arguments to ‘-mcmodel=’ are: 32 kernel large medium small

  exit status: 1

  --- stderr

  error occurred: Command "cc" "-Os" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-march=rv32imac" "-mabi=ilp32" "-mcmodel=medany" "-Wall" "-Wextra" "-DCFG_TARGET_OS_espidf" "-DCFG_TARGET_ARCH_riscv32" "-o" "/home/silveira/bluefreedom/test-app/target/riscv32imac-esp-espidf/debug/build/wasmtime-runtime-d75f6ee2ec7ef9d7/out/src/helpers.o" "-c" "src/helpers.c" with args "cc" did not execute successfully (status code exit status: 1).

warning: build failed, waiting for other jobs to finish...

Your C compiler (cc) was complaining. Just reading the log. It doesn't seem like an issue caused by Cargo. Do you have specific thoughts in mind that made you open an issue against Cargo project instead of those crates (subxt or wasmtime-runtime)?

Fair enough

authors: blue-freedom-technologies weihanglo


text:
Point out which version failed to error

Given this Cargo.toml:
[package]
name = "foo"
version = "1.2.3"
authors = []

[dependencies]
plugin = "0.2*"

You get this error:
$ cargo build --verbose
error: failed to parse manifest at `/home/steve/tmp/lol/Cargo.toml`

Caused by:
  you have already provided an operation, such as =, ~, or ^; only use one

Now, there's two things that aren't great about this error. First, the text isn't as helpful as it could be, but that's just Cargo passing on the messages semver is giving, so that's not Cargo's fault. But what Cargo could do in this instance is say exactly which version failed to parse.
In this case, the actual Cargo.toml was huge, with a ton of dependencies, and it took a sharp eye to notice that it should have been 0.2.*. If it had pointed out which version failed, it would have been a lot easier.

Should be a pretty easy bug too! Just a chain_error needs to be somewhere in the util/toml.rs parsing code most likely

Looks like it might be with PackageId's constructor. Checked the version decoder for TomlVersion and iron's plugin dependency version was never listed.
Currently hacking on this, but running out of time for the day. I don't really understand the chain_error business or if it's applicable when calling from to_package_id

Hm maybe yeah! Probably good in any case to bolster up error reporting there anyway :)
I think though that this is probably coming from Dependency::parse where the VersionReq is parsed

Should the increased strictness of the semver parser be considered a breaking change? I have a project with Iron 0.3.0 in Cargo.lock that builds on stable but fails to build on nightly with this error.
For anyone uses Iron 0.3.0 and finds this issue when searching for the error message, the fix is to update Iron to 0.3.1, which fixes the malformed version in its Cargo.toml.

There's already discussion of that in another bug. I'd link but I'm on mobile.
From SemVer's perspective, this is a bugfix, not a breaking change. Regardless, this ticket is valid either way.
On Aug 16, 2016, 18:48 -0400, Kevin Mehall notifications@github.com, wrote:

Should the increased strictness of the semver parser be considered a breaking change? I have a project with Iron 0.3.0 in Cargo.lock that builds on stable but fails to build on nightly with this error.
For anyone uses Iron 0.3.0 and finds this issue when searching for the error message, the fix is to update Iron to 0.3.1 (https://github.com/iron/iron/issues/471), which fixes the malformed version in its Cargo.toml.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub (https://github.com/rust-lang/cargo/issues/2964#issuecomment-240263396), or mute the thread (https://github.com/notifications/unsubscribe-auth/AABsikVwkjMKKZo6SUeSbnHh7gt5DSDLks5qgj5JgaJpZM4Jd6YR).

https://github.com/rust-lang/cargo/issues/3001, for the purposes of cross-linking

I think this is sufficiently fixed now.  The original example shows a large warning added in #3154 with:
warning: parsed version requirement `0.2*` is no longer valid

...plus a long description

Details for parse errors were added in #6141.  Errors generally look like this now:
error: failed to parse manifest at `/.../Cargo.toml`

Caused by:
  failed to parse the version requirement `==1` for dependency `plugin`

Caused by:
  the given version requirement is invalid

authors: RandomInsano alexcrichton ehuss kevinmehall steveklabnik


text:
Feature request: cargo test  should respect .gitignore

I like to put scratch.rs in .gitignore so I can have a src/bin/scratch.rs or examples/scratch.rs for running quick experiments, etc. in crates under development. It would be nice if cargo test (and probably any subcommand that should only be working on files that will be included by cargo publish) would respect .gitignore and, for example, not fail if there are errors in my scratch.rs file.

Triage: this is not only for cargo test test targets but all Cargo tests. This is not yet accepted but from the implementation perspective it is perhaps not really hard to get it done.

Its unclear if the more meaningful request is for having package.auto* respect .gitignore or should respect package.includes / package.excludes.  I think the latter is more meaningful and correct.
The original request sounds like it wants inconsistent results.  They apparently want .gitignored files to sometime be used by cargo so they can use this scratch.rs but at other times, have it not be used.  I can't think of a universal policy we could support with that but it'd need to be environment configuration (.cargo/config.toml).  I say environment rather than project (Cargo.toml) because this seems to be context sensitive to the user.
Even if the user actually wants consistent results, there are valid use cases for having targets that are excluded from packaging, like development-only targets that they don't want made available to cargo install.
I'm going to propose to the cargo team that we close this.  If there is a reason we should reconsider, let us know!

Second and close

authors: edmccard epage weihanglo


text:
Publishing a crate is case-sensitive

It's the first time i published a crate, so i followed https://doc.rust-lang.org/book/2018-edition/ch14-02-publishing-to-crates-io.html
It didn't mention that the name of your crate is case sensitive.
I ended up publishing Boa instead of boa and I didn't realised i made the mistake until it was too late.  It was only until after i published i noticed that most crates were lowercase.
Is there something we can do about this?

By convention, we almost always use lowercase for crate names, so we should probably warn about this at some step in the process.

Considering users should have gotten a warning from rustc
warning: crate `UPPERcase_name` should have a snake case name such as `uppercase_name`, #[warn(non_snake_case)] on by default

And we now have a warning from cargo new in #12766, I'm going to close this as resolved.  If there is a reason we should re-open this, let us know!

authors: epage jasonwilliams joshtriplett


text:
Remove repeated definite articles

Remove repeated definite articles

Thanks!
@bors r+

:pushpin: Commit 825c75af318071b7ecdb6f247addc3beebeeb3c2 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 825c75af318071b7ecdb6f247addc3beebeeb3c2 with merge ba45764a2c0101a7bac8168f8ea8ba408e9ac6e9...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing ba45764a2c0101a7bac8168f8ea8ba408e9ac6e9 to master...

authors: bors cuishuang weihanglo


text:
chore: bump cargo-credential-* crates as e58b84d broke stuff

e58b84d changed the shape of response of cargo credential protocol trait,
so credential plugin crates effectively depend on cargo-credential@0.4.0.
However, cargo@0.74.0 still depends oncargo-credential@0.3.0.
They must depend on the same major version of cargo-credential
otherwise incompatible.
This PR

bumps the version to cargo-credential-wincred@0.4.2
bumps the version to cargo-credential-macos-keychain@0.4.2
bumps the version to cargo-credential-li@0.4.2

See https://github.com/rust-lang/cargo/pull/13004 for more.

@bors r+

:pushpin: Commit 36ce6cf0f5dc89b88513f02d797d169c4a5bba8d has been approved by ehuss
It is now in the queue for this repository.

:hourglass: Testing commit 36ce6cf0f5dc89b88513f02d797d169c4a5bba8d with merge 90a24286bf2b2b8a3cb88ce9d34e5e0d364ac837...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 90a24286bf2b2b8a3cb88ce9d34e5e0d364ac837 to master...

authors: bors ehuss weihanglo


text:
Tests rely on absence of RUST_BACKTRACE

I have it set in my default environment, and it causes tests to fail

@bors r+

:pushpin: Commit f3c7525a61d61b347ed9e2e278dd84cc8c943531 has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit f3c7525a61d61b347ed9e2e278dd84cc8c943531 with merge 8f40fc59fb0c8df91c97405785197f3c630304ea...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing 8f40fc59fb0c8df91c97405785197f3c630304ea to master...

authors: bors epage kornelski


text:
Git2-rs on Android got error "the SSL certificate is invalid"

Hi, there. I made an app with git2-rs, it works well on linux, but I got an error on Android like:
{ code: -17, klass: 16, message: "the SSL certificate is invalid" }
Does anyone know how to solove it?
Thank you.

Unfortunately I don't know how to resolve that.
Closing as a duplicate of #920.

authors: ehuss newproplus


text:
Add a guide for new Council Representatives.

This adds a guide to help orient new Council Representatives.
Closes #26
Closes #28
(I don't feel inclined to automate any of this, thus the checklist at the bottom should suffice for now.)

@rust-lang/leadership-council Checking if everyone agrees with this. This is just a guide for new members to get started. It also includes a checklist at the bottom for the things that need to happen when changing representatives.
@rfcbot fcp merge

repo: rust-lang/leadership-council


text:
[illumos] add pthread stack functions

Cherry-picks 80d43bf020792098497a94d0ff1c9ef30e8bdf05 (#3788) onto the libc-0.2 branch.

Thanks, will merge this after CI gets fixed up.

repo: rust-lang/libc


text:
Add Trusty OS support

This PR adds support for the Trusty secure operating system. This upstreams the patch that we have been using internally, cleaned up to meet the project's coding conventions.
This is a revival of https://github.com/rust-lang/libc/pull/2987.

Addressing a comment from the original PR, @JohnTitor asked:

I wonder if we could move the module under linux_like or somewhere else similar to that. I'm not familiar with Trusty but is it completely different from Linux-like OS (i.e. exposing linux-like items on Trusty is harmful)?

Yeah, Trusty is not linux-like, nor is it a Unix. It has some overlap with those platforms, but isn't part of the same family of systems. I think the right thing to do is have Trusty be its own module.

I think this would also be a good candidate for merging over to the 0.2 branch. The diff should apply cleanly, I've tested it against both branches.
@rustbot label stable-nominated

What should I do about the unknown target_os = "trusty" cfg in CI? The targets aren't yet in the stable compiler. I've got this Cargo.toml snippet I've been using locally
[lints.rust.unexpected_cfgs]
level = "warn"
check-cfg = [
    'cfg(target_os, values("trusty"))',
]

Is that appropriate to add in the PR as a temporary way to suppress the lint? Or is there a better way to handle this?

@tgross35 We're using musl as our libc implementation, so those definitions come from the musl headers.

PROT_READ, PROT_WRITE, and MAP_FAILED come from mman.h.
CLOCK_BOOTTIME comes from time.h.
STDOUT_FILENO and STDERR_FILE_NO come from unistd.h.
AT_PAGESZ comes from elf.h.

Also it looks like a rebase to the latest main fixed the unknown platform error, so I didn't need to update build.rs.

oh I forgot to say the magic word
@rustbot review


text:
rustup

@bors r+

@bors r+

:pushpin: Commit 739d796b0588bb7c38c2a69f17d44084d48d5010 has been approved by RalfJung

:hourglass: Testing commit 739d796b0588bb7c38c2a69f17d44084d48d5010 with merge 9b01141b043d8e81394ac18390dfbeda449c7c6a...

:boom: Test timed out

authors: RalfJung bors

repo: rust-lang/miri


text:
Meeting proposal: Do Vec and Box have an aliasing requirement?

Summary
This meeting will discuss the aliasing requirements on Vec and Box to see if consensus exists at least as to the question of whether such aliasing requierments exist. If consensus exists that some exist, the meeting may cover what the requirements are to an extent, but the primary focus in on the yes or no question.
Reading
UCG Issue: https://github.com/rust-lang/unsafe-code-guidelines/issues/326
Prior Zulip Topic: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/Making.20Box.20allow.20aliasing
A meeting document will be written up prior to the meeting.
Comment policy
These issues are meant to be used as an "announcements channel" regarding the proposal, and not as a
place to discuss the technical details. Feel free to subscribe to updates. We'll post comments when
reviewing the proposal in meetings or making a scheduling decision. In the meantime, if you have
questions or ideas, ping the proposers on Zulip (or elsewhere).

@chorman0773 what shal we do with this issue? Could you post a short summary of the discussion?
I don't think we had any concrete post-meeting actions, we kind of came out of it without much of a conclusion.

Summary as recorded

Box and Vec are imbued with langauge magic, and their aliasing concerns are major concerns in the ecosystem, with a wide variety of common pain points that the ecosystem runs into (ala StableDeref and similar). With Box, the situation is simple than Vec, as this would be a weakening of guarantees, whereas it would be an addition for Vec.

Answer to question posed: No, we cannot currently answer the question.

Possible solutions to advance on the question:

Attributes to opt-out or opt-in to various behaviours, allowing stdlib types to either have or not have aliasing constraints without intruding on unsafe code that wants or does not want the constraints.
MaybeDangling<Box<T>> could have place-deref behaviour like Box<T>

I'm not sure there's a lot to do from here, except either wait for MaybeDangling or the attribute design, so this issue can probably be closed.

repo: rust-lang/opsem-team


text:
Why does the cast_slice parameter have to be of type Pod?

pub fn try_cast_slice<A: Pod, B: Pod>(a: &[A]) -> Result<&[B], PodCastError>
requires that the parameter a is a slice of type Pod. Pods can't be chars (because the type must allow any bit pattern).
However I don't understand why. It's not like I can introduce illegal bit patterns through a non-mutable reference?!
Is this some random limitiation of this crate?
Can we not fix this because of #41?
Is relaxing trait boundaries not allowed?

Did you mean to file this issue on bytemuck?
This repo isn't for a crate; it tracks an effort to add a new analysis to rust itself.

Yes you are right @jswrenn . Somehow I accidentally opened the issue in the wrong repository. And moreover since at least version 1.9.0 bytemuck actually changed the signature to take NoUnit instead of Pod to address exactly that. So the whole issue is moot in the first place.
I really shouldn't open issues when tired. Sorry for the noise! If you have the permission to delte my issue I would appreciate if you delete it.

authors: jswrenn kwinz

repo: rust-lang/project-safe-transmute


text:
TaskPool should contain a spmc queue and more features

Currently, the std::sync::taskpool::TaskPool have fixed number of threads and does not support reject execution policy. It is simple but I think it could have more features.
In Java, the java.util.concurrent.ThreadPoolExecutor, when calling execute on the pool:

If the number of current working threads is less than CoreThreadNum, then it will spawn a new thread and execute the task;

If the number of current working threads is greater or equal to CoreThreadNum, but smaller than MaximumThreadNum:

if the queue is not full, then just put the task into the queue
if the queue is full, then spawn a new thread and execute a task

If the number of current working threads is equal to MaximumThreadNum, and the queue is full, then it will reject the task according to the RejectExecutionHandler.

Currently implementation of TaskPool uses the channel in std::sync::mpsc, which result in every working threads have to lock the mutex for getting the real tasks. If we have a "spmc" channel, which means that the Receiver could be shared across multiple threads, the TaskPool could be more efficient.

spmc primitives would quite generally be very useful. I've found myself maintaining a Vec<mpsc::Sender<T>> for callback mechanisms more than once.

It's not very hard to implement a spmc queue since mpsc and spsc queues are already exists. I hope this could be included into the std crate.

Because the sync module has already been stabilized, changes to it need to go through the RFC process, and so, threads like this belong over there: https://github.com/rust-lang/rfcs/issues/
Thanks!

@steveklabnik. I am pretty sure, this is the RFCs repo…

Uuuuuugh, sorry :(

This has since been removed from libstd, so closing.

authors: aepsil0n alexcrichton steveklabnik zonyitoo

repo: rust-lang/rfcs


text:
Add custom toolchains for powerpc* and s390x

Using Ubuntu's cross-toolchains meant these targets were depending on glibc symbols from Ubuntu 16.04.  And if that host is ever updated to a new release, the toolchains would raise the bar too.
This switches powerpc* and s390x to use crosstool-ng toolchains, with the kernel and glibc configured approximately like RHEL7.  That should also be compatible with Debian 8 (jessie) and Ubuntu 14.04 (trusty).
Incidentally, this also updates the netbsd and llvm URLs to fix the docker build.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Note, however, there is one hiccup preventing powerpc64 from working.  In Rust mk/cfg/ and in gcc-rs, powerpc64 is configured to use the power-linux-gnu- prefix, which only works because it's also using -m64 and the toolchain supports multilib.  Here, crosstool-ng does not provide multilib by default, and describes that option as being experimental.  But I'm not sure why powerpc64 is being compiled this way.  @alexcrichton It looks like you set this -- do you recall why?

Also, my original motivation for this was to get RHEL6-compatible binaries, glibc-2.12, but I wasn't able to wrangle crosstool-ng to provide that old of a glibc along with a new enough gcc for LLVM.  So I think it's still worthwhile for Rust to compile these arches at a lower target than Ubuntu 16.04, but I'll have to figure out our own cross-compilation to get RHEL6 going.
Actually, powerpc64le in this PR isn't even low enough for RHEL7, but that's because upstream support wasn't added until glibc-2.19, and RHEL7's glibc has it backported.  It would almost be close enough anyway, but __cxa_thread_atexit_impl@GLIBC_2.18 sneaks in and ruins it. 😢

It's also not clear to me how this all relates to rust/src/ci/docker/... is this repo now obsolete?

Thanks for the PR @cuviper! Things are definitely in a bit of a state of flux, but we can accept this PR anyway for now. To answer some of your questions:

Note, however, there is one hiccup preventing powerpc64 from working. In Rust mk/cfg/ and in gcc-rs, powerpc64 is configured to use the powerpc-linux-gnu- prefix, which only works because it's also using -m64 and the toolchain supports multilib.

Yeah this is fine, and also one of the many reasons to jettison the makefiles! Rustbuild handles this case w/ the various env vars being set, so the defaults in the makefiles should become irrelevant quickly!

So I think it's still worthwhile for Rust to compile these arches at a lower target than Ubuntu 16.04, but I'll have to figure out our own cross-compilation to get RHEL6 going.

Aw that's a bummer :(. I've had tons of difficulty in the past getting various versions to match up w/ crosstool-ng. If you can get glibc/gcc builds from source though that'd also work great, we don't mind too much vendoring tons of shell scripts here.

It's also not clear to me how this all relates to rust/src/ci/docker/... is this repo now obsolete?

Yes and no! Eventually we're going to deprecate this repo in favor of the support in the rust-lang/rust repository (tracked here: https://github.com/rust-lang/rust/issues/38531). For now though this repo is still the source of truth for producing releases.
If you're ok with a month-ish time frame to get this out to nightlies, then we may want to move all this over to the rust-lang/rust repo rather than here. If you'd like to get it out sooner though we can do it here, build a new image, and update the current release bots to use that.
I just sent a PR actually (https://github.com/rust-lang/rust/pull/39198) to do what you're doing here for the existing compilers we've got in this repo for the Travis builds. Eventually we'll want to send this up to rust-lang/rust as well, but that's up to you in terms of time frame when you'd like to do so.
Does that help clear things up?

Oh and this PR looks great to me! I'm fine to merge whenever. Curious on your thoughts from my previous comment though.

Yeah this is fine, and also one of the many reasons to jettison the makefiles! Rustbuild handles this case w/ the various env vars being set, so the defaults in the makefiles should become irrelevant quickly!

Ah, I knew that the makefiles are on the way out, but I missed that gcc-rs checks the env first.  It's still a weird default to have "powerpc64-unknown-linux-gnu" => Some("powerpc-linux-gnu"), but whatever. :)

If you can get glibc/gcc builds from source though that'd also work great, we don't mind too much vendoring tons of shell scripts here.

I think ultimately to handle RHEL6 from source, we'd have to use two compilers - the old gcc to compile that old glibc, and then a new gcc to use with Rust/LLVM, still linking to that old glibc.  I have no idea how to convince crosstool-ng to work like this, nor am I really keen to duplicate its procedure manually.  But it's my first time with the tool, so maybe there's a way...
At least if I'm cross-compiling for RHEL6 on my own, I can just use the actual glibc binaries of the target.  And it's a one-time pain, then I can chase Rust releases with native builds thereafter.  But it doesn't help anyone outside Red Hat either.  We'll see, maybe after I try it my estimates of the difficulty will change.

If you're ok with a month-ish time frame to get this out to nightlies, then we may want to move all this over to the rust-lang/rust repo rather than here. If you'd like to get it out sooner though we can do it here, build a new image, and update the current release bots to use that.

Given that I still have to figure out RHEL6, and having done so can reuse that for RHEL7 too, this leaves me in no rush for merging this PR.  I just wanted to bear some fruit from my efforts with crosstool-ng. :)
So the long-term approach is fine with me.  We can avoid rocking the boat on the current infrastructure, and as soon as rust-lang/rust#39198 lands I can try to carry these changes over there too.

Ok that all sounds good to me!
So I'll also note that the minimum gcc for LLVM is 4.7, so it's not too recent. I'll also note that crosstool-ng is just the "first thing that worked", and I'd be totally down for using anything else that worked. For example the netbsd/freebsd toolchains have their own shell scripts to compile gcc (just a standard configure-then-make). This rarely works out in practice though unless everything is just right, so your mileage may vary...
If we can get precompiled binaries of glibc, though, then perhaps we can take the strategy of avoiding compiling it and going straight to glibc? This tends to be much easier than also having to compile glibc.

So I'll also note that the minimum gcc for LLVM is 4.7, so it's not too recent.

Well, LLVM's guide says GCC 4.8, but yeah, not too recent.  That's even what RHEL7 ships with - how shiny! :)
I wonder though, maybe I can use two compilers - just use crosstool-ng for gcc-4.4/glibc-2.12/binutils, then manually run a build script for newer gcc to live next to that.  Hmm...
That still leaves a question for RHEL7 ppc64le, with its odd backported glibc-2.17.  If I could just find a way to hack out __cxa_thread_atexit_impl from 2.19, I think it would be ok.  The crosstool-ng page mentions it can do custom patches, so maybe I can cut it out.  Or applying the same backport patches to 2.17 would be cleaner.

If we can get precompiled binaries of glibc, though

AIUI, RHEL binary redistribution is still restricted, even though source is freely available.  Maybe it would be fine, but I'd rather not involve legal question if we can avoid it. :)  But for ppc64le in particular, it might work to grab binaries from centos7.
Anyway, there are a few more things for me to try here.

Oh dear looks like we may be in for a gcc upgrade soon ...
Also yeah binaries from a random centos disk image or something like that would be fine by me, even some historical release of ubuntu might work. All we really need is a basic "chroot" kinda

OK, pushed an update -- I managed to get everything back as far as I need, yay!
Quoting the commit:

For crosstool-ng with powerpc, powerpc64, and s390x, a few small patches
are now applied to glibc-2.12 to get it to compile with newer GCC.  This
should now be compatible with RHEL6, Debian 7 (wheezy), and Ubuntu 12.04
(precise).
For powerpc64le, the challenge was that only glibc-2.19 officially added
support, but el7 backported those changes to glibc-2.17.  The backport
patches are complex and numerous, so instead of trying to push those
into crosstool-ng, just use glibc binaries directly from centos7 and
build the toolchain manually.

Now, I've only checked it briefly, to see that the full docker build succeeds and compiling C/C++ hello-world produces binaries for the right target.  I can try an actual rust build tomorrow...

Looks good! I'll merge here and we'll pick it up on the next update (if ever, not sure if we'll proactively do this). Want to submit this upstream to the docker images in the main repo as well? It should actually be pretty soon that we have full releases built there.

I'm reasonably confident that these cross-compilers are working now, but I'm running into other issues trying to use their result for a native rebuild on el6, like:
rustc: powerpc64-unknown-linux-gnu/stage1/lib/rustlib/powerpc64-unknown-linux-gnu/lib/libcore
error[E0081]: discriminant value `0isize` already exists
    --> src/libcore/slice.rs:1178:5
     |
1176 |     Continue,
     |     -------- first use of `0isize`
1177 |     // Fold is complete and will return this value
1178 |     Done(T),
     |     ^^^^^^^ enum already has `0isize`

error[E0081]: discriminant value `0isize` already exists
  --> src/libcore/num/flt2dec/decoder.rs:46:5
   |
44 |     Nan,
   |     --- first use of `0isize`
45 |     /// Infinities, either positive or negative.
46 |     Infinite,
   |     ^^^^^^^^ enum already has `0isize`

[many similar errors later...]

error: aborting due to 57 previous errors

Same on s390x, but my ppc64le rebuild on el7 was fine, so it could be an endianness issue again, or maybe just an el6 issue.  I'm trying to reproduce elsewhere to isolate this now, especially on Fedora where I don't need these new cross-compilers, and if so I'll file a bug in the Rust repo.

This is now in rust-lang/rust#39382.
And for reference, I found the enum discriminant problem was independent of these cross-toolchains, so I filed rust-lang/rust#39331, and when I get a new nightly I'll verify if rust-lang/rust#39332 fixed it.

Awesome, thanks so much for the investigation and digging here @cuviper! Sounds like this is working, so I'll merge.

@alexcrichton Will I need to do anything to get Cargo using this too?

Oh right good point! Right now Cargo uses this same docker image. I'll build/publish this image (working on that now) and then we'll need to send a PR to update that container to use the freshly minted builds.
Eventually this won't be necessary as we'll compile Cargo as part of the normal release process, but alas!

@cuviper ok I'm now in the process of pushing up alexcrichton/rust-slave-linux-cross:2016-02-02, want to send a PR for Cargo to use that?

Sure, will do.

authors: alexcrichton cuviper rust-highfive

repo: rust-lang/rust-buildbot


text:
can't format let chains

let chains got stabilized recently but it seems that rustfmt has absolutely no idea how to format them https://github.com/rust-lang/rust/pull/94927
sample code, nothing will be reformatted in this code:
pub enum Color {
    Blue,
    Red,
    Violet,
}

pub enum Flower {
    Rose,
    Tulip,
    Violet,
}

pub fn roses_are_red_violets_are_blue_printer(
    (first_flower, first_flower_color): (Flower, Color),
    (second_flower, second_flower_color): (Flower, Color),
    pick_up_lines: &[&str],
) {
    // I messed up the formatting here a bit
    if let Flower::Rose = first_flower
        && let Color::Red = first_flower_color &&
      let Flower::Violet = second_flower
        && let Color::Blue =
        second_flower_color
        && let &[first_pick_up_line, ..] = pick_up_lines
      {
 println!("Roses are red, violets are blue, {}", first_pick_up_line);
    }
}

fn main() {
    roses_are_red_violets_are_blue_printer(
        (Flower::Rose, Color::Red),
        (Flower::Violet, Color::Blue),
        &["sugar is sweet and so are you"],
    );
}

Thanks but going to close as a duplicate of #4955.
tl;dr, rustfmt doesn't format let expressions because there isn't any specification yet for how they should be formatted, even more so in chains - https://github.com/rust-dev-tools/fmt-rfcs/issues/169

authors: calebcartwright matthiaskrgr

repo: rust-lang/rustfmt


text:
rustfmt gives up on method chain with closure with very long return type

rustfmt refuses to format the following statement (reduced from a real-world example):
fn test() {
    let output: Vec<_> = input
            .into_iter()
            .map(|serialized| -> Result<long_crate::LongCrateTypeName, long_crate::DeserializationFailure> {
                Ok(serialized)
            })
            .map_err(|_| {
                // A comment
                Failure
            })?;
}

The long type names seem to be at fault; shortening either of them results in a successful format. I realize there's not a great way to format that type, but giving up on the entire statement was surprising.
Tested on play.rust-lang.org using the 2024-02-04 07dca48 build of rustfmt.

Thanks for the report. This is another duplicate of #3863

Ah, not specific to types. Thanks!

authors: jrose-signal ytmimi


text:
Format trailing where clauses in type aliases

Self-explanatory. cc rust-lang/rust#114901
This implementation is probably super busted. I have no idea what most of these options in rustfmt mean, lol.

r? @ytmimi or @fee1-dead
I'd like to hold off on merging this till the next-next sync & release (assuming we are still on track to get let-chains in quickly) given the diff it'll introduce on stable.
Probably worth having common (and uncommon) comments in the test snippets too

I'd like to hold off on merging this till the next-next sync & release (assuming we are still on track to get let-chains in quickly) given the diff it'll introduce on stable.

Sounds good. I think we're still on track to get that out soon. I'll likely have that PR ready later this week. Given that I'll probably hold off on reviewing this until after the next sync.

@ytmimi  do you think we should pull this in as part of the next release? I imagine this would need to be prefaced with a blog post and some associated lead time due to the intro of formatting being applied for the first time?

@ytmimi do you think we should pull this in as part of the next release? I imagine this would need to be prefaced with a blog post and some associated lead time due to the intro of formatting being applied for the first time?

@calebcartwright Yeah, I think we could pull this in for the next release. When did you want to do the sync? I'm still up for taking on the subtree push. Maybe we can talk it over on Zulip and find a time that works.

I'm expecting to see some changes now that we actually format trailing where clauses, but let's see what the Diff-Check reveals.

Okay, This Diff-Check job shows the diffs I was expecting. @compiler-errors can when you have a chance, can you review the logs and double check that things are formatted here as expected based on the formatting rules you implemented.
For your convenience I'm including the diffs inline:
note the output is a diff of diffs, so it might be a little noisy, by the highlighting should help identify the changes
Diff in /tmp/rust-lang-rust-f0yK2vou/library/core/src/ops/async_function.rs:73:
     where
         <F as FnOnce<A>>::Output: Future,
     {
-        type CallFuture<'a> = <F as FnOnce<A>>::Output where Self: 'a;
+        type CallFuture<'a>
+            = <F as FnOnce<A>>::Output
+        where
+            Self: 'a;

         extern "rust-call" fn async_call(&self, args: A) -> Self::CallFuture<'_> {
             self.call(args)

Diff in /tmp/rust-lang-rust-f0yK2vou/library/core/src/ops/async_function.rs:85:
     where
         <F as FnOnce<A>>::Output: Future,
     {
-        type CallMutFuture<'a> = <F as FnOnce<A>>::Output where Self: 'a;
+        type CallMutFuture<'a>
+            = <F as FnOnce<A>>::Output
+        where
+            Self: 'a;

         extern "rust-call" fn async_call_mut(&mut self, args: A) -> Self::CallMutFuture<'_> {
             self.call_mut(args)

Diff in /tmp/rust-lang-rust-f0yK2vou/compiler/rustc_query_system/src/query/caches.rs:32:
 pub struct DefaultCacheSelector<K>(PhantomData<K>);

 impl<'tcx, K: Eq + Hash, V: 'tcx> CacheSelector<'tcx, V> for DefaultCacheSelector<K> {
-    type Cache = DefaultCache<K, V>
+    type Cache
+        = DefaultCache<K, V>
     where
         V: Copy;
 }

Diff in /tmp/rust-lang-rust-f0yK2vou/compiler/rustc_query_system/src/query/caches.rs:84:
 pub struct SingleCacheSelector;

 impl<'tcx, V: 'tcx> CacheSelector<'tcx, V> for SingleCacheSelector {
-    type Cache = SingleCache<V>
+    type Cache
+        = SingleCache<V>
     where
         V: Copy;
 }

Diff in /tmp/rust-lang-rust-f0yK2vou/compiler/rustc_query_system/src/query/caches.rs:126:
 pub struct VecCacheSelector<K>(PhantomData<K>);

 impl<'tcx, K: Idx, V: 'tcx> CacheSelector<'tcx, V> for VecCacheSelector<K> {
-    type Cache = VecCache<K, V>
+    type Cache
+        = VecCache<K, V>
     where
         V: Copy;
 }

Diff in /tmp/rust-lang-rust-f0yK2vou/compiler/rustc_query_system/src/query/caches.rs:177:
 pub struct DefIdCacheSelector;

 impl<'tcx, V: 'tcx> CacheSelector<'tcx, V> for DefIdCacheSelector {
-    type Cache = DefIdCache<V>
+    type Cache
+        = DefIdCache<V>
     where
         V: Copy;
 }

Diff in /tmp/rust-lang-rust-f0yK2vou/src/librustdoc/clean/types.rs:1059:
 }

 impl AttributesExt for [(Cow<'_, ast::Attribute>, Option<DefId>)] {
-    type AttributeIterator<'a> = impl Iterator<Item = ast::NestedMetaItem> + 'a
-        where Self: 'a;
-    type Attributes<'a> = impl Iterator<Item = &'a ast::Attribute> + 'a
-        where Self: 'a;
+    type AttributeIterator<'a>
+        = impl Iterator<Item = ast::NestedMetaItem> + 'a
+    where
+        Self: 'a;
+    type Attributes<'a>
+        = impl Iterator<Item = &'a ast::Attribute> + 'a
+    where
+        Self: 'a;

     fn lists<'a>(&'a self, name: Symbol) -> Self::AttributeIterator<'a> {
         AttributesExt::iter(self)
@ -7[54](https://github.com/rust-lang/rustfmt/actions/runs/7661954853/job/20882324738#step:4:55)9,0 +7[63](https://github.com/rust-lang/rustfmt/actions/runs/7661954853/job/20882324738#step:4:64)3,7 @@ Diff in /tmp/rust-lang-rust-f0yK2vou/src/tools/rust-analyzer/crates/parser/test_

Diff in /tmp/rust-lang-rust-f0yK2vou/src/tools/rust-analyzer/crates/parser/test_data/parser/inline/ok/0012_type_item_where_clause.rs:1:
-type Foo = () where Foo: Copy;
+type Foo
+    = ()
+where
+    Foo: Copy;

@ytmimi: Yes, that formatting looks correct. When there is a where clause present, there's always a line break, then =, then a break, then the where clauses.

@ytmimi do you think we should pull this in as part of the next release? I imagine this would need to be prefaced with a blog post and some associated lead time due to the intro of formatting being applied for the first time?

I think all the implementation work for this is done on the rustfmt side!
@calebcartwright I missed the fact that you suggested we get a blog post together for this. I'd be happy to draft something in preparation for the release. Is the idea to have the blog post go out before the release?

@ytmimi: Yes, that formatting looks correct. When there is a where clause present, there's always a line break, then = and the type, then a break, then the where clauses.

Awesome, thank you for confirming! I'm already anticipating someone asking for a single-line formatting option 😅

@calebcartwright @ytmimi: It's been almost a year since this PR was opened. Is there any chance we could finally get this merged? What's the plan on doing the next rustfmt->rust sync?

@ytmimi thoughts on how to label this one? it isn't technically part of the 2024 edition and can/should go before, but it is definitely something that can't slip past the 2024 edition

Agreed that this one should get in no later than the 2024 edition, and really as soon as we can. Just brainstorming here, but maybe we can label it something like pre-2024-must-have

What I think I'd like to do is get this merged such that it's timed to land with the addition of the style_edition option so that we can have a single blog post highlighting both

@compiler-errors i hate to ask but would you have bandwidth to rebase? if not i understand (i know how busy you are) and i can grab your commits and pull them into a new branch but just wanted to check with you first

@calebcartwright: Done. Sorry, was asleep by the time you sent that message otherwise I'd've done it sooner 😆

Do you want me to rebase?

Well, I went ahead and did it anyways.

Thank you :pray:

authors: calebcartwright compiler-errors ytmimi


text:
Create a documentation book

I'd like to move the documentation from the wiki to an mdbook published on gh-pages. The intent is to have something that is organized a little better, and so that any changes or new features can update the documentation within the same PR when they are introduced. I'd also like to move the documentation from https://forge.rust-lang.org/platforms/zulip/triagebot.html to this book as well so there is only one place where the documentation lives.
I'd also like to organize the documentation a little better so it has clearer sections for users versus administrative-oriented things like how to configure a feature. I'd like it to be a little more user-centric so that information about how to use a feature is up-front, with information about how to configure triagebot.toml is perhaps lower down. And to have a consistent organization between the pages for the different features.
Another intent is to then address #629 by updating some of the bot commands to point to this new book.
Does that sound like something that there would be interest in?

Opened a Zulip thread to discuss this issue

Posted https://github.com/rust-lang/rust-forge/pull/687 to address this.

authors: apiraino ehuss

repo: rust-lang/triagebot


text:
Automatically mark all but the last comment as resolved

GitHub now allows comments to be marked as "Resolved". I propose we automatically mark all old "failed on Travis" comments as resolved every time a new one gets added. This will improve the readability of discussions in PRs (especially in cases like https://github.com/rust-lang/rust/pull/51249).
Sadly, it doesn't look like there is an API endpoint for doing this (neither in the REST v3 nor in the GraphQL API).

See also https://github.com/rust-ops/rust-log-analyzer/issues/10#issuecomment-382517000 :)

Ah, great! Before researching this I was hoping it was just a simple API call. I agree the Checks API might be better suited.

authors: kennytm killercup

repo: rust-ops/rust-log-analyzer


text:
black screen on QEMU 6.0.93

I've tried all of the Writing an OS in Rust posts from https://os.phil-opp.com/  and they work fine with QEMU 4.2.1 under Ubuntu 20, but when I tried running them on QEMU 6.0.93 under Windows 10, I just get a black screen.
I've tested this install of QEMU 6 with every other OS I have and they all boot fine. I'm using bootloader 0.9.19 since that seems to be the last one that is completely compatible with the configuration given in the blog posts.
So I'm not sure where to go next.
update: I resolved this by installing QEMU 6.1.0

update: I resolved this by installing QEMU 6.1.0

Thanks for providing the update, I'm glad that it works again.

I had the exact same issue as @jaymzee with QEMU 6.0.x on Windows, just a black screen, updating to QEMU 6.1.x fixed the issue for me 👍🏻

authors: jaymzee phil-opp vandadnp

repo: rust-osdev/bootloader


text:
The driver is currently broken

The current version of this driver (v0.0.6) depends on scram (v0.1.0) which depends on ring (v0.6) which was recently yanked along with almost all old versions. scram v0.2.0 which depends on the latest ring version has since been released but unfortunately it contains breaking changes so simply bumping its version didn't doesn't cut it.

Now fixed on master. Will release v0.0.7 shortly.

repo: rust-rethinkdb/reql


text:
fix: Update dependencies

This change is

bors r+

repo: rustgd/rhusics


text:
Improve ref to use local_ref when available

Details
Looking specifically at road.lua but should update anywhere else it's used.  Currently ref is populated using a simple grab_tag()
local ref = object:grab_tag('ref')

Looking at Colorado data (from March 2021) in osm.unitable.
SELECT COUNT(*) AS rows_with_either_ref,
        COUNT(*) FILTER (WHERE tags->>'ref' IS NOT NULL)
            AS ref_only,
        COUNT(*) FILTER (WHERE tags->>'local_ref' IS NOT NULL)
            AS local_ref_only
    FROM osm.unitable
    WHERE tags->>'ref' IS NOT NULL
        OR tags->>'local_ref' IS NOT NULL
;

Missing ~2.2k of 59k -- 4% of total.
rows_with_either_ref|ref_only|local_ref_only|
--------------------+--------+--------------+
               58946|   56775|          2187|

https://wiki.openstreetmap.org/wiki/Key:ref
A bunch of variety.  Looks like might find some lang specific ref too, should bring that over from name handling.

Then there are issues like this, where there are ref:left and ref:right tags to indicate multiple exits from the motorway, e.g. 12A and 12B.  This usage doesn't appear to be documented anywhere.
https://www.openstreetmap.org/node/175870954#map=17/39.76541/-104.82749

repo: rustprooflabs/pgosm-flex


text:
複数行の引用をした際の表示がプレビューとパブリッシュで異なる

以下のように記述した場合、プレビュー時は改行ありで表示されますが、パブリッシュ時は改行が消えてしまうようです。
> A
B
C

修正しました。

repo: rusts/team


text:
Structs whose name begins with "Test" cause run-time failures in wasm-bindgen-test tests

Describe the Bug
When using wasm-bindgen-test via wasm-pack test, if any struct have a name beginning with Test or test and have  the #[wasm-bindgen] macro the tests will fail to run.
Steps to Reproduce

wasm-bindgen = "0.2.62"
wasm-bindgen-test = "0.3.12"
Add the following to a fresth lib.rs and run wasm-pack test --node.

#[wasm_bindgen]
pub struct Test;

#[cfg(test)]
pub mod test {
    use wasm_bindgen_test::*;

    #[wasm_bindgen_test]
    fn pass() {
        assert_eq!(1, 1);
    }
}

Actual Behavior
These struct names work:

ConnectionTest
SocketTest
ATest
Attestation

These names fail:

Test
TestConnection
Testnet
Testify
test
testify

Removing the #[wasm-bindgen] macro causes everything to succeed. Packages can be built succesfully, imported into Node, and used normally. Only tests break
Failures produce the following error message (stack information has been trimmed):
$ wasm-pack test --node

panicked at 'exception thrown while creating a test: Error: recursive use of an object detected which would lead to unsafe aliasing in rust

Oh dear what a bizarre bug! Should be fixed in https://github.com/rustwasm/wasm-bindgen/pull/2123 though, thanks for the report!

authors: alexcrichton prestwich

repo: rustwasm/wasm-bindgen


text:
get_channel_data does not return a mutable reference to the memory

Describe the Bug
Related to the bug in CPAL here, I have discover that usage of get_channel_data is fully supported today, not like copy_to_channel.
But today the definition of get_channel_data returns a copy of the buffer into a Vec<u8>.
So it's impossible to copy the data into the buffer memory.
Expected Behavior
Be able to return a reference to the memory of the Buffer.
The expected signature of the method seems to be something like:
pub fn get_channel_data(this: &AudioBuffer, channel: u32) -> Result<&mut Vec<f32>, JsValue>;

The only way to fix this at this time would be to change the return value to Float32Array or similar I think. I suspect that to implement that we would need to have a special case for this API since it would differ from how all other APIs are bound.

Made sense. But do you know any API that returns a non-mutable array in Javascript ?
For me everything in Javascript is returned without a hard copy, so it's direct access to the memory in read/write mode...
Just by curiosity, do you know if idl format can help to define the mutable status of the returned value ?

AFAIK WebIDL doesn't have a way to convey the mutability semantics and/or semantics about where the buffer is pointing. We could perhaps annotate the WebIDL ourselves, however, by inventing attributes for wasm-bindgen

I close it as the release of Safari 14.1 (Released 2021-04-26) fix it.

authors: MarcAntoine-Arnaud alexcrichton


text:
Working around BOM bug in Safari

Fixes #1825
We don't currently run unit tests on Safari, but I'd really like it if we did.

Sounds good to me to go ahead and get in early, thanks @Pauan! I'm fine independently pursuing Safari testing in CI as well!

authors: Pauan alexcrichton


text:
Code for accuracy report of implementation of IMDB-binaray

❓ Questions & Help
i combined datasets.py, GCN.py , train_eval.py in
(https://github.com/rusty1s/pytorch_geometric/tree/master/benchmark/kernel),
This is my code
how can i get a report of accuracy of 100 epoch?

You can print out your epoch results in the cross_validation_with_val_set method.

thank you, how to set up the lr_decay_factor, lr_decay_step_size? any state of art?


text:
ERROR: Failed building wheel for torch-unique

On Google Colab.
Collecting torch-unique
Downloading https://files.pythonhosted.org/packages/6f/e1/04d4919f2e8bdd1381eae4c5455c9885757e71a5c2f4ddf897756192ac3b/torch_unique-1.0.3.tar.gz
Requirement already satisfied: numpy in /usr/local/lib/python3.6/dist-packages (from torch-unique) (1.17.4)
Building wheels for collected packages: torch-unique
Building wheel for torch-unique (setup.py) ... error
ERROR: Failed building wheel for torch-unique
Running setup.py clean for torch-unique
Failed to build torch-unique
Installing collected packages: torch-unique
Running setup.py install for torch-unique ... error
ERROR: Command errored out with exit status 1: /usr/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-a6i9zk_v/torch-unique/setup.py'"'"'; file='"'"'/tmp/pip-install-a6i9zk_v/torch-unique/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' install --record /tmp/pip-record-jxd38i9u/install-record.txt --single-version-externally-managed --compile Check the logs for full command output.

This is not the actual error message. Do you still need this package? It is actually deprecated since PyTorch provides its own unique function.


text:
Feature Request : colemak Support

i use colemak keyword arrangement, hint mode input char is qwerty

This is my warpd config in colemak
left:n
right:i
up:u
down:e

grid_activation_key:A-M-g
activation_key:M-x
hint_activation_key:M-z
grid:b

grid_up:f
grid_down:s
grid_left:r
grid_right:t

grid_keys:g j d h

scroll_up:h
scroll_down:d

start:^
end:$

cursor_size:10

exit:z

indicator: bottomleft
#indicator: Specifies an optional visual indicator to be displayed while normal mode is active, must be one of: topright, topleft, bottomright, bottomleft, none (default: none).

#indicator_color: The color of the visual indicator color. (default: #00ff00).

#indicator_size: The size of the visual indicator in pixels. (default: 12).

#speed: Pointer speed in pixels/second. (default: 220).
#speed: 500
#acceleration: Pointer acceleration in pixels/second^2. (default: 700).
#acceleration:900

#buttons: m , .
buttons: k m .

This is a simple fix for grid mode, but hint mode I'm not sure how to fix it. Advice?

@qrpike When described as follows, l: left click, m: middle click, and r: right click, respectively
buttons: l m r

This is a known bug. For historical reasons, warpd doesn't take the display server keymap into account. A proper patch for this will require some work on the platform code.

@qrpike I have not tested it, so I don't know if it will work, but if I were to use the layout in the image at https://colemak.com/ as a reference and place the keys for only the 8 keys in the home position, it would be as follows.
hint_chars: arstneio

Ah I see. Would it work if he/she had include layouts/colemak in the keyd settings instead of setting up colemak on the display server?

Yes, since the remapping is done at the evdev level, but ideally the user shouldn't have to use another tool. Given the recent influx of interest, I am working on a proper fix.

I believe this should work in the latest commit.

Nevermind, my config had an error, its working! Thank you for the quick turnaround, this is huge! Thanks

authors: kackerx qrpike rvaiya tkna91 xtccc

repo: rvaiya/warpd