text:
Subscriptions renewed when the MacOS app was closed are not picked up by Storekit2

I'm seeing a really strange behavior in Xcode 14.3 (14E222a, Ventura 13.3) for a MacOS app with auto-renewable subscriptions.
Scenario:

Launch the app (local Xcode testing) and purchase a subscription -> works OK.
Let the app run and after a while the subscription renews and StoreHelper picks up the renewal alright.
Close the app and let the subscription renew a few times "in the background."
When reopening the app, the latest transaction retrieved by a call to storeHelper.subscriptionHelper.subscriptionInfo(for: "Monthly") is the last one seen when the app was running. All the transactions happening while the app was closed are not there.
The Storekit 1 call in AppStoreHelper is picking up the "ghost" transactions quite well, but it only passes down the stream the ProductID(s) associated with those transactions, which is quite useless without a proper subscriptionInfo object.

Am I the only one seeing this? Is this going to happen in production too, or is it just a bug in local testing?

Thanks for letting me know. I had a very quick look to see what happens using the demo project. With local StoreKit testing I can see that subscription renewals happening while the app's not running are indeed NOT sent to the app when it re-opens, as I would have expected. I won't be able to look into this properly for a few days I'm afraid.
In the meantime, are you able to try this using sandbox testing (i.e. with your products defined in App Store Connect). Nobody has reported this as a problem before, so I wonder if this is related only to local StoreKit testing?
What I would expect to see happen is renewal transactions that happen while an app's not running to be sent through the normal Storehelper.handleTransactions() method once the app re-opens.
I'm a bit confused when you talk about the Storekit 1 call in AppStoreHelper picking up "ghost" transactions. That's only meant to support direct App Store purchases made outside the app. Are you saying that the paymentQueue(_:updatedTransactions) method is receiving subscription renewals?

I've looked into this a bit more and you're quite right: subscription renewals (even if there are multiple renewals) that happen when the app's not running ARE being detected when the app re-opens, but they're being picked up by the paymentQueue(_:updatedTransactions) method. And the transactions are not being properly handled.
Now I can see what's happening I'll hopefully be able to put a fix together quickly!

Honestly, I had and still have the same issue, but I thought this is how it works in local env. Because on prod env (App Store) I don't have this issue, however it was frustrating 😀, good that I'm not the only one with this issue

@russell-archer Thank you for looking into this. I wasn't clear at all when speaking about 'ghost transactions' indeed :-) I meant the transactions happening while the app was closed.
It could be a Storekit cache problem though, if I delete the
~/Library/Group Containers/group.com.apple.storekit/Library/Caches folder the missed transactions are retrieved without problems by the Storehelper.handleTransactions().
Testing now with the Sandbox.

@chriswitko Glad it works in production though, I was afraid something is very wrong with the Subscriptions on MacOS and they're not really usable.

OK, tested in the sandbox environment too, and it's the same as with local testing. Deleting the caches helps here too.

I've made some minor changes and done a fair bit of testing. I think subscriptions are now correctly auto-renewing when the app isn't running (i.e. they're picked up correctly when the app restarts). This is for local StoreKit and Sandbox testing. I don't want to do anything too drastic as I don't want to break something that is working correctly in production!

@russell-archer now it works properly :) thank for the fix!

authors: bogdanf chriswitko russell-archer

repo: russell-archer/StoreHelper


text:
feat: add parent argument to setup function

By exposing the parent argument of selectAll to the user via S.setup, we allow the user to pass in a different parent element to execute the step selector against.
fixes #123 by allowing the user to pass in a shadow root as the parent, successfully selecting the provided steps. By replacing line 38 of this gist with
scrollama().setup({ step: '.step', parent: document.getElementById(shadowElement).shadowRoot })

we correctly select .step elements within the shadow dom.

great, thanks!

source: gharchive/pull-request

authors: emma-k-alexandra russellgoldenberg

repo: russellgoldenberg/scrollama

license: mit

license_type: permissive

license_source: bigquery


text:
Release wasm binaries

For adding RA to the playground, it would be nice to have wasm binaries in releases in addition to linux, windows, vsix and ... so the building logic can be separated from playground and we can select between RA versions in playground, which enables using it to share code in issues and see behavior of latest RA instantly (like how playground is used in rustc and clippy).
I see three options:

Do nothing. Playground can use a specific RA version, and bump it manually, occasionally (for example once a year).
Declare interface in rust-analyzer-wasm repo as stable (after some changes) and build wasm binary for each release with that interface.
Compile RA (after stripping unnecessary parts) as is to WASI, so LSP will become the interface. It would make the binary bigger probably, but it will enable to use it in web extension easily. Web extension should be possible with 2, but it needs a completely different code for the extension. It can also be used for targets that we don't have build officially, but they will probably prefer building from source to using 10x slower wasm.

@shepmaster is it ok to import RA wasm from third party in playground? If it isn't and we need to self host it, we can go with 1 and defer releasing wasm binaries to when another usecase appears for them.

I think compiling for WASI is quite compelling. The lack of rust-src is pretty unfortunate, but could probably be worked around. And I don't think we will be able to support proc macros.

I do not wish to have uncontrolled versions for anything in the playground. The crates, Rust dependencies, JS dependencies, and Ruby dependencies are all pinned to specific versions. The only thing that isn’t is the version of Rust / Cargo itself which changes automatically.

It will be more like user controlled than uncontrolled updates. (We need user control anyway, due to heavy downloads) But I understand that even this may not be ok. So I'm closing this issue for now.
If in the future someone become interested in building for wasi, first step is to make tool-chain, fly-check and proc-macro-srv optional, then we need an alternative interface in project-model, and some dependencies need some trivial fix and then it should work.

I don't think I follow your decisions; some things appear to be mixed together as well.

wasm binaries in releases

Seems reasonable.

the building logic can be separated from playground

Yes, that's good. Ideally the playground just grabs a working & tested binary from somewhere.

select between RA versions in playground

I don't understand why a user would want to select the version of rust-analyzer.

enables using it to share code in issues

I don't follow how this is related to any other points.

import RA wasm from third party in playground? If it isn't and we need to self host it

I wish to reduce third party resources required by the user's browser. That is, ideally all network requests from the playground go to play.rust-lang.org.
This doesn't mean that something couldn't come from another source at container / asset build time. We pull from crates.io for dependencies and some arbitrary GitHub repos for Wasm tooling, for example.

The only thing that isn’t is the version of Rust / Cargo itself

I lied a bit here — as you pointed out, Clippy, Miri, and Rustfmt are also automatically updated.
If rust-analyzer-wasm were shipped as a rustup component, for example, I'd be OK with that.
If rust-analyzer-wasm were uploaded somewhere "official" whenever it was released normally (weekly?), I'd be OK with that as well.

I think the issues idea was to share RA bug reproductions using the playground. But I don't think it's worth keeping around old versions like that.

enables using it to share code in issues

I don't follow how this is related to any other points.

If playground ships nightly or weekly releases, it can be used to reproduce RA bugs. Like how it is used in rust and clippy.

I don't understand why a user would want to select the version of rust-analyzer.

Switch between latest nightly, latest weekly and already downloaded one. Wasm binaries should be compatible with each other in some level, to prevent frequently invalidating old ones and redownloading.

If rust-analyzer-wasm were uploaded somewhere "official" whenever it was released normally (weekly?), I'd be OK with that as well.

That's the idea, official place is in this repo in the releases page.

This doesn't mean that something couldn't come from another source at container / asset build time. We pull from crates.io for dependencies and some arbitrary GitHub repos for Wasm tooling, for example.

That should work.

But I don't think it's worth keeping around old versions like that.

We don't need to keep old ones for download, but playground user should be able to keep one RA for a good time in their browser.

Prior art: https://ra-wasm.netlify.app/

After seeing #11255, I wonder whether a specifically-built-for-WASI binary crate would be a more maintainable solution, if we want a WASI build (if we only want it for playground integration, it would IMO make more sense to start with something specifically for that). We could maybe extract more parts from the rust-analyzer crate into their own crates, if there are things we would want to share. But I'm not sure a WASI LSP server is actually the best interface for integration in the playground.

A WASI LSP is best for using in web extension, and if we don't need a one size fit all solution, ra-wasm repo approach is better api for playground-like usages. So at this point I would suggest including ra-wasm's wasm-bindgen crate in the tree and releasing wasm binary of it. We can add wasi build in addition to that in future if needed.

A WASI LSP is best for using in web extension

Best for which criteria? Wouldn't it be possible there as well to use a similar approach to ra-wasm (directly calling functions exported by the WASM blob) instead of going through LSP? I guess the disadvantage might be needing more changes on the extension side, but I don't know how much that would actually be.

It would be possible. I mean, assuming we have a wasi lsp server and a wasm library, it would be easier to use wasi one for web extension. But considering cost of achieving and maintaining a wasi lsp server, it is not clear which one is better.

best for using in web extension

you mean specifically the Monaco editor’s implementation of extensions, correct? Is there some generic “web extension” that I am unfamiliar with?

Switch between latest nightly, latest weekly and already downloaded one.

That’s the what, but not the why.
As a normal user who navigates to the playground, why would I ever want to be presented with a choice of what rust-analyzer version I want to use?
Personally, I build rust-analyzer locally and use it with emacs, so I’m not a normal user. Assuming VS Code users are normal, are they presented with a choice of r-a versions from the extensions marketplace? If so, what prompted them to select different versions and what choices do they have?

I mean vscode's web extension, they are extensions that web builds of vscode, like https://github.dev can install them from marketplace. And they are completely unrelated to the playground.

@shepmaster In Code you can pick any version you want from the beginning of time, but we'd generally recommend installing the latest version. There's no "long-term support branch", for example, and it doesn't seem worth allowing that on the playground.

As a normal user who navigates to the playground, why would I ever want to be presented with a choice of what rust-analyzer version I want to use?

I, as a normal user of playground, prefer it to not upgrade automatically and download something every week I go to playground. And would prefer to update it occasionally. Auto update, never update (update by clear cache) and update on some logic are options, with their own cons.

@hf29h8sh321: Prior art: https://ra-wasm.netlify.app/

Could I perhaps look at how this was implemented? I'd love to hack on something like this!

Could I perhaps look at how this was implemented? I'd love to hack on something like this!

https://github.com/rust-analyzer/rust-analyzer-wasm

source: gharchive/issue

authors: HKalbasi flodiebold hf29h8sh321 lnicola nerdypepper shepmaster willcrichton

repo: rust-analyzer/rust-analyzer

license_source: github-api


text:
Unresolved import for a re-exported macro

Hi, rust-analyzer appears to be giving me unresolved import when importing tokio::main:
use anyhow::Result;
use tokio::main as wrapper; // unresolved import

#[wrapper]
async fn main() → Result<()> {
  // ...
}

I do know that directly using #[tokio::main] instead of use-aliasing it will avoid the complaints from rust-analyzer; however, I believe this error points to a deeper issue with specific imports that should be addressed.

However, the code compiles properly. Upon closer inspection of the source containing the tokio::main macro, I see that it is embedded with several layers of macros to handle cfg (to only export the macro when certain tokio features are enabled):
cfg_macros! {
    /// Implementation detail of the `select!` macro. This macro is **not**
    /// intended to be used as part of the public API and is permitted to
    /// change.
    #[doc(hidden)]
    pub use tokio_macros::select_priv_declare_output_enum;

    cfg_rt! {
        cfg_rt_multi_thread! {
            // This is the docs.rs case (with all features) so make sure macros
            // is included in doc(cfg).

            #[cfg(not(test))] // Work around for rust-lang/rust#62127
            #[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
            pub use tokio_macros::main;

            #[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
            pub use tokio_macros::test;
        }

        cfg_not_rt_multi_thread! {
            #[cfg(not(test))] // Work around for rust-lang/rust#62127
            pub use tokio_macros::main_rt as main;
            pub use tokio_macros::test_rt as test;
        }
    }

    // Always fail if rt is not enabled.
    cfg_not_rt! {
        #[cfg(not(test))]
        pub use tokio_macros::main_fail as main;
        pub use tokio_macros::test_fail as test;
    }
}

Perhaps it is the expansion of these macros, or the #[cfg(not(test))], that is tripping up rust-analyzer?

Does adding
    "rust-analyzer.procMacro.enable": true,
    "rust-analyzer.cargo.loadOutDirsFromCheck": true,

to your configuration fix the issue? Proc Macro support is disabled by default.

I already had those options enabled when I reported this issue. But good call, should have included that info in the report!
On Nov 7, 2020, 4:07 PM -0500, Arif Roktim notifications@github.com, wrote:

Does adding
"rust-analyzer.procMacro.enable": true,
"rust-analyzer.cargo.loadOutDirsFromCheck": true,
to your configuration fix the issue? Proc Macro support is disabled by default.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Perhaps it is the expansion of these macros, or the #[cfg(not(test))], that is tripping up rust-analyzer?

It is the #[cfg(not(test))]. rust-analyzer always enables the test cfg.
However it seems that the Rust issue this is working around, https://github.com/rust-lang/rust/issues/62127, has been fixed, so the workaround in tokio can probably be removed now.

Ah nevermind it was closed as wontfix.

This can be worked around by adding tokio-macros to the rust-analyzer.cargo.unsetTest setting now.

authors: ArifRoktim Veykril hulloitskai jonas-schievink stevenxie


text:
"Check on Save"/"cargo clippy" sometimes warns despite allow attribute

I am using VSCode, and I prefer to work with check on save set to cargo clippy instead of cargo check. I am using faux for testing. When a function is mocked, its arguments must be &String instead of &str. For this reason, I have had to add #[allow(clippy::ptr_arg)] to the various places where this is relevant.
Running cargo clippy in the terminal behaves as expected. The lint is muted when the allow line is in place. However, rust-analyzer's behavior is varied. When the allow line is present, sometimes the lint is suppressed and sometimes not.
This line, for example, works correctly:
#[allow(clippy::ptr_arg)]
pub fn send_confirmation(&self, email: &String, access_code: &String, settings: &Settings) {

Whereas with this line, the yellow squigglies and the IDE warning remain:
#[allow(clippy::ptr_arg)]
pub async fn select_access_code_by_email(&self, email: &String) -> Option<UserAccessCode> {

Could rust-analyzer's clippy output be somehow mis-firing for async functions? Perhaps async methods in impl blocks?

rust-analyzer just calls the cargo command you provided; there's really no way for it to influence the results on such a fine-grained level. Any difference in behavior almost surely comes from passing different flags, or a different working directory. Can you try to provide a minimal example that reproduces this? Also, try running cargo clippy with --all-targets and --all-features (depending on your configuration).

I can reproduce the behavior in the terminal by running cargo clippy --all-targets. Is there a way to change rust-analyzer to not use this flag for check on save?

I found the setting, but now I am worried that I am suppressing legitimate issues by turning this off. I'll do some more digging into this flag. Thanks for your help!

Yeah... This is non-workable as I now have no linting in tests.

I'd suggest reporting it in the clippy repository, unless it's clearly not a bug.

authors: flodiebold mbuscemi


text:
ItemTree: Lower tuple types despite invalid type

Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5380

bors r+

authors: flodiebold jonas-schievink


text:
Automated daily update to rustc (to nightly-2024-11-13)

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

Pull Request Test Coverage Report for Build 11829190282
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 82.47%

Totals

Change from base Build 11822813449:
0.0%

Covered Lines:
19773

Relevant Lines:
23976

💛  - Coveralls

authors: apoelstra coveralls

repo: rust-bitcoin/rust-bitcoin


text:
How would one cite this book in an academic resource?

See title, preferably in biblatex style.

This is what I came up with:
@book{embedded-rust,
  title = {The Embedded Rust Book},
  author = {},
  date = {},
  url = {https://docs.rust-embedded.org/book/},
  urldate = {2022-08-26},
}

Maybe the author would be 'Rust on Embedded Devices Working Group', but what could I put as date or the likes?

That seems OK. I probably would just leave a date accessed, the same as you might for a URL, or the date of the most recent commit when you viewed it. For author, "Rust Embedded Working Group & Contributors" or something like that would be fine.

Thank you. I changed it to the following:
@book{embedded-rust,
  title = {The Embedded Rust Book},
  author = {{Rust on Embedded Devices Working Group} and others},
  date = {}, % intentionally left empty
  url = {https://docs.rust-embedded.org/book/},
  urldate = {2022-08-26},
}

which is correctly handled (in IEEE format) as: Rust on Embedded Devices Working Group et al., The Embedded Rust Book. [Online]. Available: https://docs.rust-embedded.org/book (visited on 26/08/2022).
Would it be useful if I add the preferred citation at the end of the Introduction in a pull request?

Looks good. Maybe the best way to add it to the repository would be via GitHub's built-in support for citations:
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files
Ideally you'd write a CFF file with the same info, and then GitHub can parse it and render it to a bibtex or other formats depending on what people want. It looks like you could also just stick a CITATION.bib file in the repo root and it will at least offer 'Cite this repository' as an option, though without parsing or converting the file.

I chose to only PR the .bib file, due to the .cff file not supporting "et al." nor empty date fields. Feel free to let me know your thoughts.

authors: adamgreig cvvletter

repo: rust-embedded/book


text:
Remove enable_cs due to unsoundness

Breaking change. See rust-embedded/bare-metal#42 for discussion.

For completeness' sake, do you mind adding a CHANGELOG.md Removed entry and bumping the version number to 0.3.0?

Actually maybe we can change enable_cs to unsafe. This would prevent the misuse where the CriticalSection is used after enabling interrupts. The drawback is that we now have two unsafe APIs for enabling interrupts. What do you think?

@YuhanLiin Making it unsafe is a visible API change, and thus a breaking change. And passing in a CriticalSection is not actually doing anything useful in light of the fact that a user can clone a CriticalSection token.
I would rather get rid of enable_cs completely, and update the docs for enable from:
/// - Do not call this function inside an `interrupt::free` critical section

to something like:
/// - In any function `f()` that calls `enable`, `CriticalSection` or `&CriticalSection` tokens cannot be used in `f()`'s body after the
///   call to `enable`. If `f()` contains owns `CriticalSection` tokens, it is recommended to [`forget`](https://doc.rust-lang.org/nightly/core/mem/fn.forget.html)
///   these tokens before calling `enable`.

At least passing in a CriticalSection is still a valid optimization :D!

I remember the proc macro for that change being a pain to implement, so it's good that it doesn't need to be reverted.

bors r+

bors r+


text:
Make arbitrary an optional dependency, provide an MSRV of 1.47 without arbitrary

Fixes #57.
This also adds CI tests of the arbitrary-based example, which was previously untested.

Workaround for when I inevitably end up back here trying to fix things again - cargo update -p honggfuzz --precise "0.5.52"

Hi @TheBlueMatt,
Thanks for this PR! this LGTM!
Sorry for the looong delay!

authors: PaulGrandperrin TheBlueMatt

repo: rust-fuzz/honggfuzz-rs


text:
Allow the return type to be on next line.

In some cases, I find expanding the argument like
    pub fn alloc(
        &self,
        buf: disk::SectorBuf,
        description: &'static str,
    ) -> impl Future<page::Pointer, Error> {

excessive, so I prefer something like
    pub fn alloc(&self, buf: disk::SectorBuf, description: &'static str)
    -> impl Future<page::Pointer, Error> {

which is illegal per new proposal, if I understand it correctly.

My opinion is that when a function signature gets long enough that it must be split across multiple lines, even if that can be done by just splitting off the return type, then it is nearly always complex enough that it reads better on multiple lines (that is, one line per arg). In the given example, I do prefer the first version.
I think we discussed something very similar when discussing the function guidelines which is whether to allow formatting such as:
pub fn alloc(
    &self, buf: disk::SectorBuf, description: &'static str
)

We decided 'no' there and I think the same reasoning applies here.
I'm entering FCP to close. There hasn't been explicit support and I think it is covered by the reasoning from a previous discussion. Happy to un-FCP if there is a discussion to be had here.

We decided 'no' there and I think the same reasoning applies here.

I don't see how it applies here?

I don't see how it applies here?

The reasoning is that when a function is long enough to be split to multiple lines, we should do so for the sake of 'reading complexity', not try to do the minimal line breaking possible

The reasoning is that when a function is long enough to be split to multiple lines, we should do so for the sake of 'reading complexity', not try to do the minimal line breaking possible

The problem with 'reading complexity' is that as often as not the complexity is for a large part in the return part of the definition, but that this complexity doesn't extend to the argument list.
Some possibly illustrative examples:
From futures:

 fn poll(&mut self) -> Poll<Option<Self::Item>, Self::Error> {

From nom:

 pub fn tag_cl<'a,'b>(rec:&'a[u8]) -> Box<Fn(&'b[u8]) -> IResult<&'b[u8], &'b[u8]> + 'a> {

In the method department do I often see function declarations where the return specification is close to half the length of the declaration. The argument list is only self with sometimes one additional parameter. And when lifetimes are involved this often gets worse.
Though I have to concede that some of the code that ran into line breaking, might involve names that are rather long and might benefit from a cleaner module structure.

@internetionals I think you are right in that the complexity of args vs return type might be unrelated. However, it is generally pretty hard to get Rustfmt to reason about complexity vs line length. I think the only practical way to address this would be to have a length heuristic for the return type, if it is exceeded, then we put the return type on its own line. However, I think this is pretty much an edge case that this would happen where the whole line does not exceed the max width. So, I'd be open to incorporating such a heuristic, but I don't think it is important enough that we need to include it in the style guide or implement it right now.

@nrc I think that standpoint is reasonable and just wanted to point out that there are some valid cases worth considering, but I wholeheartedly agree that there are more important things right now to consider. And return signature complexity might (or might not, too soon to tell) change a lot once 'impl Trait' lands.

authors: internetionals nrc ticki

repo: rust-lang-nursery/fmt-rfcs


text:
Test attributes deserve their own section

cc @QuietMisdreavus and @steveklabnik for possibly out-of-scope documentation here.

Do not merge both this and the previous PR at the same time until I've edited the other PR to remove the "function-only attributes" section since the two PRs remove all of the attributes from that section.

With the other PR merged, this one now also handles removing the entirety of the "Function only items" section and can be merged.
Hmm, I probably should have done that in a new commit, but it's 2am and I'm not thinking straight. But wanted to get this unblocked before I head to bed. Sorry. The only change since the previous comment is just the removal of that header.

Thanks!

authors: Havvy matthewjasper

repo: rust-lang-nursery/reference


text:
Option to not insert spaces at beginning of comment lines

Examples:
-//TODO something
+// TODO something

-//debug!("{}", foo);
+// debug!("{}", foo);

I'd prefer to tell rustfmt to just leave those comments alone.

Seems a bit odd that it will do this when it doesn't remove spaces inside comments. Because it also does this (note that my editor puts the // at the start of the line when I tell it to comment-out code, then rustfmt indents again instead of just moving the //):
 fn foo() {
-//    do_something();
+    //    do_something();
     another_fn_call()
 }

authors: dhardy seanmonstar

repo: rust-lang-nursery/rustfmt


text:
Wrap long single field tuple struct

Closes #2125.

Thanks!

authors: nrc topecongiro


text:
Take rustfmt_skip attribute into account on modules

Closes #632

:+1:

authors: marcusklaas nrc


text:
Dead URL in windows install

The Windows installer suggests downloading the Visual C++ Build Tools 2015 from https://landinghub.visualstudio.com/visual-cpp-build-tools which gives a 404.
A quick google didn't manage to turn up any working links to the standalone installer.

Hmm https://www.visualstudio.com/downloads/ refers me to https://visualstudio.microsoft.com/vs/older-downloads/ for older versions. Clicking on the download button on that page requires me to log in to a microsoft account after which I am greeted by this page:

The old downloads don't seem to have an option for the community edition which might be why.

Further googling turned up this page https://www.microsoft.com/en-us/download/details.aspx?id=48159 which allows you to download "Microsoft Build Tools 2015"

Compiling with cargo now spews out massive error: linking with link.exe failed: exit code: 1 errors so presumably that doesn't actually install the right thing :/

For reference:
error: linking with link.exe failed: exit code: 1
|
= note: "link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build0.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build1.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build10.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build11.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build12.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build13.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build14.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build15.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build2.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build3.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build4.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build5.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build6.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build7.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build8.rcgu.o" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.build_script_build9.rcgu.o" "/OUT:C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.exe" "C:\Users\cleme\src\LocustDB\target\debug\build\heapsize-1b72f00bbd2c86b4\build_script_build-1b72f00bbd2c86b4.crate.allocator.rcgu.o" "/OPT:REF,NOICF" "/DEBUG" "/NATVIS:C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\intrinsic.natvis" "/NATVIS:C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\liballoc.natvis" "/NATVIS:C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\etc\libcore.natvis" "/LIBPATH:C:\Users\cleme\src\LocustDB\target\debug\deps" "/LIBPATH:C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-26ec27827ae0ca62.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libpanic_unwind-e34d54f3f9fdb6ac.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libunwind-419a8101e2d3fa6d.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liblibc-c0a4078a0099457d.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liballoc_system-d5549d68e4c6523f.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liballoc-73a63b968e0bb534.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcore-eb374a3dfd2a7a7f.rlib" "C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcompiler_builtins-fe8341acd189dfc1.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
= note: /usr/bin/link: extra operand ‘/LIBPATH:C:\Users\cleme\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib’
Try '/usr/bin/link --help' for more information.

I managed to get things working by getting the microsoft-visual-cpp-build-tools from chocolatey: https://chocolatey.org/packages/microsoft-visual-cpp-build-tools
This does require you to also install chocolatey first (and maybe Python).

Thanks, Microsoft, for breaking your URLs.
It seems hard to find a reliable URL to point to for the 2015 build tools, so we could probably start recommending the 2017 ones:
https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017
Though who knows how long that URL will survive.

There's also this URL: https://go.microsoft.com/fwlink/?linkid=840931. I'm not a Microsofter but I believe go.microsoft.com is their system to provide permalinks which redirect to the correct destination for their given content. Hopefully if they change the Visual Studio landing page again they'll update that redirect accordingly.

Should be fixed in 1.12

authors: Diggsey cswinter mattico


text:
cant install on bash Xenial in Windows 10

I have installed rust on the previous version of bash for windows (which is a 14.06 LTS Ubuntu) and it did install correctly, now (Xenial 16.04 LTS)  I get
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
 33.3 MiB /  33.3 MiB (100 %)  16.7 MiB/s ETA:   0 s
info: downloading component 'rust-std'
 40.6 MiB /  40.6 MiB (100 %)  17.9 MiB/s ETA:   0 s
info: downloading component 'rust-docs'
info: downloading component 'cargo'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: rolling back changes
error: could not rename component directory from '/home/laila/.rustup/tmp/cjhsyltqd0s3i317_dir/bk' to '/home/laila/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu'
error: could not rename component directory from '/home/laila/.rustup/tmp/4b_vekx73u6z0k7l_dir/bk' to '/home/laila/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/man'
warning: could not delete temp directory: /home/laila/.rustup/tmp/rr3a5s4svixw4mw2_dir
error: failed to install component: 'rust-docs-x86_64-unknown-linux-gnu', detected conflict: '"share/doc/rust/html"'
rustup: command failed: /tmp/tmp.8UVDwWa2ZW/rustup-init

I can install cargo and rustc with ^sudo apt install

rustup-init completes successfully on Ubuntu 16.04 LTS under Windows 10 build 14986, an Insider Preview release:
jdub@sliver:~$ curl -O https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 9500k  100 9500k    0     0  1153k      0  0:00:08  0:00:08 --:--:-- 1504k

jdub@sliver:~$ file rustup-init
rustup-init: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.9, not stripped

jdub@sliver:~$ chmod +x rustup-init

jdub@sliver:~$ ./rustup-init --version
rustup-init 1.0.0 (17b6d21 2016-12-15)

jdub@sliver:~$ ./rustup-init --no-modify-path -y
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
 47.1 MiB /  47.1 MiB (100 %)   1.1 MiB/s ETA:   0 s
info: downloading component 'rust-std'
 56.8 MiB /  56.8 MiB (100 %)   1.5 MiB/s ETA:   0 s
info: downloading component 'cargo'
  4.0 MiB /   4.0 MiB (100 %) 794.4 KiB/s ETA:   0 s
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: default toolchain set to 'stable'

  stable installed - rustc 1.14.0 (e8a012324 2016-12-16)

rustup component add rust-docs completes successfully (albeit very slowly, c.f. #904, though my CPU is being smashed by the "Antimalware Service Executable"), though can't delete its temp directories:
jdub@sliver:~$ .cargo/bin/rustup component add rust-docs
info: downloading component 'rust-docs'
  9.4 MiB /   9.4 MiB (100 %)   1.5 MiB/s ETA:   0 s
info: installing component 'rust-docs'
warning: could not delete temp directory: /home/jdub/.rustup/tmp/yxysh3m5z6nqmwbn_dir

Let's try that again with --verbose:
jdub@sliver:~$ .cargo/bin/rustup --verbose component add rust-docs
verbose: read metadata version: '12'
info: downloading component 'rust-docs'
verbose: creating temp file: /home/jdub/.rustup/tmp/763s_xkqn88_z58u_file
verbose: downloading file from: 'https://static.rust-lang.org/dist/2016-12-21/rust-docs-1.14.0-x86_64-unknown-linux-gnu.tar.gz'
verbose: downloading with curl
  9.4 MiB /   9.4 MiB (100 %)   1.5 MiB/s ETA:   0 s
verbose: checksum passed
info: installing component 'rust-docs'
verbose: creating temp directory: /home/jdub/.rustup/tmp/3v7v6n0p6013hydo_dir
# note: 99% of the time spent installing was spent here
verbose: creating temp file: /home/jdub/.rustup/tmp/0usmpuc_efm1muwf_file
verbose: creating temp file: /home/jdub/.rustup/tmp/vbgrea77pkduzc46_file
warning: could not delete temp directory: /home/jdub/.rustup/tmp/3v7v6n0p6013hydo_dir
verbose: deleted temp file: /home/jdub/.rustup/tmp/763s_xkqn88_z58u_file
verbose: creating temp file: /home/jdub/.rustup/tmp/k8716l1qrsxqrr32_file
verbose: creating temp file: /home/jdub/.rustup/tmp/guoxk3yftjt2hm5o_file
verbose: deleted temp file: /home/jdub/.rustup/tmp/0usmpuc_efm1muwf_file
verbose: deleted temp file: /home/jdub/.rustup/tmp/vbgrea77pkduzc46_file
verbose: deleted temp file: /home/jdub/.rustup/tmp/k8716l1qrsxqrr32_file
verbose: deleted temp file: /home/jdub/.rustup/tmp/guoxk3yftjt2hm5o_file

jdub@sliver:~$ .cargo/bin/rustup component list | grep docs
rust-docs-x86_64-unknown-linux-gnu (installed)

jdub@sliver:~$ du -sh $(.cargo/bin/rustc --print sysroot)/share/doc/rust
98M     /home/jdub/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust

jdub@sliver:~$ ls -lh .rustup/tmp/
total 0
drwxr-xr-x 0 jdub jdub 0 Jan  7 02:21 3v7v6n0p6013hydo_dir

jdub@sliver:~$ du -sh .rustup/tmp/
69M     .rustup/tmp/

Bah, should've run it with time. Oh well. 😄

Windows 10 14986, bash on Ubuntu on Windows
Input:
$ curl https://sh.rustup.rs -sSf | sh -s

Ouput:
info: downloading installer
curl: ../sysdeps/posix/getaddrinfo.c:2603：getaddrinfo: Assertion ‘IN6_IS_ADDR_V4MAPPED (sin6->sin6_addr.s6_addr32)’ failed.
Aborted (core dumped)
rustup: command failed: curl -sSfL https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init -o /tmp
/tmp.vDnemRar7t/rustup-init

I'm seeing similar behavior with rustup update running inside a docker container based on arm42v7/debian:stretch-slim itself running on an RaspberryPi 3.
Full log: rustup_arm_error.txt
Excerpt:
verbose: creating temp directory: /root/.rustup/tmp/l0a9w95vem0cyv22_dir
verbose: deleted temp directory: /root/.rustup/tmp/l0a9w95vem0cyv22_dir
info: rolling back changes
error: could not rename component directory from '/root/.rustup/toolchains/stable-armv7-unknown-linux-gnueabihf/lib/rustlib/etc' to '/root/.rustup/tmp/l0a9w95vem0cyv22_dir/bk'

# rustup --version
rustup 1.11.0 (e751ff9f8 2018-02-13)

Rustup works fine in WSL on Windows 10 1809, this issue could be probably closed.

Thanks @mati865


text:
crate version mismatch between cargo.toml and cargo.lock

Problem
When i am running cargo build --release in one of my projects. Cargo is downloading and compiling latest versions of crates mentioned in cargo.toml instead of the version i specified. so some of the latest crates which are getting downloaded have a msrv of 1.65 but i am using 1.64 because of which i am not able to compile my code and generate a binary. i haven't changes anything in my code recently. i am unable to find the cause behind this behaviour. Any help would be much appreciated!!.
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
cargo 1.64.0 (387270bc7 2022-09-16)
release: 1.64.0
commit-hash: 387270bc7f446d17869c7f208207c73231d6a252
commit-date: 2022-09-16
host: aarch64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.87.0 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.3.1 [64-bit]

cargo uses maximal compatible versions by default, rather than minimal compatible versions.
#8539 is for supporting minimal versions.
#9930 is for making the resolver MSRV-aware (hopefully by default)
I believe those capture the concerns mentioned in this issue, so I'm closing in favor of those.  If there is something I missed, let us know!

what can i do to strictly generate the binary with exact versions of dependencies i specified in cargo.toml?

Tracking Cargo.lock in your version control system is probably the best way I know at this moment.

@weihanglo. yes i am not checking in  cargo.lock file. i think that's what caused the issue.

authors: Mohan6677 epage weihanglo

repo: rust-lang/cargo


text:
Add a mechanism to inform cargo not to rebuild the crate after running build script

Build script is usually used to do code generating, and sometimes, even the build script is triggered to rerun, the output generated code may not change at all. In that case, rebuilding the whole crate (and all its dependants) doesn't make sense.
There should be a mechanism for build script to inform that a rebuild is not needed from it.

I guess a new special key from build script's output should work?

Does this happen often? I'd be curious about what percentage of builds rerun a build script but don't want to rebuild the crate...

I think with binding generated from C++ headers, that could happen more frequently than normal, especially when you use whitelist to include only specific types, functions, etc. in the result.

Hm I'm not sure I quite follow. Could you elaborate more on the example? Is the library being bound not being compiled into the crate? How is bindgen detecting that no changes are made? etc.

For example, if I have a C++ header:
class A { /* ... */ };
class B { /* ... */ };

For some reason, we only want to have A in the generated Rust code (because, for example, B contains something bindgen cannot convert correctly, or we ask bindgen to replace it with a different class for simplification), then the generated Rust file would be something like:
struct A { /* ... */ }

Now, whatever you do to B wouldn't affect the generated Rust code, and thus nothing actually needs to be rebuilt.
In larger projects, like Gecko, there are complicated dependencies between headers, and thus tons of headers, which may or may not affect the result, are indirectly included. But we only whitelist a small fraction of the types / functions declared in those files, and thus majority of changes to those files wouldn't really change the generated Rust code.
Bindgen library itself is not able to detect whether there is any change, but the build script can check whether the generated code is different from what currently inside the OUT_DIR, and if not, inform Cargo that nothing actually needs to happen.
FWIW, Gecko's build system has a mechanism to avoid updating generated file if its content is not changed, so that all its dependants would not be triggered to rebuild. (Gecko's build system requires a manifest to specify which file is generated by which script or function, so it can apply a generic mechanism for all generated files. This is different than the design of Cargo's build script, though.)

Oh, and, when you are debugging the build script, you may not really want the other part to build repeatedly as well.

@upsuper thanks for the explanation! That definitely makes sense to me!

#5663 includes some other use cases for this.

I have this issue with a project where build.rs is used to automatically generate test cases from a directory of test input/output files.
Specifically, it generates tests/black_box.rs which contains a #[test] function for each tests/black_box/*.json file.  In order to ensure the build script is run if I add new tests, I emit a rerun-if-changed=tests/black_box line.  This works for adding/removing *.json files, but it also re-runs any time I modify any of those files.  As a note: the tests/black_box.rs file depends only on the list of test files, not on their contents.
So any change to any test input causes a full 10 second re-link of the program, despite it being completely unnecessary.  The only alternative is to manually maintain the tests/black_box.rs file, but I automated it because I would sometimes add a bunch of tests at once and not notice I'd forgotten one.
As for why I do all this in build.rs and not some other script: build.rs is the only "hook" available which I can guarantee I don't forget to run.

My main concern with targeting use cases related to test generation is that means all of your dependents now need to build those dependencies and run your test generator.  #12552 would be an alternative solution though that would build on the same core as build.rs

If I'm understanding this issue correctly,build.rs are always writing out their data and cargo rebuilds because the mtime has changed.

Not sure about the author of the issue, however in my case the build.rs script checks if the output file is different to the one that it wants to write. If it isn't different, it doesn't try to write it. Actually this is the write_if_changed function you mentioned :sweat_smile:
But the problem is that the moment the build.rs was running, because it was triggered by some rerun-if-changed request, the entire crate rebuild. It would be nice that if the build.rs doesn't change any generated file, to also not rebuild the crate and every crate that follows in the dependency chain.

authors: DanielKeep alexcrichton bkchr ehuss epage upsuper


text:
path and registry shouldn't be mutually exclusive in dependency configurations

In multi-crate workspaces, dependencies to other crates in the workspace are specified with path when building locally, as well as version when the crate is pulled from a registry. If registry can't be used with path, then multi-crate workspaces that publish to a custom registry don't work.
cc @withoutboats

The check is made here: https://github.com/rust-lang/cargo/blob/868d37339117213fdef4ead8daf4a9557cc4ec89/src/cargo/util/toml/mod.rs#L930

Simply removing that restriction causes the registry field in the index entry to be the file path. It seems like the logic in https://github.com/rust-lang/cargo/pull/4568 is not quite right. The source ID of the dependency is going to be a file path here, which isn't right. cc @cswindle


text:
Improve cargo --list output (split output into sections)

(Related to #12114 , but the scope of that issue is bigger and this PR doesn't close it.)
What does this PR try to resolve?
cargo --list's output is really bad. It mixes aliases, builtin commands and external commands.
It would look something like this:
$ cargo --list
Installed Commands:
    add                  Add dependencies to a Cargo.toml manifest file
    b                    alias: build
    bench                Execute all benchmarks of a local package
    build                Compile a local package and all of its dependencies
    build-man            alias: run --package xtask-build-man --
    bump
    c                    alias: check
    check                Check a local package and all of its dependencies for errors
    checktests
    clean                Remove artifacts that cargo has generated in the past
    clippy               Checks a package to catch common mistakes and improve your Rust code.
    config               Inspect configuration values
    d                    alias: doc
    doc                  Build a package's documentation
    examples
    expand
    fetch                Fetch dependencies of a package from the network
    fix                  Automatically fix lint warnings reported by rustc
    flowistry
    fmt                  Formats all bin and lib files of the current crate using rustfmt.
    generate
    generate-lockfile    Generate the lockfile for a package
    git-checkout         This command has been removed
    help                 Displays help for a cargo subcommand
    init                 Create a new cargo package in an existing directory
    install              Install a Rust binary. Default location is $HOME/.cargo/bin
    is-tested
    locate-project       Print a JSON representation of a Cargo.toml file's location
    login                Save an api token from the registry locally. If token is not specified, it will be read from stdin.
    logout               Remove an API token from the registry locally
    metadata             Output the resolved dependencies of a package, the concrete used versions including overrides, in machine-readable format
    miri
    new                  Create a new cargo package at <path>
    owner                Manage the owners of a crate on the registry
    package              Assemble the local package into a distributable tarball
    pkgid                Print a fully qualified package specification
    publish              Upload a package to the registry
    r                    alias: run
    rdme
    read-manifest        Print a JSON representation of a Cargo.toml manifest.
    remove               Remove dependencies from a Cargo.toml manifest file
    report               Generate and display various kinds of reports
    rm                   alias: remove
    run                  Run a binary or example of the local package
    rustc                Compile a package, and pass extra options to the compiler
    rustdoc              Build a package's documentation, using specified custom flags.
    search               Search packages in crates.io
    set-version
    stale-label          alias: run --package xtask-stale-label --
    t                    alias: test
    test                 Execute all unit and integration tests and build examples of a local package
    tree                 Display a tree visualization of a dependency graph
    udeps
    uninstall            Remove a Rust binary
    unpublished          alias: run --package xtask-unpublished --
    update               Update dependencies as recorded in the local lock file
    upgrade
    vendor               Vendor all dependencies for a project locally
    verify-project       Check correctness of crate manifest
    version              Show version information
    watch
    yank                 Remove a pushed crate from the index

Finding a command is very hard in this list. That's why this PR aims to fix this list.
It groups builtin commands, external and aliases in three different sections. It also groups builtin commands with its builtin aliases.
    build, b             Compile a local package and all of its dependencies

The final output looks like this
$ cargo run -- --list
Installed Commands:
====================
  Builtin commands:
    add                  Add dependencies to a Cargo.toml manifest file
    bench                Execute all benchmarks of a local package
    build, b             Compile a local package and all of its dependencies
    check, c             Check a local package and all of its dependencies for errors
    clean                Remove artifacts that cargo has generated in the past
    config               Inspect configuration values
    doc, d               Build a package's documentation
    fetch                Fetch dependencies of a package from the network
    fix                  Automatically fix lint warnings reported by rustc
    generate-lockfile    Generate the lockfile for a package
    git-checkout         This command has been removed
    help                 Displays help for a cargo subcommand
    init                 Create a new cargo package in an existing directory
    install              Install a Rust binary. Default location is $HOME/.cargo/bin
    locate-project       Print a JSON representation of a Cargo.toml file's location
    login                Save an api token from the registry locally. If token is not specified, it will be read from stdin.
    logout               Remove an API token from the registry locally
    metadata             Output the resolved dependencies of a package, the concrete used versions including overrides, in machine-readable format
    new                  Create a new cargo package at <path>
    owner                Manage the owners of a crate on the registry
    package              Assemble the local package into a distributable tarball
    pkgid                Print a fully qualified package specification
    publish              Upload a package to the registry
    read-manifest        Print a JSON representation of a Cargo.toml manifest.
    remove, rm           Remove dependencies from a Cargo.toml manifest file
    report               Generate and display various kinds of reports
    run, r               Run a binary or example of the local package
    rustc                Compile a package, and pass extra options to the compiler
    rustdoc              Build a package's documentation, using specified custom flags.
    search               Search packages in crates.io
    test, t              Execute all unit and integration tests and build examples of a local package
    tree                 Display a tree visualization of a dependency graph
    uninstall            Remove a Rust binary
    update               Update dependencies as recorded in the local lock file
    vendor               Vendor all dependencies for a project locally
    verify-project       Check correctness of crate manifest
    version              Show version information
    yank                 Remove a pushed crate from the index
====================
  External commands:
    bump
    checktests
    clippy               Checks a package to catch common mistakes and improve your Rust code.
    examples
    expand
    flowistry
    fmt                  Formats all bin and lib files of the current crate using rustfmt.
    generate
    is-tested
    miri
    mommy
    rdme
    set-version
    udeps
    upgrade
    watch
====================
  Aliases:
    b                    build
    build-man            run --package xtask-build-man --
    c                    check
    d                    doc
    r                    run
    rm                   remove
    stale-label          run --package xtask-stale-label --
    t                    test
    unpublished          run --package xtask-unpublished --

How should we test and review this PR?
Execute cargo run -- --list (in the Cargo repository) and check that the output is better than before.

I'll close it and elaborate on #12114


text:
Try uploading test coverage to coveralls

Curious to see how this turns out on Travis!

r? @wycats
(rust_highfive has picked a reviewer for you, use r? to override)

Hm seems to increase CI times a bunch without perhaps much gain, ah well!

authors: alexcrichton rust-highfive


text:
"Versions" dropdown no longer populated.

This seems to be missing in every crate I've checked so far - both those recently updated and those that haven't updated in awhile.  No console errors, DOM doesn't appear to be populated, occurs in both Chrome (including with adblock disabled) and FireFox (which I don't have adblock installed for at all) on multiple computers.
Example: https://docs.rs/lazy_static/1.4.0/lazy_static/

Probably because of https://github.com/rust-lang/docs.rs/pull/546. cc @koenaad

Looks like the template is referring directly to versions, but we changed that field to releases.
https://github.com/rust-lang/docs.rs/blob/master/templates/navigation_rustdoc.hbs#L76

license: MIT


text:
Set explicit font size for topbar

Fixes https://github.com/rust-lang/rust/issues/93171.
Explanation: Since https://github.com/rust-lang/rust/pull/92448, the docs.rs topbar will misbehave when the user's font size is >16px. Some items in the navbar will overflow their allotted height of 33px. This wasn't happening before because the navbar was inheriting rustdoc's styles on the <body> element, which included font-size: 16px. It turns out docs.rs was implicitly relying on that font-size: 16px, so add it here explicitly.
To test: Set your browser font-size to anything >16px. Visit a documentation page. It should have the normal width.
/cc @cynecx @GuillaumeGomez @syphar

Looks good to me, just one question: did this issue appear after a specific rustdoc version? If so, please do like https://github.com/rust-lang/docs.rs/pull/1579.

Looks good to me, just one question: did this issue appear after a specific rustdoc version? If so, please do like #1579.

@jsha could you check this?
I'll wait with deploying until we know more

My understanding is that before the new CSS version, rustdoc specified 16px itself. So docs.rs specifying it again won't change anything, and adding a new copy of the docs.rs CSS just for this seems like overkill.

Yes, @jyn514 has it exactly right. The problem appeared after a specfic rustdoc version, but it's safe and correct to apply this style with all rustdoc versions, so we shouldn't split off a new copy of the CSS for it.

authors: GuillaumeGomez jsha jyn514 syphar


text:
Please provide bindings for the rebase API

See https://libgit2.github.com/libgit2/#HEAD/search/rebase .
Since the rebase API uses annotated commits, it would also help to have bindings to the other functions that create annotated commits, including git_annotated_commit_lookup and git_annotated_commit_from_revspec.

Sounds all good to me! Just waiting on an implementation :)

Currently tracking unimplemented APIs from libgit2 in this issue tracker, so I'm going to close this. PRs to add more support are of course always welcome!

authors: alexcrichton joshtriplett


text:
Init before creating Odb with new

This allows calling Odb::new() as first thing in a code base

Thanks!

authors: alexcrichton stoically


text:
Consolodate the Linux *_SUPER_MAGIC constants.

Move the Linux *_SUPER_MAGIC constants out of
android/uclibc/gnu-specific directories and into the common linux_like directory
so that they're available on all Linux-family platforms, and so that that all
Linux-family platforms have all the constants.

r? @Amanieu
(rust-highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit f7f06565f051144b313594672fc32a24635b6e8c has been approved by Amanieu

:hourglass: Testing commit f7f06565f051144b313594672fc32a24635b6e8c with merge df7bb3cbe8ca20b72753dd2a564d4adc76b14943...

:broken_heart: Test failed - checks-actions

I think this is the same as #2633: the musl version used in CI doesn't have the BINDERFS magic, which is causing the check to fail.

@bors r+

:pushpin: Commit d0891d93f27a7631ddb4c0fc19344e6c25229a70 has been approved by Amanieu

:hourglass: Testing commit d0891d93f27a7631ddb4c0fc19344e6c25229a70 with merge c0e0bf19bbc99b57bbce25bdab2d69cf21fe0771...

:broken_heart: Test failed - checks-actions

@bors r+

:pushpin: Commit 4875c52f56ade14fe84010488ebebb793271c613 has been approved by Amanieu

:hourglass: Testing commit 4875c52f56ade14fe84010488ebebb793271c613 with merge 33464a46b21dc648cd5d55a53dc24e589a824554...

:broken_heart: Test failed - checks-actions

@bors r+

:pushpin: Commit 338ac98a849d94f735e726bc4ca655925b4bce52 has been approved by Amanieu

:hourglass: Testing commit 338ac98a849d94f735e726bc4ca655925b4bce52 with merge a76930062c7406676e3b46ac9ac91480f2d04fa3...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing a76930062c7406676e3b46ac9ac91480f2d04fa3 to master...

authors: Amanieu bors rust-highfive sunfishcode

repo: rust-lang/libc


text:
Does Miri install into the correct rustup toolchain if it's not the default?

The current nightly doesn't have Miri, so I installed a nightly from a few days back to run nightly. I forgot to install rust-src, which Miri thoughtfully prompted me:
cargo +nightly-2019-08-01 miri --bin hash_file src/lib.rs
It seems you do not have the rust-src component installed. I will run `rustup component add rust-src`. Proceed? [Y/n]

Since it says what it would run, I assumed that it would not secretly run  rustup component add rust-src --toolchain nightly-2019-08-01 and canceled it. Would it have installed the component in the right toolchain for me?

It definitely would have run what it says.
But in an ideal world, rustup would set the right env var inside the commands it executes so that nested rustup invocations also apply to that toolchain. I will do some digging.

I tested this, and it seems to work fine. Looks like rustup is doing the right thing.

That's a good rustup.

authors: RalfJung shepmaster

repo: rust-lang/miri


text:
Use ui_test from crates.io instead of having it in-tree

I have moved a copy of the ui_test crate into a separate repo to facilitate the further non-miri development of it. I will keep syncing until we have reached a point where we don't touch it anymore for miri. At that point we can remove the in-tree version and do further development out of tree.

Hmm weird, it picked up the commits twice. I need to investigate.

Hmm weird, it picked up the commits twice. I need to investigate.

Ok I guess we'll always to squash merges when pulling

Ok I guess we'll always to squash merges when pulling

What do you mean by this?

What do you mean by this?

when we do a sync with the ui_test repo, we'll only see a single sync commit instead of all the commits that happened on the ui_test side.

Aha... So the usual process does not work? Why?
Anyway I dont think I care strongly about reflecting ui-test history in this repo. Please just add a section to the contributor docs saying exactly which commands one has to run for a sync.
Alternatively, we could just use a cargo git dependency pinned to a particular commit? Or would that make the rustc workspace unhappy?

Aha... So the usual process does not work? Why?

I think because subtree doesn't really work nicely for moving a subfolder out, it is meant for moving a separate repo into a subfolder.

Alternatively, we could just use a cargo git dependency pinned to a particular commit? Or would that make the rustc workspace unhappy?

We could just point to a regular crates.io dependency

Or, that too. You could give me access so I can publish new versions if needed.

You should have an invite

(changed PR title to match)

That repo having its last commit 28 days ago, it probably needs to be synced again?

At least https://github.com/rust-lang/miri/pull/2505 is not included.

published 0.1.1 with the latest changes.

I confirmed they are in sync. Thanks :)
@bors r+

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

:hourglass: Testing commit a33fb11894e0c1a21d6ddc1651811b7ea9937591 with merge f08b413161816843d358ff3e8181ebdc3d98bc42...

@bors r- retry
Ah wait can you update the lockfile to sue the 0.1.1 version? then r=me

@bors r=RalfJung

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

:hourglass: Testing commit fb071a14bd065da54c5bbc497033503932925cb2 with merge d5853bc724d469287ca3aeab2585413625f1a4ba...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing d5853bc724d469287ca3aeab2585413625f1a4ba to master...

At least https://github.com/rust-lang/miri/pull/2505 is not included.

authors: RalfJung bors oli-obk


text:
Unicode word-boundary matching doesn't follow UAX #29

The documentation of this crate tells me that \b matches a "Unicode word boundary", which it leaves undefined, but which I assume meant a word boundary according to UAX 29. But the word boundaries it gives me don't follow UAX 29, and therefore don't match other implementations such as Python's regex==2017.01.17 package or the Rust unicode-segmentation crate.
Here's a test case where the regex crate gives inconsistent results on a word containing an apostrophe. The regex \w(\B\S)* is supposed to match any word starting with a word character (\w) followed by any number of characters that do not cause word breaks (\B) and are not whitespace (\S):
    #[test]
    fn test_apostrophe() {
        let word_re: Regex = Regex::new(r"\w(\B\S)*").unwrap();
        let matches = word_re.find_iter("Here's a test");
        let words: Vec<&str> = matches.map(|m| m.as_str()).collect();
        assert_eq!(words, ["Here's", "a", "test"]);
    }

When I run this, regex considers the apostrophe to be a word boundary:
---- tests::test_apostrophe stdout ----
        thread 'tests::test_apostrophe' panicked at 'assertion failed: `(left == right)` (left: `["Here", "s", "a", "test"]`, right: `["Here\'s", "a", "test"]`)', src/lib.rs:182

But UAX 29, rule WB6 says that apostrophes that occur between two characters of class AHLetter are not word breaks: http://unicode.org/reports/tr29/#WB6

The documentation of this crate tells me that \b matches a "Unicode word boundary", which it leaves undefined

It's not undefined. The docs say:
\b    a Unicode word boundary (\w on one side and \W, \A, or \z on other)

where
\w     word character (\p{Alphabetic} + \p{M} + \d + \p{Pc} + \p{Join_Control})

In other words, this is much closer to "simple word boundaries" as defined in UTS 18.
Implementing UAX 29 (and most of UTS 18 level 2) appear to have major performance implications and therefore would require significant work. Python's regex engine isn't a useful data point for implementors, because it uses a completely different approach to matching.
There aren't any plans to pursue UTS 18 level 2 support. I'd be open to someone championing that, but I'm very skeptical that it can be feasibly done. (To be fair, I haven't spent much time thinking about what an implementation path looks like, mostly because it seems so intractable to me.)

One thing worth mentioning is that the docs could definitely be a lot better with being more precise about the extent of Unicode support.

Ah, I see.
Indeed, I notice that if I use the unicode-segmentation crate, it slows down segmentation to merely twice the speed of Python's implementation, which is quite a performance cost. I had thought that the slowdown came from my code, which is why I wanted to try an alternative implementation using regex, but the slowdown seems to be inherent.
So I understand the decision you made. It's a bummer not to be able to match words with apostrophes in them, though.

authors: BurntSushi rspeer

repo: rust-lang/regex


text:
RFC: Disallow interleaving commas after result blocks in match exprs

 Issue by bjz
Saturday Dec 21, 2013 at 00:19 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/11090
This issue was labelled with: A-grammar, B-RFC in the Rust repository

Currently you can do:
match x {
    A => (),  // exprs must end in a comma
    B => {}   // no comma needed after blocks
    C => {},  // a comma can still be added because `{}` is also an expr
    D => (),  // the comma is optional here, good for playing nice with diffs
}

Perhaps we could simplify the grammar so that each pattern/result pair is a form of :
<match-arm>  ::= <pattern> "=>" <expr>
<match-expr> ::= "match" <expr> "{" (<match-arm> ",")* <match-arm> [","] }

To illustrate what it might look like with bigger blocks, here is what is currently possible:
match x {
    A => (),
    B => {
        // some block stuff here
    }
    C => {
        // some more block stuff here
        // ...and here
    }
    D => blah_blah(),
}

Subjectively, I find the mixing of comma terminated exprs and non-comma terminated blocks distracting and a little ad-hoc. Compare to what would be required with the simpler grammar:
match x {
    A => (),
    B => {
        // some block stuff here
    },
    C => {
        // some more block stuff here
        // ...and here
    },
    D => blah_blah(),
}

I think this would be great. Still there's no official RFC for this.. is there more prediscussion needed?
Discussion in the [forum]http://internals.rust-lang.org/t/clarify-the-syntax-of-match-expressions/451) and in the original issue seemed good.

Since the language is now stable I don't think we can particularly change this, so closing.

repo: rust-lang/rfcs


text:
Amend RFC 2175 to support for loops and leading vert

This PR fixes RFC 2175 to also:

include leading | (already in match expressions)
include for loops (where the or-pattern must be irrefutable as in let bindings).

This is more or less a consistency bug-fix.

I agree that this RFC extended irrefutable patterns to allow |, so it makes sense for that to be the case in for too, not just let.  But that's not exactly just a typo, so let's get more eyes on it:
@rfcbot fcp merge

With my style team hat on, I don't think we should recommend using leading vert in any of these places. However, I don't have any objection allowing this if it drastically simplify the grammar. That said, @centril, can you please show how this simplifies the grammar enough to be worthwhile?

In full agreement wrt. style recommendations :)

That said, @Centril, can you please show how this simplifies the grammar enough to be worthwhile?

Certainly! Here goes a review of grammatical simplifications:
The status quo (i.e. with RFC 2071) is that we have (formulated for maximum clarity):
// Important bits:

let_pat : pat ('|' pat)* ;
match_pat : '|'? let_pat ;
for_pat : pat ;

// Where they are used:

expr_if_let : IF LET let_pat '=' expr '{' block '}' else_tail ? ;
expr_while_let : maybe_label WHILE LET let_pat '=' expr '{' block '}' ;
let : LET let_pat maybe_ty_ascription maybe_init_expr ';' ;

expr_for : maybe_label FOR for_pat IN expr_nostruct block ;

match_arm : maybe_outer_attrs match_pat (IF expr_nostruct)? FAT_ARROW ;

// Details of `match ... { .. }`:

expr_match : MATCH expr_nostruct '{' match_clause* nonblock_match_clause? '}' ;
match_clause : nonblock_match_clause ',' | block_match_clause ','? ;
nonblock_match_clause : match_arm (nonblock_expr | block_expr_dot) ;
block_match_clause : match_arm (block | block_expr) ;

what this PR does is unify first bits of the grammar so that we get:
let_pat   : '|'? pat ('|' pat)* ;
match_pat : '|'? pat ('|' pat)* ;
for_pat   : '|'? pat ('|' pat)* ;

since these are all equivalent, our grammar becomes just:
pats_or : '|'? pat ('|' pat)* ;

expr_if_let : IF LET pats_or '=' expr '{' block '}' else_tail ? ;
expr_while_let : maybe_label WHILE LET pats_or '=' expr '{' block '}' ;
let : LET pats_or maybe_ty_ascription maybe_init_expr ';' ;

expr_for : maybe_label FOR pats_or IN expr_nostruct block ;

match_arm : maybe_outer_attrs pats_or (IF expr_nostruct)? FAT_ARROW ;

// as before...

I would not call this simplification drastic, but it is simplification that makes the language have less corner cases and thus makes it easier for users to understand. Another benefit is that macros in particular have an easier time when you avoid syntactic corner cases.
As a note about style, observe that rustfmt already will convert:
match foo {
    | A => {},
    | B => {},
    | C => {},
}

into:
match foo {
    A => {},
    B => {},
    C => {},
}

The rustfmt tool should, for consistency, apply this rule for any leading | whether it be for match, if let, while let, let, for.

authors: Centril joshtriplett scottmcm


text:
Identifiers ending with digits are highlighted as 2 separate parts.

If an identifier ends with a digit (not followed by any letter or underscore), the digit is highlighted separately from the rest of the identifier.
Also, slightly unrelated request: the keywords 'mut' and 'self' being the same color as all others in the middle of code is a worse situation that it'd been before ('self' and 'mut' were turquoise in Monokai, while now they're the same red shade as all others).

You might want to report this to Ace (the editor used by the playpen): https://github.com/ajaxorg/ace

Is this common procedure? Since this's a Rust-specific issue, so maybe a maintainer reporting it would push things faster.
This issue is still true.

I'm not sure, but there's not much that can be done in this repo, so opening an issue upstream at all can get it fixed faster

I submitted a fix for this as ajaxorg/ace#3083

The upstream fix has been accepted, we now need to
a) either wait for a new version of ace to be released (which may take several months, looking at the schedule of previous releases) or
b) build a version of ace ourselves.

authors: Enamex TimNN jonas-schievink

repo: rust-lang/rust-playpen


text:
Internal error if license check fails

When the license header in rust code file doesn't match license template, cargo fmt would panic with internal error: entered unreachable code.
Backtrace is as follows:
$ RUST_BACKTRACE=1 cargo fmt
thread 'main' panicked at 'internal error: entered unreachable code', src/tools/rustfmt/src/formatting.rs:322:18
stack backtrace:
   0: std::panicking::default_hook::{{closure}}
   1: std::panicking::default_hook
   2: std::panicking::rust_panic_with_hook
   3: std::panicking::begin_panic
   4: <rustfmt_nightly::format_report_formatter::FormatReportFormatter as core::fmt::Display>::fmt
   5: core::fmt::write
   6: <std::io::stdio::Stderr as std::io::Write>::write_fmt
   7: std::io::stdio::_eprint
   8: rustfmt::format_and_emit_report
   9: rustfmt_nightly::Session<T>::override_config
  10: rustfmt::execute
  11: rustfmt::main
  12: std::rt::lang_start::{{closure}}
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: std::rt::lang_start_internal
  16: main

Meta
$ rustc --version --verbose
rustc 1.38.0-nightly (cd2cd4c96 2019-07-10)
binary: rustc
commit-hash: cd2cd4c9627e52c33e68e8c93a8916dc11094cbb
commit-date: 2019-07-10
host: x86_64-apple-darwin
release: 1.38.0-nightly
LLVM version: 8.0

$ cargo fmt --version
rustfmt 1.3.0-nightly (d3345024 2019-06-09)

Demo
I created a repo reproducing this issue at here.

I can reproduce this with 1.3.0, but I cannot reproduce this on 1.3.2. Are you able to reproduce with 1.3.2?

I think this issue can be closed as it was fixed in 1.3.1 https://github.com/rust-lang/rustfmt/pull/3655.
Please @shaopengw reopen if you still have a problem with the latest release.

authors: calebcartwright scampi shaopengw

repo: rust-lang/rustfmt


text:
Fix typos in changelog

@Thomasdezeeuw

Thanks.

Thanks.

authors: Thomasdezeeuw tamird


text:
Implement From for Complex

Right now, this crate lets us convert real types like i32 to Complex<i32> by implementing From<T> for Complex<T> (source). Awesome!
Would you consider adding mixed-type conversions, i.e., implement From<U> for Complex<T>? Ideally all the implementors from std::convert::From would be available so one could convert, e.g., 3i16 to Complex64, etc.
I think this could be relevant to #4 but also help more issues in that vein. (I ran into it when attempting to create mixed-domain/mixed-precision vector-addition, and couldn't implement this in my own library because of the orphan rule.)
I can take a shot at a pull request, if you think this is worthwhile and has some possibility of being done correctly by a Rust noob?

I don't think it's possible, because of the core impl From<T> for T.  At least, when I try to replace the current implementations of From with:
impl<T: Clone + Num + From<U>, U> From<U> for Complex<T> {
    #[inline]
    fn from(re: U) -> Complex<T> {
        Complex { re: T::from(re), im: T::zero() }
    }
}

I get:
error[E0119]: conflicting implementations of trait `std::convert::From<Complex<_>>` for type `Complex<_>`:
   --> src/lib.rs:403:1
    |
403 | / impl<T: Clone + Num + From<U>, U> From<U> for Complex<T> {
404 | |     #[inline]
405 | |     fn from(re: U) -> Complex<T> {
406 | |         Complex { re: T::from(re), im: T::zero() }
407 | |     }
408 | | }
    | |_^
    |
    = note: conflicting implementation in crate `core`

But if you can figure out how to make that work, I'll consider it!

Ah, I see, very interesting! I found a reasonably lucid explanation of the problem in this blog post (search for 'conflicting implementations of trait', and the links therein), though in a slightly different context.
If I understand, Rust has to allow for the possibility that, when we say impl<T, U> From<U> for Complex<T>, hypothetically U == Complex<T>, in which case the new implementation is a redefinition of impl<T> From<T> for T from core.
How frustrating!
The solution in that blog post, however, is to implement not From<U> but From<&U>, a reference to the "smaller" type. You already have impl<'a, T: Clone + Num> From<&'a T> for Complex<T> (source), which you could replace with a impl<'a, U, T> version, without any loss of generality (I think):
impl<'a, U, T> From<&'a U> for Complex<T>
where
    U: Clone + Num,
    T: Num + From<U>,
{
    #[inline]
    fn from(re: &'a U) -> Complex<T> {
        Complex {
            re: T::from(re.clone()),
            im: T::zero(),
        }
    }
}

Then, the following test passes:
    #[test]
    fn test_from() {
        let n = 3i16;
        let c: Complex64 = Complex::from(&n);
        let d = Complex { re: 3., im: 0. };
        assert_eq!(c.re, d.re);
        assert_eq!(c.im, d.im);

        let e = Complex64::from(&2.2f64);
        assert_eq!(e.re, 2.2f64);
        assert_eq!(e.im, 0.0);
    }

The downside is that you'd have to remove both From for Complex implementations that you have currently, including the impl<T: Clone + Num> From<T> for Complex<T>, because this latter conflicts with the one above. That is, you wouldn't be able to call Complex::from on values, only references.
Do you think this is too high a price to pay? The reward would be mixed-precision/mixed-domain capability, so you can add Complex64 to i16, etc.

Note that scheme hurts type inference, as you had to force it to Complex64 in both of your examples.

let c: Complex64 = Complex::from(&n);
let e = Complex64::from(&2.2f64);

The partner trait Into is also less ergonomic when you add the & indirection.  Imagine you had a trait Foo: Into<Complex64>.  Now you'd have to write trait Foo where for<'a> &'a Self: Into<Complex64>.  Per rust-lang/rust#20671, that where clause also can't be implied by Foo, but has to be repeated everywhere Foo is used.
Do you need this to use a direct From?  You should already be able to do the two-layer conversion yourself, Complex::from(f64::from(n)).  It would also be easy to add a plain method along these lines, avoiding a breaking change to From altogether, something like:
impl<T: Clone + Num> Complex<T> {
   pub fn from_real<R: Into<T>>(re: R) -> Self {
      Complex::from(re.into())
   }
}

Ahh, you are absolutely right—and there we see the difference between the noob and the guru 😅!
Let me press on with implementing more of my library (a BLIS port to Rust) with your crate as it is now, and think a bit harder about how to do mixed-precision and mixed-mode. I think that the right place to tweak num-complex would be in the implementations of Add, Sub, etc., so that we could add real+complex, complex+real, and complex+complex with different types, as long as From is available between the underlying real types—but let me think about it a bit more to see if I'm right. Thanks for your thoughtfulness and advice!

No need to worry about noobs and gurus -- we'll come to agreement either way. :smile:

I think that the right place to tweak num-complex would be in the implementations of Add, Sub, etc., so that we could add real+complex, complex+real, and complex+complex with different types, as long as From is available between the underlying real types

That would be atypical for Rust -- note that the operators for primitive integers and floats don't do From conversions either.  Idiomatic Rust generally prefers explicit numeric conversions.
You might then ask why we should bother with real OP complex and complex OP real at all, but there's at least some argument that the operation can be implemented more simply or more accurately than complex OP complex.  (Even if we don't do that yet, as noted in #4.)

I understand better now how Rust asking you to do explicit conversion is an important precedent. My concern would be in dealing with vectors (or matrixes or tensors) where speed is paramount, e.g., when I have a billion Complex<f32> and a billion i16s and want to add the latter into the former quickly, I don't want to convert before handing them off to my linear algebra addv routine. Also, I'd love it if that addv function not need to know about the types of its two inputs, just that lower-level they can be Fromed/Intod.
(Perhaps some useless background—right now, BLIS is a C99 library and does not yet do mixed-mode/mixed-precision arithmetic. Its addv can only add the exact same types. With Rust and your crate, my addv can at least do mixed-mode! That is, I can add Complex<f64> and f64 vectors, with my noob-level skill with generics/traits. Mixed-precision would be the next desideratum.)
Again, many thanks for being so generous with your time!

authors: cuviper fasiha

repo: rust-num/num-complex


text:
Unusual breaking change introduced in 0.2.6

The following code builds fine on 0.2.5, but fails to compile on 0.2.6. Extremely unusually, testing seems to indicate that was introduced in d2bf4e04e, a rustfmt commit.
extern crate num_traits;
use num_traits::*;

pub trait Trait {
    type Num: PrimInt + CheckedShl;
}
pub fn function<T: Trait>(b: usize) -> T::Num {
  T::Num::one() << b
}

Error encountered:
error[E0308]: mismatched types
 --> src/lib.rs:8:20
  |
8 |   T::Num::one() << b
  |                    ^ expected u32, found usize

Moving the associated type's bounds directly into the trait bounds for T, as well as removing the bound on CheckedShl both seem to clear this error.
Changing the body of function to Shl::<usize>::shl(T::Num::one(), b) also clears the error, proving that an implementation of Shl<usize> does exist for T::Repr.
This seems to be due a bug in rustc, where the order that traits are declared in influences their resolution in operators.

Very strange!
For reference, I see that you also filed a rustc issue: https://github.com/rust-lang/rust/issues/54296

Extremely unusually, testing seems to indicate that was introduced in d2bf4e0, a rustfmt commit.

In particular, rustfmt sorted the mod declarations, so now int comes before ops here:
https://github.com/rust-num/num-traits/commit/d2bf4e04e43add49c4ab6b7df794501b09d0a081#diff-b4aea3e418ccdb71239b96952d9cddb6R53
If I just swap those two lines, your example works again.
Yet even that is fickle.  I swapped the lines and got it to build, then swapped back and it still built!  But cargo clean then build fails again, so I guess incremental compiling is interfering here too.

Seems to have been long fixed upstream.

authors: Lymia cuviper

repo: rust-num/num-traits


text:
Integrate common floating point constants

In most of my implementations involving generic floating point values I have the need to work with pi and/or e. Thus it would be really helpful to provide static functions to retrieve those values for the concrete type.

In general, let e = Float::one().exp(); and  let pi = (-Float::one()).acos(); should work.  We could provide these as default implementations and override the specific constants for f32 and f64.

Associated constants would be nice too, rust-lang/rust#29646, but we couldn't provide defaults there.

I agree that pretty much every mathematical constant can be computed using the methods that are already there. However, (-Float::one()).acos() and alike obscure the actual algorithm. Do we really want to see people in the Rust community writing this kind of generic code? Besides, who is willing to guarantee that (-Float::one()).acos() is indeed a zero-cost abstraction?

No, I don't expect people should do that -- it's just a way to write a generic default so it's not a breaking change.  We can provide the proper constants in the implementation for the concrete float types.
Care to write up a PR?

@cuviper, first of all, I apologize if it sounded rude; no offense was intended. I’m an active user of num and really appreciate your work.
Yes, absolutely. If there are no objections, I’ll be happy to help.

No problem, sorry if I sounded too defensive. :)

Fixed by #220 -- thanks @IvanUkhov!

authors: IvanUkhov b52 cuviper

repo: rust-num/num


text:
This Month in Rust OSDev: August 2022

This is a draft for the upcoming "This Month in Rust OSDev: August 2022" post. Please add your content to this draft by creating a pull request against the next branch. All projects related to OS development in Rust are valid here, they don't need to be associated with the rust-osdev organization.
The July post will be published in the first week of September.

It's time to prepare the new release! Please submit pull requests for all projects that you want to include in this issue.
I filled in the changes for the rust-osdev crates based on the autogenerated changelogs from the new collect-changes script. Feel free to open PRs if you like to make adjustments. cc @rust-osdev/uefi @rust-osdev/xhci @rust-osdev/acpi

Published at https://rust-osdev.com/this-month/2022-08/.
I created a draft PR for the September post in https://github.com/rust-osdev/homepage/pull/117.

repo: rust-osdev/homepage


text:
Fix status to Result conversions

Following the changes in https://github.com/rust-osdev/uefi-rs/issues/360, warning status were supposed to be treated as errors when converted to Results. But instead they were incorrectly being converted to Result::Ok. Fix that, and add a new unit test for that case.

I missed this rather important conversion bug in #361! :flushed:

Oops, good catch. I guess it's a good thing we didn't rush with the new release :))

authors: GabrielMajeri nicholasbishop

repo: rust-osdev/uefi-rs


text:
feat: fix and test examples in docs

Added an extra unwrap to unwrap Option<Device> in both examples.
Just a minor addition to help newbies to rust :smiley:.

Unfortunately, it looks like due to permission errors this test cannot be added.
I have two suggestions:

Either you can figure out how to can around the permission issues, OR
You re-add the ignore label, but leave the other changes.

No worries! I think I'll re-add the ignore label and add a footnote to mention that to examples actually should work (in normal circumstances).

Note that the permissions issue is the same as in #285 which I've tried to dodge by using a feature flag instead of the 'ignore' option.  Feedback welcome, but IMHO the feature flag is a cleaner way to say "this test should work".

Resolved by #296

authors: Wojtek242 lockness-Ko robs-zeynet

repo: rust-pcap/pcap


text:
add a stucts-and-tuples chapter

Writes up what I believe to be the consensus around layout of structs and tuples. Suggestions very welcome!
Here are some of the highlights:

Tuples are defined to be laid out as if there were a "fresh generic struct" for their arity. So (T1...Tn) is laid out the same as TupleN<T1..Tn> where struct TupleN<P0..Pn>(P0..Pn).

There is an exception for the case where all the types are the same (after lifetime erasure), in which case the layout is guaranteed to be compatible with [T; N].

Tuple structs are laid out the same as "named fields".
#[repr(Rust)] structs (the default) have no particular layout guarantees. In particular, even if two #[repr(Rust)] structs have the fields of the same types, they are not guaranteed to be laid out in a compatible way. This is a conservative position that could be strengthened, though I personally now think it'd be better to "opt-in" to any such guarantees. I cover the pros and cons in the doc.
#[repr(C)], #[repr(align)], #[repr(packed)], and #[repr(transparent)] are all discussed.

Fixes #11 and #12.

Pushed an update containing the various suggestions from @eddyb.

Long ago I proposed that we might want to guarantee (some subset of) newtype unpacking for repr(Rust) structs. @nikomatsakis carried this over into #11 as discussion point but it received no further discussion. I like to think that means it's uncontroversial 😄 I've also never heard of any reason why one might not want that to be true.
To make a specific proposal, let's restrict it to structs [1] that contain a single field having the same memory layout as the type of the sole field. So struct Foo<T>(T); and struct Foo<T> { x: T } would be laid out like T in memory, though possibly still passed differently in function calls.
[1] The same guarantee for (T,) are already covered by the special case of homogeneous tuples being laid out like arrays that is already in this PR.

@rkruppe for (T,) the .0 field is public, in Foo<T> it is not. The members of the tuple are guaranteed to never change for that type but since Foo has private fields it is a non-breaking change to add new fields which would remove the layout guarantee.
So shouldn't that guarantee be restricted to structs with a single public field? Or at least there should be a lint if such transmutations are used by a crate that does not own Foo.

Visibility should not affect layout, only who can rely on the layout.

That might be worth documenting.
Still, it might be better to document the intent of such structs with repr(transparent).

I have made a number of edits addressing various concerns. The most significant is that I pulled out some controversial topics and marked them as "Unresolved Questions". I plan to open issues for each of them to continue the conversation. I am marking this with the final-comment-period label — we plan the merge the PR next meeting unless major controversy arises.

Here is the set of unresolved questions:
Zero-sized structs (#37). If you have a struct which --
transitively -- contains no data of non-zero size, then the size of
that struct will be zero as well. These zero-sized structs appear
frequently as exceptions in other layout considerations (e.g.,
single-field structs). An example of such a struct is
std::marker::PhantomData.
Single-field structs (#34). If you have a struct with single field
(struct Foo { x: T }), should we guarantee that the memory layout of
Foo is identical to the memory layout of T (note that ABI details
around function calls may still draw a distinction, which is why
#[repr(transparent)] is needed). What about zero-sized types like
PhantomData?
Homogeneous structs (#36). If you have homogeneous structs, where all
the N fields are of a single type T, can we guarantee a mapping to
the memory layout of [T; N]? How do we map between the field names
and the indices? What about zero-sized types?
Deterministic layout ([#35]). Can we say that layout is some deterministic
function of a certain, fixed set of inputs? This would allow you to be
sure that if you do not alter those inputs, your struct layout would
not change, even if it meant that you can't predict precisely what it
will be. For example, we might say that struct layout is a function of
the struct's generic types and its substitutions, full stop -- this
would imply that any two structs with the same definition are laid out
the same. This might interfere with our ability to do profile-guided
layout or to analyze how a struct is used and optimize based on
that. Some would call that a feature.

I pushed some updates. The most interesting thing has to do with zero-sized structs. I added the following text to the #[repr(C)] section:

One deviation from C comes about with "empty structs". In Rust, a struct that contains (transitively) no data members is considered to have size zero, which is not something that exists in C. This includes a struct like #[repr(C)] struct Foo { }. Further, when a #[repr(C)] struct has a field whose type has zero-size, that field may induce padding due to its alignment, but will not otherwise affect the offsets of subsequent fields (as it takes up zero space).

@avadacatavra my hope was that we will merge it today

OK, I attempted to summarize the conversation from here in the latest commit and added some appropriate warning language.

It looks like gcc (the only compiler which has implemented [[no_unique_address]]), has chosen:

to put [[no_unique_address]] members at the top of the class holding them

(see https://gcc.godbolt.org/z/Q4oFIR - note that this is technically UB).
Alignment does still matter tho: https://gcc.godbolt.org/z/Pn1eqo

I'm going to merge this, and any additions can be filed as followup issues/PRs (cc @nikomatsakis)

authors: avadacatavra nikomatsakis rkruppe the8472 ubsan

repo: rust-rfcs/unsafe-code-guidelines


text:
Publish mshv-bindings and mshv-ioctls

The vfio-ioctls depends on these two crates, so they need to be published.

Is this urgent? @russell-islam is on vacation this month.

Is this urgent? @russell-islam is on vacation this month.

Hope that we could publish vfio-ioctls this year:)
Do you mean @russell-islam will be back to work on next year?

Is this urgent? @russell-islam is on vacation this month.

Hope that we could publish vfio-ioctls this year:) Do you mean @russell-islam will be back to work on next year?

He will be gone most of the month so realistically I expect him to be active again next year.
I can have a look at publishing the crates next week.

Is this urgent? @russell-islam is on vacation this month.

Hope that we could publish vfio-ioctls this year:) Do you mean @russell-islam will be back to work on next year?

He will be gone most of the month so realistically I expect him to be active again next year.
I can have a look at publishing the crates next week.

Thanks, @liuw

Unfortunately there are some loose ends that we need to tight up. I'm currently occupied.

See #25 . It needs to merged to meet the minimum standard for publishing.

The main point is that our interfaces are not stable yet. We need to pass that debate before a release.

Crates are now published on crates.io. https://crates.io/search?q=mshv Closing this issue now.

authors: jiangliu jinankjain liuw russell-islam

repo: rust-vmm/mshv


text:
🛑 Saridon is down

In 59e9be7, Saridon (https://saridon.co.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Saridon is back up in c04682f.


text:
Using async decorator uses type hints incompatable with with asyncio.run or asyncio.create_task

It would be nice to be able to use this with asyncio methods like run and create_task without needing to resort to escape hatches like typing.cast or #type: ignore. I'm not sure that is just having a result.as_coroutine_result or there's a better way.
An example case is the following:
from result import as_async_result
import random
import asyncio

@as_async_result(Exception)
async def example() -> str:
    if random.random() < 0.5:
        raise RuntimeError("Boom")
    return "made it"

task: str = asyncio.run( example() )
print(task)

Running mypy on that will produce the following error:
error: Argument 1 to "run" has incompatible type "Awaitable[Ok[str] | Err[Exception]]"; expected "Coroutine[Any, Any, Never]"

This function python async def awaiting(awaitable: Awaitable[T]) -> T:     return await awaitable  can do the trick to wrap awaitables into coroutines, alas, there is an additional await added.

What would be the reason for using Awaitable instead of Coroutine then? From what I can understand, Coroutines are defined using the async def, which I assume is the use-case for the async_as_result?
Awaitable is just a less specific type used for Coroutine, Future and Task.
I tried to locally change from Awaitable to Coroutine in the result-package in my use-case and mypy was happy.

authors: golgor kalebo nekitdev

repo: rustedpy/result


text:
bindgen unsafe functions

Motivation
JavaScript has no notion of safe and unsafe concerning Rust WASM modules. For example, you can directly write to linear memory with no safety guards. Therefore, it would make sense to allow calling Rust-unsafe functions from JavaScript. This would prevent calling these functions directly from Rust without the unsafe keyword, which Rust coders expect from logically unsafe functions. (Of course, you can use JS reflection from wasm_bindgen to do unsafe things from Rust code without the unsafe keyword, but this is like opening /proc/self/mem.)
Proposed Solution
Allow to bindgen unsafe functions by removing the lines https://github.com/rustwasm/wasm-bindgen/blob/main/crates/macro-support/src/parser.rs#L762-L764.
Alternatives
Because of #2429, you can create a pub, safe function in an impl of a private type. The function is then callable from JavaScript, but not from other Rust modules.
Additional Context
Needed to replace __wrap use in #3017

This would also be consistent to the C FFI, which allows to export functions to C that are not safely callable from Rust:
#[no_mangle]
pub unsafe extern "C" fn hello_from_rust() {
    println!("Hello from Rust!");
}

repo: rustwasm/wasm-bindgen


text:
'Tensor' object has no attribute 'keys'

❓ Questions & Help
Hey :)
I'm trying to get the Graculus MNIST work, but everytime I get the error:
AttributeError: 'Tensor' object has no attribute 'keys'.
The error comes from:
train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True)
Any idea why this isn't working? :)
Thank you :)

Downloaded the dataset again. Now it work's.


text:
Fix error in DenseGraphConv triggered when aggr is max

In original implementation of DenseGraphConv, dimention mismatch error occured when aggr is max.

# keep dimention while using max
# out = out.max(dim=-1)[0]
out = out.max(dim=-1, keepdim=True)[0]

# change the way to merge output of lin_rel and lin_root
# out += self.lin_root(x)
out = out + self.lin_root(x)

Thank you very much! Indeed, DenseGraphConv with max aggregation was really buggy. This is now fixed.