text:
SQLite3: add ability to set compile flags; add more versions

Per #803, here is an updated version of the SQLite3 package. The only substantive change I made from our discussion in the ticket was to drop support for "valueless" arguments like -DSQLITE_ENABLE_COLUMN_METADATA. In practice, this is equivalent to the ...=1 form and valueless args are not supported by hunter_cmake_args(..., CMAKE_ARGS FOO="") anyway (the value ends up being a single semicolon instead of the empty string and CMake complains about missing whitespace separators)

Closing inactive pull request.

authors: ruslo tdavis

repo: ruslo/hunter


text:
Updates botocore to latest master.

Latest master as of 9/20/16.

We've got some work to do on this to get it to compile!

source: gharchive/pull-request

repo: rusoto/rusoto

license: mit

license_type: permissive

license_source: bigquery


text:
Infinite loop in trait solving

When i try to run ra_cli analysis-stats on rust-analysis source code, it seem to be going in infinite loop inside https://github.com/rust-analyzer/rust-analyzer/blob/b22614f0b500c351d3abf33a4ed6beaea6861bca/crates/ra_hir/src/ty/traits.rs#L94
Is it because of the fuse things in Chalk we are talking in Zulip , or other reasons ?

It's not an infinite loop, just a very long one ;)
Are you on current master? I thought I made sure that with #1266 it worked again.

Yes i am in master (b22614f0b500c351d3abf33a4ed6beaea6861bca) , and i waited over 10 mins :), although my pc is quite old. (Windows i5-4440).

Hm, I must have accidentally tested with the wrong binary :( I'll look into it.

#1270 should fix this for rust-analyzer for now, at least it works for me again now. We need rust-lang/chalk#227 or something like that to make sure this can never happen, though.

Closed #1270

source: gharchive/issue

repo: rust-analyzer/rust-analyzer

license_source: github-api


text:
Hover: Show documentation

Closes #186

LGTM

@matklad is this good to go?

Ci's failing, otherwise LGTM!

It looks like it failed on the format check so I rebased and ran cargo fmt.

check so I rebased and ran cargo fmt.

The right command is cargo format: it'll run our own wrapper of rustfmt, wihc pins a specific version.

bors r+
Thanks!

bors retry

bors r+

authors: kjeremy matklad


text:
Added mdcheckr to detect broken links in Markdown

This will be the PR for checking for broken links in documentation, I will start adding it to more places as soon as we are happy with it here.
Please come with comments if there is something more that you'd like to add or change.

Any comments on the CHANGELOG link issue @rust-embedded/cortex-m ? I am unable to get around the scenario @japaric mentioned, unless removing the file from being checked. But it sub-optimal.

So eh, should we close this?

@korken89 Sounds good to me.

If we want to look into this again we can redo it

repo: rust-embedded/cortex-m-rt


text:
Add list of implementations and example mutex use

The example feels a bit half-hearted but I think it might still be worth having something like this. Very happy to take suggestions to improve the example, or any more implementations we should link.

Thanks! Anything else before a release?

can't think of anything, no.

authors: Dirbaio adamgreig

repo: rust-embedded/critical-section


text:
N17: Weegames

Part of #408

Thanks!

Thanks!


text:
ch13-02-iterators übersetzt

Diesmal sollten die Codeblöcke auch korrekt sein. ;)

This change is

Sehr schön, vielen Dank!

Die Seite ist mittlerweile auch online zu sehen:
https://rust-lang-de.github.io/rustbook-de/ch13-02-iterators.html

repo: rust-lang-de/rustbook-de


text:
Rustfmt adds tab in raw string

Using the latest master (fbdd0e815c80d0c7dde62cc541e866440039bafc) and 0.4.2, rustfmt is inserting an extraneous tab into the raw string:
Running rustfmt --check-mode=write test.rs
macro_rules! template {
    ($name: expr) => {
format_args!(r##"
"http://example.com"

# test
"##, $name)
    }
}

outputs
Diff in /home/alan/workspace/scratch/test.rs at line 1:
 macro_rules! template {
-    ($name: expr) => {
-format_args!(r##"
+    ($name:expr) => {
+        format_args!(r##"
 "http://example.com"
-
-# test
-"##, $name)
-    }
+
+        # test
+        "##, $name)
+    };
 }

internal error: left behind trailing whitespace
 --> /home/alan/workspace/scratch/test.rs:5
  |
5 |
  | ^^^^^^^^^^^^

AFAICT, this is some interaction between the macro declaration and the // in the URL (which is presumably being interpreted as a comment).

I can still reproduce. cc @nrc this breaks user code: it modifies the contents of a raw literal string.

authors: alanhdu gnzlbg

repo: rust-lang-nursery/rustfmt


text:
panicked at 'Box' ... syntex_syntax-0.30.0/src/parse/lexer/mod.rs:1438

$ echo '`'|RUST_BACKTRACE=1 ./rustfmt
stdin:1:1: 1:2 error: unknown start of token: `
stdin:1 `
        ^
thread '<main>' panicked at 'Box<Any>', /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/lexer/mod.rs:1438
stack backtrace:
   1:     0x55b3ed5af0b0 - std::sys::backtrace::tracing::imp::write::h3152d690c5b90b0c
   2:     0x55b3ed5b1bfb - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hb638acea7c29901b
   3:     0x55b3ed5b1882 - std::panicking::default_hook::h508c3dab3df347d6
   4:     0x55b3ed5a30ef - std::sys_common::unwind::begin_unwind_inner::h5cd31b1580026517
   5:     0x55b3ed29bba6 - std::sys_common::unwind::begin_unwind::h8a2d02a56698e83a
                        at src/libstd/sys/common/unwind/mod.rs:219
   6:     0x55b3ed3ee484 - syntex_syntax::parse::lexer::StringReader::next_token_inner::he61f3e2291c514c3
                        at /home/zazdxscf/build/1nonpkgs/rustfmt/<std macros>:3
   7:     0x55b3ed3e76ef - syntex_syntax::parse::lexer::StringReader::advance_token::h255aae7847b19b40
                        at /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/lexer/mod.rs:266
   8:     0x55b3ed31adf1 - syntex_syntax::parse::lexer::StringReader::new::hef772bb54d9273a0
                        at /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/lexer/mod.rs:165
   9:     0x55b3ed31a8a9 - syntex_syntax::parse::filemap_to_tts::h2ae43363a6ee1352
                        at /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/mod.rs:255
  10:     0x55b3ed319a87 - syntex_syntax::parse::filemap_to_parser::hd88d027ff0326706
                        at /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/mod.rs:213
  11:     0x55b3ed318445 - syntex_syntax::parse::new_parser_from_source_str::h82e7cca3e8c9d718
                        at /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/mod.rs:182
  12:     0x55b3ed3181f4 - syntex_syntax::parse::parse_crate_from_source_str::hc65dcebb0b4dcf4a
                        at /home/zazdxscf/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.30.0/src/parse/mod.rs:95
  13:     0x55b3ed093473 - rustfmt::format_string::h2082095943e74a1c
                        at src/lib.rs:381
  14:     0x55b3ed0b1b3b - rustfmt::run_from_stdin::h1e8135c29ff2a697
                        at src/lib.rs:445
  15:     0x55b3ed0512b6 - rustfmt::execute::h9c9253d20e08b170
                        at src/bin/rustfmt.rs:200
  16:     0x55b3ed0633cc - rustfmt::main::h72bee7f7a14fa8c0
                        at src/bin/rustfmt.rs:245
  17:     0x55b3ed5b14b4 - std::sys_common::unwind::try::try_fn::h48f26a76fbfde40e
  18:     0x55b3ed5ae51b - __rust_try
  19:     0x55b3ed5b0efb - std::rt::lang_start::h7bd5d5e5d238827f
  20:     0x55b3ed064b69 - main
  21:     0x7f83fcd9659f - __libc_start_main
  22:     0x55b3ed04b768 - _start
  23:                0x0 - <unknown>

rustfmt commit used: d9ccec6f82fb4d58e41b78de6be530de72e4db00
$ rustc -Vv
!! executing '/home/zazdxscf/build/1nonpkgs/rust/rust//x86_64-unknown-linux-gnu/stage2/bin//rustc' with args: '-Vv'
rustc 1.9.0-dev (f2285bdaf 2016-04-02)
binary: rustc
commit-hash: f2285bdaf57e9cb56120902ae4b3b0a26d761f31
commit-date: 2016-04-02
host: x86_64-unknown-linux-gnu
release: 1.9.0-dev

Related or same? #753

Seems like a specific instance of #753 indeed. Closing.
Note that https://github.com/rust-lang-nursery/rustfmt/blob/master/Design.md states that formatting non-compiling code is a very low priority issue for now.

authors: marcusklaas respeccing


text:
--no-default-features is not applied to dependencies

Imagine that I'm working on MyCrate, which depends on crate A, which has a default feature X.
If I compile MyCrate with --no-default-features, crate A is still built with feature X enabled.
This is annoying, but it's possible to work around by using a Cargo.toml like:
[dependencies.A]
version = "*"
default-features = false

However, this solution does not work when A depends on another crate B which has its own default features. In this case, it does not seem possible to disable B's default features. In other words, it seems impossible to disable the default features of an indirect dependency.
My particular motivating case is libc unnecessarily depends on libstd when used through cargo.

This is why Cargo allows you to reexport features from dependencies in the main crate itself. Dependencies are intended to be a private implementation detail instead of a public interface, and if you'd like the feature to be exported then you must explicitly opt-in to doing so.

@alexcrichton:
So is every crate supposed to include [features.*] default-features = false just so that an end user can choose to opt out of some nested feature? That seems rather obtuse.

Yeah, that's the intention. Making something a default feature means it will be turned on almost all the time, so it's not necessarily meant for all optional pieces of functionality.

authors: JustAPerson alexcrichton

repo: rust-lang/cargo


text:
cargo test wants to execute English language prose from bindgen as a doc test

Problem
Cargo test tries to execute English language prose in the comments of the rust file generated by bindgen as doc tests, just because the header documentation of the original code
had some indented passages.
It seems very inconvenient that code would not compile because of something going on in the comments.  Especially when what's in the comments is misintepreted by the toolchain.
Steps

I have src/lib.rs and bindgen/lib.rs. bindgen/lib.rs is generated by bindgen, lib.rs is the hand-written part.
src/lib.rs contains an `include!("../bindgen/lib.rs") to keep hand-written and generated parts separate.
Running cargo test tries to interpret comments in ../bindgen/lib.rs as rust tests.  They are just english prose that happens to be indented. Error is seen below.
It is possible to add #![doc(tests(ignore))], but it's a top level directive.  Which means if you do add it to both files, then the compiler will complain that src/lib.rs has this directive at a non-top-level
place.  If you add it just to one, the compiler will complain about the other file.

error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `are`
 --> src/../bindgen/lib.rs:4322:8
  |
3 | Fields are placed for optimal alignment on
  |        ^^^ expected one of 8 possible tokens here

error: aborting due to previous error

Couldn't compile the test.

Possible Solution(s)
There could be a flag to forbid doc test execution for files that I don't want treated this way.
Notes
Output of cargo version:
cargo 1.38.0-nightly (e853aa976 2019-08-09)

FWIW, there is a bindgen flag --no-doc-comments that may help...

This is an issue with bindgen creating comments with indentation which is treated as a code block.  Code blocks always default to rust in rustdoc.
Regardless, this isn't an issue for cargo.  Either bindgen could rewrite the comments (unlikely) or rustdoc could provide an escape hatch (see https://github.com/rust-lang/rust/issues/59867).  If you want to disable doc tests entirely for the crate, doctest=false can be set in Cargo.toml. There are also some workarounds noted in https://github.com/rust-lang/rust-bindgen/issues/1313.

authors: ehuss filmil


text:
cargo vendor do not verify ~/.cargo/config

Problem
I config ~/.cargo/config like this to speed up cargo build:
[source.crates-io]
registry = "https://github.com/rust-lang/crates.io-index"
replace-with = 'sjtu'
[source.sjtu]
registry = "https://mirrors.sjtug.sjtu.edu.cn/git/crates.io-index"
when I exec cargo build, it will be fater than the default "https://github.com/rust-lang/crates.io-index".
But when I want to use "cargo vendor" to vendor all dependencies locally, it do not use the specific registry.
when exec cargo build:
cargo build
Updating `https://mirrors.sjtug.sjtu.edu.cn/git/crates.io-index` index

cargo vendor
Updating crates.io index

"cargo vendor" do not verify the config ? what can I do to speed up cargo vendor ?
Notes
Output of cargo version:
cargo -V
cargo 1.44.0-nightly (6e07d2dfb 2020-03-31)
rustc --version
rustc 1.44.0-nightly (6dee5f112 2020-04-06)

I find the descriptions in vendor.rs:
// We're doing the vendoring operation ourselves, so we don't actually want
// to respect any of the source configuration in Cargo itself. That's
// intended for other consumers of Cargo, but we want to go straight to the
// source, e.g. crates.io, to fetch crates.
and I use "cargo vendor --respect-source-config", it works.


text:
Remove needless borrow

Make clippy happy.

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

@bors: r+

:pushpin: Commit d492a446c519ea0083692d780be4a3e61c9f33e2 has been approved by alexcrichton

:hourglass: Testing commit d492a446c519ea0083692d780be4a3e61c9f33e2 with merge 07e9d46e3d1d33e3342aa578b12887b8991c798b...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 07e9d46e3d1d33e3342aa578b12887b8991c798b to master...

authors: alexcrichton bors hi-rustin rust-highfive


text:
doc(features2): polish docs a bit

What does this PR try to resolve?
Polish docs of the new feature resolver v2 a bit.
How should we test and review this PR?
cargo doc --document-private-items --no-deps --open

And read.
Additional information
I can't find any assumption to add at this moment. If ehuss can recall that would be awesome!

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

@bors r+

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

:hourglass: Testing commit 6b8903e439f76d8d607803bfe45f8e73a5020b02 with merge 37f39f699324b4c5cc5b3553a52c023099902f25...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing 37f39f699324b4c5cc5b3553a52c023099902f25 to master...

authors: bors epage rust-highfive weihanglo


text:
chore: detect the channel a PR wants to merge into

What does this PR try to resolve?
This detects which channel a pull request wants to merge into.
It is hard because bors runs in a different repo.
Bors knows nothing about branches or tag in this repo.
It only see one base commit and a merge commit AFAIK.
Basically the assumption and idea are

bors create a merge commit, so HEAD~ should find the base branch.
Cargo maintains rust-1.y.0 branch for each Rust minor version releases.
Therefore, we can use the symbolic name of origin/rust-1.x.0
to determine if it aims for stable, beta, or nightly channel.
After we know which channel it is targeted at,
we can skip jobs that are likely to be broken.

How should we test and review this PR?
I setup a rust-1.70.0 branch on ec8a8a0cabb0e0cadef58902470f6c7ee7868bdc on my repo.
The script does find beta branch correctly.
https://github.com/weihanglo/cargo/actions/runs/5081469788/jobs/9129891293#step:3:36

Additional information
Sorry for bringing more shell scripts 🤯.
If this looks good, I'll file a PR for master branch.

Thanks for the review! I rebased the pull request. Change diff can be seen from here.

Thanks!  I'm not sure if it matters much that we're merging this to rust-1.70.0, but I think it should be fine.  Do you also want to backport this to rust-1.71.0?
I kinda wish GitHub Actions would have a little more diagnostics or descriptions on the runs page to explain why a job was skipped, but hopefully it will be clear to people in the future.
@bors r+

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

:hourglass: Testing commit 11704cbf54beb2348529f91bd9199d9616246d4e with merge e032df1da5742a534366d8c6b8f686b0a1e14543...

Sure for 1.71.0.
Now it sounds like we need two more PRs — one for 1.71 beta and the other for master 😂

:broken_heart: Test failed - checks-actions

Oops, looks like skipped jobs cause a failure in the if condition.
See: https://github.com/orgs/community/discussions/45058 and https://github.com/actions/runner/issues/491.
Are there any workarounds listed there that might work?

Ok. build-std job was skipped so bors failed. Maybe we need a weak depedency syntax for needs, like
needs: ["build-std?", "test"]

Just kidding.

Something like this? I can send PRs to 1.71.0 and master and then close this if this patch seems good.
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 2f75f206b..5f955af89 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -227,11 +228,16 @@ jobs:
           "https://raw.githubusercontent.com/rust-lang/rust/$BRANCH/src/tools/linkchecker/linkcheck.sh"
         sh linkcheck.sh --all cargo

+  nightly-only-jobs:
+    needs: [build_std]
+    if: "(jobs.channel.outputs.CHANNEL != 'master' && contains(needs.*.result, 'skipped')) || success()"
+    runs-on: ubuntu-latest
+
   success:
     permissions:
       contents: none
     name: bors build finished
-    needs: [docs, rustfmt, test, resolver, build_std, test_gitoxide]
+    needs: [docs, rustfmt, test, resolver, nightly-only-jobs, test_gitoxide]
     runs-on: ubuntu-latest
     if: "success() && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo'"
     steps:
@@ -240,7 +246,7 @@ jobs:
     permissions:
       contents: none
     name: bors build finished
-    needs: [docs, rustfmt, test, resolver, build_std]
+    needs: [docs, rustfmt, test, resolver, nightly-only-jobs]
     runs-on: ubuntu-latest
     if: "!success() && github.event_name == 'push' && github.ref == 'refs/heads/auto-cargo'"
     steps:

Okay I've updated this to target on the current master. We can have a new round of review :)

@bors r+

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

:hourglass: Testing commit 40be7187a99834df2feadc4d978653280ed93665 with merge f7b95e31642e09c2b6eabb18ed75007dda6677a0...

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

authors: bors ehuss weihanglo


text:
Revert "chore(deps): update rust crate openssl to 0.10.60 [security]"

Reverts https://github.com/rust-lang/cargo/pull/13068
openssl@0.10.160 switches to OpenSSL v3,
which causes Cargo build failure on loongarch64.
See https://github.com/rust-lang/rust/pull/118541#issuecomment-1837197918

@bors r+

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

:hourglass: Testing commit df34bdd8d7b04aef165d6fda880bf9dfe96cb47f with merge 8854c4d90b4b6825c900180fcab36d5f2d2eba02...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 8854c4d90b4b6825c900180fcab36d5f2d2eba02 to master...


text:
Don't run doc tests if there's a filter

Closes #1491

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

@bors r+

:pushpin: Commit fc5abf1 has been approved by huonw

:hourglass: Testing commit fc5abf1 with merge 33b6aa7...

:sunny: Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-32, cargo-win-64

authors: alexcrichton bors huonw rust-highfive


text:
[src/doc/manifest] Add section on Migrating to gitignore-like pattern matching

Tracking issue: https://github.com/rust-lang/cargo/issues/4268

I have not seen any similar notices on http://doc.crates.io/ which made me wonder if this is the right place to notify the change, which will eventually update this part of the document.
What do you think, @alexcrichton, others?

Looks great!

@bors: r+

:pushpin: Commit 69c74aa has been approved by alexcrichton

:hourglass: Testing commit 69c74aaffad9920652f499b894645c814be835ef with merge 6708d70ba922b6adce8c94b57e69d46a4a6225b0...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 6708d70ba922b6adce8c94b57e69d46a4a6225b0 to master...

authors: alexcrichton behnam bors


text:
Add CONTRIBUTING.md

r? @alexcrichton

@bors: r+
👍

:pushpin: Commit d11a429 has been approved by alexcrichton

:hourglass: Testing commit d11a429ded93659933ab58d985eb0a9e1ce5e971 with merge 4a7cae5cb93eb9388f53e2dc37bf66935c61987f...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 4a7cae5cb93eb9388f53e2dc37bf66935c61987f to master...

authors: alexcrichton bors matklad


text:
Force linking with spectre-mitigated libraries if /Qspectre is passed.

This is a kind of alternative to #673. I write "kind of" because it's not in direct opposition, but rather just a more sensible and robust approach.
I mark it as draft, because it needs more work, and maybe even further amendments based on feedback.

a warning would be appropriate in case spectre-mitigated libraries are not installed;
the section above, one that attempts to add reference to ATL, seems to be broken for contemporary compilers;
examine %LIB% environment variable, combine it with the suggested list, and deduplicate the result;
should there be a "global" method that would trigger linking with spectre-mitigated libraries in case the user doesn't compile any C/C++?
...

should there be a "global" method that would trigger linking with spectre-mitigated libraries in case the user doesn't compile any C/C++?

Just in case, my personal opinion is "no." For the following reason. Rust-generated code has very weak dependency on the MSVC run-time. And as far as I can tell this small amount of dependencies doesn't actually require the said mitigations. In other words, it makes sense to link with spectre-mitigated libraries only if you actually compile some C/C++. This makes the /Qspectre option passed to the compiler an adequate and sufficient trigger.

I think we should aim to be consistent with the environment unless specified otherwise. This PR does not conflict with that but neither does it obsolete that method. With this PR alone we will sometimes follow the user intent (when /Qspectre is directly specified as an argument) and sometimes we will ignore it (when it's specified in the environment).
Btw, Rust practically always links to at least some C/C++ code. At a minimum, the vcruntime (including startup code and panics). Well, unless they're using no-std and providing their own entry point.

Rust practically always links to at least some C/C++ code. At a minimum, the vcruntime (including startup code and panics).

Yes, I acknowledge that with "Rust-generated code has very weak dependency on the MSVC run-time. And as far as I can tell this small amount of dependencies doesn't actually require [or even have] the said mitigations."

Well, unless they're using no-std and providing their own entry point.

I explored the extent of the said dependency in https://github.com/dot-asm/min-crt-poc.

Specifically I don't understand how you draw this conclusion:

And as far as I can tell this small amount of dependencies doesn't actually require [or even have] the said mitigations.

Exception handling is a fairly large surface area so, even if the startup code and mem* functions don't employ any mitigations, I would expect that SEH does,

Specifically I don't understand how you draw this conclusion:

And as far as I can tell this small amount of dependencies doesn't actually require [or even have] the said mitigations.

min-crt-poc demonstrates that pure Rust code can interact with Rust std in non-trivial manner (for example do things like spawning threads), and at the same time not have references to vcruntime. And the assertion is that none of the code implemented in dllmain.rs (that would otherwise come from vcruntime) require spectre mitigations. Nor does it seem to have ones in the vcruntime itself.

Exception handling is a fairly large surface area.

And how much of the said surface is used by pure Rust code? My assessment is effectively none. Well, not that I'm saying that it's the actual case, but I failed to spot a meaningful dependency... Can you think of an example? I mean of Rust code that would rely on exception handling...

Panics are implemented in terms of SEH. For msvc toolchains, rust/llvm hard codes a dependency on _CxxThrowException and __CxxFrameHandler3. See https://github.com/rust-lang/rust/blob/25b764849625cb090e8b81d12d2bb2295d073788/library/panic_unwind/src/seh.rs
Even if a project doesn't use panics and the mem* functions don't have spectre mitigations then there is still the case of linking to other pre-built C/C+ libs.

Just in case. Suggestion is not to use dllmain.rs from min-crt-poc in any real-life scenario. Its sole purpose is to explore the interface between pure Rust code and vcruntime.

Panics aren't necessarily terminal (e.g. catch_unwind) and they are in all "normal" (not no_std) Rust applications even if the code paths aren't often taken. But this feels like we're getting into the weeds.
I'm still unsure as to what your point is. Microsoft have spectre mitigated versions of its C/C++ libs. Users may want to link these libraries into their application. The linker (link.exe) has no way to indicated this other than to pass in the path to spectre mitigated libraries. You can either do this by going through the C/C++ compiler (which rustc doesn't) or by setting the library paths (which rustc does via cc-rs which in turn defers to the environment if set).

I'm still unsure as to what your point is. Microsoft have spectre mitigated versions of its C/C++ libs. Users may want to link these libraries into their application.

I [for one] [still] see no real benefit in linking pure Rust applications with the said libraries. Facilitating specifically this case would be kind of a punch in the air. It only makes sense if you actually compile some C/C++ that would introduce a meaningful dependency on vcruntime, meaningful in the context of spectre mitigations. 2. It's beneficial to allow a library crate provider to make the assessment whether or not C/C++ library code needs to be compiled with /Qspectre and consequently linked with spectre-mitigated run-time. #673 would require the library crate provider to involve the potential user of the library in this last part of the process and rely on the said user's discipline to take specific steps in the future determined by Rust release schedule. This suggestion on the other hand allows the library provider to take the said decision without involving the potential user and achieve the objective now, with current or even previous Rust versions, let alone future ones.

I think, fundamentally, we should be trusting the user to make that determination and not overriding or ignoring their preferences unless there is a fundamental conflict. It's not the job of cc-rs to tell users they're wrong.
In the absence of information it makes sense to choose sensible defaults, or if there is conflicting sources of information it can make sense to see one as being more authoritative. E.g. if the explicitly given target triple differs from the environment, then it makes sense to trust the library user knows what they want.
Again, I have no real problem with this PR. However, I don't think it's sufficient on its own. It's a compliment to other sources of information.

I think, fundamentally, we should be trusting the user to make that determination and not overriding or ignoring their preferences unless there is a fundamental conflict. It's not the job of cc-rs to tell users they're wrong.

Could you clarify? Is it a suggestion that the addition of /Qspectre option is insufficient to make the determination? Or that module that is compiled with /Qspectre has no business [whatsoever?] affecting how the final application is linked? Or is it a response to "issue a warning in case spectre-mitigated libraries are not [even] installed" [which would be telling users they're wrong]?

authors: ChrisDenton dot-asm

repo: rust-lang/cc-rs


text:
Update README

Point users to the /about page
Recommend cargo run over docker-compose up
Document native dependencies
Suggest --registry-watcher disabled for the daemon

Closes https://github.com/rust-lang/docs.rs/issues/888

Marking as P-medium since the existing instructions to use docker-compose up lead to really frustrating experiences for new contributors (cc @GuillaumeGomez).

license: MIT


text:
UB in futures::join macro?

the futures::join macro seems to be checking if all of the futures returned Poll::Ready, and if not, calls poll on all of them again, regardless of if some of them previously had returned Poll::Ready.
this, if i understand correctly, violates the poll contract:

Once a future has finished, clients should not poll it again.

This wouldn't be undefined behavior, just unspecified.
Futures are wrapped in MaybeDone, which drops the inner future the first time it returns Ready retaining the value.

@ibraheemdev I was trying to learn the internals of async/.await and was a bit confused by this, so thank you for clearing it up!

closing issue...

repo: rust-lang/futures-rs


text:
Question about build.rs automatically building libgit2

libgit2-sys' build.rs file first searches for libgit2, then if it is not found, downloads and builds libgit2. This is good because it causes the least difficulty for first-time users, but it is fraught - there isn't any way to disable this automatic building feature or any notification that it is happening. This said, I have two questions

Why did you choose this approach - what problems exist when not automatically building libgit2?
Should other libraries take libgit2-sys' approach?

I'm aware that many well-maintained libraries like git2-rs take a similar approach to building native libraries, but I picked git2-rs because it seems pretty popular and is maintained by at least one core rust maintainer. If this is not the proper forum for this discussion, feel free to let me know what the proper forum is and close this issue.

Historically libgit2 was very unstable, and the bindings were very sensitive to the exact version being used.  Also, most systems will not have libgit2 installed.
That being said, some users use build script overrides to use a separately built version of libgit2.
The approach depends heavily on the library.  I think in most cases it is nice to have the build script automatically build the library, with the option to use a system-provided library. This is often expressed with a Cargo feature, or an environment variable (the environment variable can also be used to provide a location or other options).
I would suggest for questions about best practices to try one of the user forums (urlo, stackoverflow, etc.), as you might get a broader range of responses.

authors: ehuss maxbla


text:
CUDA syscalls

This introduces basic CUDA (nvptx64-nvidia-cuda target) syscalls.
I defined only c_char and size_t types since they were necessary for the syscalls.

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

The alternative would be to expose these in core::arch::nvptx, they do lower to intrinsics, so that might be a better fit. For the memory allocation routines, core::arch::wasm32 does expose memory allocation intrinsics, so there is some precedent of that in other architectures.
If we expose these in core::arch, instead of using C types, we would use Rust types on the API, except for the void* where we could directly use core::ffi::c_void since we don't have to support ancient Rust toolchains there. So maybe these would be a better fit for that.
But I'm not sure. 🤷♂

I must say, I like the idea of moving these syscalls to core::arch::nvptx! They are indeed quite low-level for normal usage by end-users.
Assume, missing malloc and nothrow attributes problem should be addressed anyway, could you please suggest how it can be achieved?

So for malloc we would just use the #[allocator] attribute, for the others that are nothrow I think there is a #[rustc_nothrow] attribute that we can use. In any case, core::arch seems like a better fit for these to me as well, so maybe we should close this and you can pretty much copy this PR 1:1 there (we don't have to get all attributes perfect for the initial commit there).

Closing in favor of stdsimd#699.

authors: denzp gnzlbg rust-highfive

repo: rust-lang/libc


text:
strftime* api for *BSD

close #3459

@bors r+

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

:hourglass: Testing commit aff5e66e547372dd29228043e450e9ebb5860257 with merge 07e39125b2b86ac4b2016624307bf2c1ece09e65...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing 07e39125b2b86ac4b2016624307bf2c1ece09e65 to main...

authors: JohnTitor bors devnexen


text:
Re-add posix_spawn{_file_actions_t,attr_t} on Android

Replace  #3609.
Close #3609.

@JohnTitor, could we please merge this and release libc without delay so that @madsmtm can re-queue the libc release for inclusion in rust? This is turning into an endless saga and a lot of people are obviously waiting.

authors: coolbluewater tesuji


text:
feat: some register set value for linux/musl

What does this PR do
Adds some register set values for Linux/musl
Linux header: https://github.com/torvalds/linux/blob/88264981f2082248e892a706b2c5004650faac54/include/uapi/linux/elf.h#L378-L382

We can port this patch to the libc-0.2 branch.

Thanks for the PR! Are these also available through glibc? If so they should probably just go to linux/mod.rs (if not then lgtm).

Are these also available through glibc?

Yeah, we already have them in gnu/mod.rs, considering that they are directly defined in the kernel, I guess they are available on all the libcs (Not quite sure, let's test this with our CI).

If so they should probably just go to linux/mod.rs

Let me give this a try:)

Let me give this a try:)

Done:)

Docs for reference https://man7.org/linux/man-pages/man5/elf.5.html


text:
Integers and pointers sometimes incorrectly preserve provenance on typed copies

Miri currently does not properly implement what happens to provenance during a typed copy:

When doing a copy at integer type, provenance should be stripped. Instead, we will currently complain during validation that provenance on an integer is UB.
When doing a copy at pointer type, if the provenance is not the same for all bytes of a pointer, it should be stripped. Instead, we will currently just preserve it (and if we later load this pointer as a scalar, we will raise an 'unsupported' error).

The best way I see to solve this is to make validation mutating, so that during validation we can adjust integer and pointer values following these rules. Mutating validation is also needed for https://github.com/rust-lang/miri/issues/845.

Seems like testcase #1 currently passes but I didn't dig too deep to see why/since when; maybe this issue is worth updating for anyone coming to work on it in the future?

Ah right that got fixed by https://github.com/rust-lang/rust/pull/104054.

repo: rust-lang/miri


text:
isolated operations return EPERM; tweak isolation hint

Follow-up to https://github.com/rust-lang/miri/pull/1797

@bors r+

:pushpin: Commit a38f02c44c56c2b6378e18ae238f4178db7eafd9 has been approved by RalfJung

:hourglass: Testing commit a38f02c44c56c2b6378e18ae238f4178db7eafd9 with merge 6c63506e97d6313e670e77318247bcd1f127c584...

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

authors: RalfJung bors


text:
add graceful shim for the custom O_TMPFILE file opening flag plus test case

I'm trying if I can get the tempfile crate to work nicely with miri. Right now miri errors out due to an unsupported flag O_TMPFILE (= 0x410000) passed to OpenOptions::custom_flags. Interestingly, tempfile has a fallback in case the underlying file system does not support the O_TMPFILE flag, in which case open/open64 is expected to return the error code EOPNOTSUPP (= 95). This PR adds support for this scenario and also includes a test case (relevant zulip discussion).

Thank you for the speedy review @RalfJung! I just pushed all the requested changes :)

LGTM if CI passes, but please squash the commits.

Thanks! The CI passed just now and the commits are squashed, too :+1:

@bors r+

:pushpin: Commit acb51b5a50c5e01d40a1971c44891b24d9401b0a has been approved by oli-obk
It is now in the queue for this repository.

:hourglass: Testing commit acb51b5a50c5e01d40a1971c44891b24d9401b0a with merge 2713dbd7b352d354e6e9bf244bfee33c57b4e78a...

:sunny: Test successful - checks-actions
Approved by: oli-obk
Pushing 2713dbd7b352d354e6e9bf244bfee33c57b4e78a to master...

authors: Pointerbender RalfJung bors oli-obk


text:
Link against minimal/unversioned msvcrt.dll for Windows binaries

Given rust's very minimal VC runtime usage on Windows, this is a proposal to have rust's default Windows toolchain link against the unversioned msvcrt.dll that has shipped with all versions of Windows rather than the toolchain-specific Visual C++ runtime (msvcrtXX.dll). This will eliminate completely any dependence on a specific toolchain/dll on end-user systems and allow Win32 binaries generated via rust to be deployed more portably and with greater ease across all Windows platforms.
Some background:
msvcrt.dll is not intended for use by user applications as it does not have a stable API and Microsoft makes no guarantee as to the availability or the behavior of any particular methods it exposes, as such, Microsoft does not ship a msvcrt.lib for dynamically linking against msvcrt.dll - instead, it advises that developers either statically link their binaries against msvcrtXX.lib tied to a specific release of the Visual C runtime (updated with each Visual Studio release) or link against that same dll dynamically and distribute a copy of said DLL with the resulting binary (as was the norm in the early 2000s) or distribute a copy of the VC runtime installer and execute that as needed during the deployment phase.
Since rust only uses very minimal functionality from the runtime library (allocation, basic string functions, etc) I believe we should be able to limit ourselves to the surface area of the msvcrt api that has been around since at least Windows XP and hasn't changed (for example, many of Microsoft's own single-binary tools target this version of msvcrt to provide universal binary functionality without the hassle of dependency management or a complicated setup routine).
I have open sourced a script to generate a msvcrt.lib file from the publicly exposed APIs found in any msvcrt.dll, this can be used to generate a (freely redistributable, but no need to redistribute it) the msvcrt.lib library stub that can be used by the MSVC compiler to become aware of the APIs exposed by msvcrt.dll and to link against them dynamically (without needing to LoadLibrary etc at runtime): msvcrt.lib (readme forthcoming)

FWIW, at NeoSmart Technologies we've been linking against msvcrt.dll for many years now with a variety of applications for the most basic CRT requirements (basically, standard C functions) and we haven't had any issues or complaints. Binaries produced many years back on Windows XP still run without problem on the latest Windows 10 builds, and applications built today on Windows 10 run on Windows XP just fine.

If you want to do this you can use the -gnu target already. It doesn't make sense for the -msvc target to link to this DLL, as it's explicitly not part of the MSVC toolchain and not supported. Rust programs do not exist in isolation - they are often linked with C/C++ code, so either you'll end up with multiple C runtimes linked to your application, or the C/C++ code may be unexpectedly linked to this very old version of the runtime causing linker errors, or worse, instability.
Difficulties when deploying can be solved by either statically linking, or by using the universal CRT, a version-less CRT that is up-to-date, supported by the MSVC toolchain, and is a built-in windows component.

The universal crt is very nice, but unfortunately it is restricted to Windows 10 and up. Some older versions of Windows can run apps linking against the universal crt, but only after installing the redistributable, which defeats the purpose of using it.

If you're using msvcrt.dll that's just as relying on undefined behavior in e.g. C,
it works until it doesn't.
I think Microsoft is pretty clear on communicating that this is a terrible idea:

The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.

https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.120).aspx

Although MSVCRT.DLL has been an operating system DLL for a long time, and has been documented as off-limits to applications, there are still a lot of people who treat it as a C runtime delivery channel, and those programs create a lot of grief for the product team.

https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273

You're not saying anything I didn't already say in my first post. I listed all these caveats upfront, I am neither unaware about them nor attempting to hide them.
I wouldn't advise using mscvcrt.dll directly for most anyone. But if you are careful and you know what you are doing (and presumably people working on a cross-platform compiler would qualify as such), a judgement call can be made. This is a tool in an arsenal, and hopefully it won't be used by anyone to whom the expression "if all you have is a hammer, everything looks like a nail" would apply.
It all depends on how much rust depends on the CRT for. You do yourself and others a disfavor if scaremongering people into thinking the signatures for memcpy or strcmp and co. will ever change. Microsoft's policy is that they're free to break compatibility. But they're not going to do change the essential building blocks, even if thousands of other APIs are added or modified. Look at strcpy. Despite its many faults, Microsoft did not dare touch it, and even in the versioned CRT, strcpy_s was introduced instead.
Many of these functions are either formal or de facto standards, either universally or in the Windows world.
Again, it all depends on how much rust relies on the CRT for. If rust is using it for simd operations and advanced intrinsics, then I would be against linking against the unversioned msvcrt.dll. But the guidelines that apply to your common developer are less a "must" and more of a "recommendation" when you are working on low-level applications or writing your own runtime library.
Using the GNU target, the versioned MSVCRT, or the Universal CRT are complete non-starters in this discussion. What would have been a helpful alternative suggestion would have been to compile the rust runtime against the userspace DDK, directly using the NT kernel APIs exposed to userland that msvcrt.dll is written against in the first place. Which is also an option I'd be in favor of and happy to permanently abandon this suggestion if interest in doing that were expressed.

I just wanted to provide some references for a clarified position on msvcrt.dll.

Many of these functions are either formal or de facto standards, either universally or in the Windows world.

Some are pretty safe sure, but a single one that isn't, is enough that everything falls apart.
Software shouldn't rely on luck, versioning and guarantees are there for a reason, we aren't in the 70s anymore.

directly using the NT kernel APIs exposed to userland that msvcrt.dll is written against in the first place

Assuming you mean kernel32 and such (and not direct NT-syscalls), sure one could do that, but it's work not providing much added value for the common user and someone has to look into it and do it.
(from a compatibility point with other MSVC dll's and such it may cause more issues than it solves)
You can already link the CRT statically, if you really do not want to ship it after all, is there any usecase that this is not enough/suboptimal for?

cc @retep998 for expertise.

I am opposed to trying to link to msvcrt.dll with the -msvc toolchain.

It would create massive incompatibility issues whenever you try to statically link to any C or C++ code.
Not relying on redistributables is already achievable through statically linking the CRT.
Rust would have to ship it's own import library for linking to msvcrt.dll.
Microsoft themselves tells you not to do this.

There are no upsides to this change, and the downsides would make life hell for programmers not understanding why their program is getting linker errors or crashing at runtime due to CRT incompatibilities.
Also, Rust does not currently prevent you from choosing to use your custom msvcrt.lib so you already can do what you want to do without having to mess with the default experience for most Rust users on Windows.

Alright, given @retep998's review I'll elect to close this issue at this time; if you think more discussion is necessary, feel free to reraise the issue on http://internals.rust-lang.org/.

https://github.com/Chuyu-Team/VC-LTL/releases
VC-LTL is an open source CRT library based on the MS VCRT.
You can use rust + VC-LTL, shared to msvcrt.dll and optimize the C/C++ application file size.

That repo has quite a lot of files starting with

//      Copyright (c) Microsoft Corporation. All rights reserved.

...

VC-LTL is compatible with rust

authors: Centril Diggsey comex mingkuang-Chuyu mqudsi retep998 steffengy xspeed1989

repo: rust-lang/rfcs


text:
Fix nightly packaging

The nightly-dist-packaging builders have all been failing to package for the past few nights with the error:
Traceback (most recent call last):
  File "package-rust.py", line 151, in <module>
    if "CFG_PRERELEASE_VERSION" in line and CFG_PRERELEASE_VERSION is None:
NameError: name 'CFG_PRERELEASE_VERSION' is not defined

Thus, a new nightly hasn't been published since 2015-01-08.  This pull request should fix packaging.

Ping @brson, just in case you didn't happen to see this.

repo: rust-lang/rust-packaging


text:
broken link

In the query.md file:
https://github.com/rust-lang/rustc-guide/blob/master/src/query.md
the first link (which should point to the high level overview of rustc page) is broken. Easy to fix but i don't know which link  exactly it is supposed so i will let someone do a PR to fix/fix it myself if someone tells me which link it's supposed to be.

Hi @shika-blyat :)
Thanks for the report. The link seems to work for me.
If you are viewing on github, the links might not work properly. I would recommend the hosted version here instead: https://rust-lang.github.io/rustc-guide/query.html

Well the problem was just coming from the link extension, so the PR above should fix it :)

Given what JohnTitor said, i'll close this issue

authors: mark-i-m shika-blyat

repo: rust-lang/rustc-guide


text:
normalize_comments = true de-normalizes some comments

According to https://rust-lang.github.io/rustfmt/?version=v1.4.36&search=#normalize_comments should convert /* yada */ to // yada, but the inverse happens.
# rustfmt +nightly --version
rustfmt 1.4.37-nightly (d2b04f0 2021-07-07)

normalize_comments = true
normalize_doc_attributes = true

results in a delta of
@@ -150,11 +151,11 @@ pub enum Stage {
        AvailabilityRecovery = 6,
        BitfieldDistribution = 7,
        ApprovalChecking = 8,
-       // Expand as needed, numbers should be ascending according to the stage
-       // through the inclusion pipeline, or according to the descriptions
-       // in [the path of a para chain block]
-       // (https://polkadot.network/the-path-of-a-parachain-block/)
-       // see [issue](https://github.com/paritytech/polkadot/issues/2389)
+       /* Expand as needed, numbers should be ascending according to the stage
+        * through the inclusion pipeline, or according to the descriptions
+        * in [the path of a para chain block]
+        * (https://polkadot.network/the-path-of-a-parachain-block/)
+        * see [issue](https://github.com/paritytech/polkadot/issues/2389) */
 }

 /// A wrapper type for a span.

Thanks for the report. This is technically a duplicate of a similar report added in a comment in #3350, but better to have a dedicated issue for it any way

I just hit this when commenting out a field in a struct definition, but I haven't even set normalize_comments = true.
rustfmt --version: 1.4.37-nightly (5ecc8ad 2021-09-19)

authors: calebcartwright drahnr jplatte

repo: rust-lang/rustfmt


text:
Avoid poor-formatting of the rhs of lazy_static macro

Parse the rhs as statement
Do not format unsafe block on the statement position in a single line

Close #3419.

@calebcartwright Thanks!


text:
Implement verbose option for "rustup toolchain list"

This PR resolves #1479.
local test
→ rustup toolchain list -v
stable-x86_64-apple-darwin (default)	/Users/bchen/.rustup
nightly-2019-09-05-x86_64-apple-darwin	/Users/bchen/.rustup
nightly-x86_64-apple-darwin	/Users/bchen/.rustup

→ rustup toolchain list --verbose
stable-x86_64-apple-darwin (default)	/Users/bchen/.rustup
nightly-2019-09-05-x86_64-apple-darwin	/Users/bchen/.rustup
nightly-x86_64-apple-darwin	/Users/bchen/.rustup

→ rustup toolchain list -h
rustup-toolchain-list
List installed toolchains

USAGE:
    rustup toolchain list [FLAGS]

FLAGS:
    -h, --help       Prints help information
    -v, --verbose    Enable verbose output with toolchain infomation

Thank you for the feedback, @kinnison. Just a quick note to acknowledge the feedback. Will definitely find time to edit to update the PR.

Greeting @kinnison. Per suggestions, I've pushed the updates in a squashed commit to:

used toolchain_list wrapper fn to avoid clap not leaked into common.rs
updated list_toolchains tests in cli-v1.rs & cli-v2.rs to assert the tab character in the toolchain path, to ensure verbosity option are being invoked.

PTAL? Thanks.

Noticed failed tests in CI log. Will check and update accordingly.

Thanks for catching the typo, @kinnison. Updated.


text:
Compatible with cargo --remap-path-prefix

As discussed in num-traits issue 139.

bors r+

authors: cuviper dingelish

repo: rust-num/num-complex


text:
add the option to disable singlethreaded-cbc

The dependency coin_cbc uses a default feature, singlethread-cbc, to introduce a global lock around the solve function of Cbc. They give the following reason:

This is because by default, libcbc is not thread safe. If you have compiled your own libcbc with the CBC_THREAD_SAFE option, you can disable this behavior by disabling the singlethread-cbc feature on this crate.

Unfortunately, if one includes your library and enables the coin_cbc feature, the dependency is added with all default features, and there is no way (to the best of my knowledge) to disable such a feature again.
This pull request also adds a default feature, singlethread-cbc, to this library which enables coin_cbc/singlethread-cbc if it is also included. This way, users of your library can opt out of singlethread-cbc if they can guarantee that they compiled the project with the appropriate falgs.

I cannot explain why the build fails. It cannot link to some Highs functions, which I have not touched. I reverted the commit and triggered the action again, and it still fails.


text:
builtin: pwd

Should support a variable PWD and a builtin for getting the present working directory

created the pwd builtin and the test for it

repo: rustic-shell/rsh


text:
Nail down wasm weekly release

I've noticed we have some conflicts sometimes (like two posts to /r/rust) as well as having our own subreddit when posting things. We should hammer out all the details on who is responsible for what, posting where etc.

@fitzgen think we can talk about this at either the next meeting or just a side meeting for those interested in this? Or just hash it out here?

We talked about this in the meeting and the consensus was that if you merge it you need to go to all the sites to let everyone know it was release.


text:
Expose helpers to allow synchronous initialization

This PR exposes helpers that will allow to synchronously initialize the WASM module. The helpers are only exported when compiling for web. But we could also export them for no-modules.
What I have done is to extract some of the functionality from init() into helper functions which are now exported.
This fixes #2698.
Todos

[ ] Add documentation
[ ] Do we only want to expose the helpers or maybe export a single function initSync()?

Background
At StackBlitz we are building WebContainer, a Node.js runtime for the browser, and we could benefit from this addition a lot because it would allow us to lazy load WASM modules on demand. Some features are split into separate WASM modules to improve load performance and those features are often not frequently used. By exposing these helpers we could synchronously instantiate modules in a worker like this then:
import { getImports, initMemory, finalizeInit } from 'my_wasm_module.js';

const imports = getImports();

initMemory(imports[, maybe_memory]);

const bytes = "<sync_fetch_bytes>";

const module = new WebAssembly.Module(bytes);
const instance = new WebAssembly.Instance(module, imports);

const wasm = finalizeInit(instance, module);

ℹ The above only really works in a Web Worker but that's ok IMO as the main thread disallows sync APIs for good reasons.
What do you think @alexcrichton? Is that what you were thinking of in #2698?

This seems reasonable enough to me, thanks for the PR! Can you add some documentation for this as well?

Yep, will add some documentation.

Honestly this is so far outside my expertise I don't really have an opinion. It's not "obviously wrong" but I know very little about all the myriad embeddings that JS can be run in, so I have no idea how to gauge which is better to provide. I'm basically leaving such a judgement call to you.

@alexcrichton This PR is ready for review.

Thanks!

@alexcrichton Nice! When do you think an we release this as a new version? So that the wasm-bindgen book is also updated with the example etc.

I'll look into doing a release next week

Ok I'm doing a publish at https://github.com/rustwasm/wasm-bindgen/pull/2935

Thanks a lot!

repo: rustwasm/wasm-bindgen


text:
Update WebGPU's webidl

Regenerated the webidl from the current state of the spec.

I would be great to publish a new version soon (for wgpu). What is the policy for new versions with changes to unstable specs?

I would be great to publish a new version soon (for wgpu). What is the policy for new versions with changes to unstable specs?

I don't think there's any policy as such. cc @alexcrichton

Nah no policy, just when someone asks

@alexcrichton in that case, can I haz a new version pretty please 🙏 thanks!

If one of y'all would be willing to make a PR for this release that'd be much appreciated which mostly boils down to running ./publish bump and I can tag/publish the PR when it merge.

authors: Liamolucko alexcrichton nical


text:
Remove unnecessary use_extern_macros feature

As @fitzgen pointed out in #17, nightly no longer requires the use_extern_macros feature :tada:

Can we also ditch the extern crate usage here too?

Can we also ditch the extern crate usage here too?

Not until Rust 2018 is shipping, I don't think.

authors: fitzgen scrogson

repo: rustwasm/wasm-pack-template


text:
release a new version

https://github.com/rustwasm/wasm-pack/pull/839
This fix has been merged for a while, but it's also a year without new release.
Can we draft a new release to fix related issues.
@ashleygwilliams

#839
This fix has been merged for a while, but it's also a year without new release.
Can we draft a new release to fix related issues.
@ashleygwilliams

cargo install --git https://github.com/rustwasm/wasm-pack wasm-pack

A big +1 to a new release. The bundler target issue bit me as well. Given how trivial it is issue a new release, the lack of one indicates to me that wasm-pack is essentially abandonware.

@danwilhelm Sorry for the direct at, but you are the only person listed under people that seems to be active. Any news on this repository?

@Zageron I have not kept up with the project's status. I would recommend reaching out to Rust's WASM working group, which has a very active channel #wg-wasm on Rust's official Discord server.

@Zageron I have not kept up with the project's status. I would recommend reaching out to Rust's WASM working group, which has a very active channel #wg-wasm on Rust's official Discord server.

Thank you very much. :)

FWIW, I did some poking around and it does seem a bit like this project is abandoned for now.

https://github.com/rustwasm/team/issues/294
https://github.com/rustwasm/wasm-bindgen/issues/2337#issuecomment-716075906

New release planned in #1020

authors: Zageron danwilhelm drager gengjiawen lucperkins turboladen

repo: rustwasm/wasm-pack


text:
update the edgeweight of undirected graph

Hello,
I have a gnn that will assign edge weight based on the topology of the subgraph. For each batch, I will update say 16 edge weights of one graph. Since the graph is undirected, it is expected that when edge weight (stored in the g.edge_weight as a tensor of size (n_edge)) corresponding to edge [1, 2] is updated, the weight of edge [2, 1] will be 'automatically' updated.
Do you know what's a good way to force the weight of two edges to be the same all the time? If this can not be done, I probably will have to find the location of edge [2, 1] when updating edge [1, 2] and it seems quite awkward.
Thank you very much!

One possible way to achieve this is to only save one direction in edge_index and use a custom GNN operator where you propagate twice (with different flows):
self.flow = 'source_to_target'
h= self.propagate(edge_index, x=x, edge_weight=edge_weight)
self.flow = 'target_to_source'
h= h + self.propagate(edge_index, x=x, edge_weight=edge_weight)

Thank you very much!


text:
Farthest Point Sampling

❓ Questions & Help

Hi, I am trying to use fps function to train my Point cloud network.
The problem is that my data for point cloud is fed into the network as (batch_size, channels, num_points) but when I use the fps function to sample my data, it works on the batch size, so the shape stays the same even after the sampling.
Is there anyway to use fps function to sample num_points?
Could reshaping the data shape to (num_points, channels, batch_size) and then change it back to the original shape after sampling to continue the training be valid approach?
Thank you!

I suggest to permute your input data to align with the representation fps expects:
pos = ... [batch_size, channels, num_points]
pos = pos.permute(0, 2, 1).view(batch_size * num_points, channels]
batch = torch.arange(batch_size).view(-1, 1).repeat(1, num_points).view(-1)
index = fps(pos, batch=batch, ratio=0.5)

I suggest to permute your input data to align with the representation fps expects:
pos = ... [batch_size, channels, num_points]
pos = pos.permute(0, 2, 1).view(batch_size * num_points, channels]
batch = torch.arange(batch_size).view(-1, 1).repeat(1, num_points).view(-1)
index = fps(pos, batch=batch, ratio=0.5)


text:
dgcnn_segmentation:AttributeError: 'Batch' object has no attribute 'category'

❓ Questions & Help

when i run dgcnn_segmentation with batch=4 (my GPU memory only 3G), it raise:
"     categories.append(data.category.to(torch.device('cpu')))
AttributeError: 'Batch' object has no attribute 'category"
why??

Yes, the ShapeNet dataset changed in master. You need to install PyG from source, and everything should work as expected. I will craft a new minor release soon.


text:
Stream loosing files

gulp-filter is using through2 and in certain conditions Some files are skipped during gulp.dest after restore.
From what I've tested (see my comment) I think that's related with an "highWaterMark" value that was introduced in version 0.5.0: https://github.com/rvagg/through2/commit/7ce8c780b1219c1ebea7717e9dc111bbe4dc2ffa
I've tested with through2 version 0.4.2 and there are no lost items (we switched to this version).
Also, tested with an highWaterMark value of 128 and it also worked.
Thanks!

This is most like a bug in your code with a stream not being drained. Setting hwm to a higher value just means that any flushing bug will take longer to appear.

I found the bug in gulp-filter and tried to add a (somewhat) detailed description of why you are seeing this issue in sindresorhus/gulp-filter#29. Since this isn't related to though I'm closing this. Feel free to reopen if I'm wrong :)

killer job!

@mafintosh thanks :)!

authors: juliangruber mafintosh nevcos


text:
Suggestion: quick ITOPOD selection

hello, I believe that ITOPOD should not be placed at the end of a long Zone selection list, but rather quick selection checkbox (or something similar) will be nice.

this is rather suggestion for lazy players, but maybe add ITOPOD from zone selection to TOP on list?

Added a checkbox in 3.0

authors: rvazarkar yoksi

repo: rvazarkar/NGUInjector


text:
BESTAUG - update cost formula and check if we can afford the upgrade …

…when doing pairs

canceling the PR, looks like its even more broken with this 'fix'

canceling the PR, looks like its even more broken with this 'fix'

Fixed math, now works accurately, should make more sense

Fixed math, now works accurately, should make more sense


text:
[BUG] bug of _search_split

in dataset_factory.py
_TRAIN_SYNONYM = {'train', 'training'}
_EVAL_SYNONYM = {'val', 'valid', 'validation', 'eval', 'evaluation'}
Type of _EVAL_SYNONYM is a dict, iterating a dict is not always in same order, when used in distributed system, _search_split will return different roots.

@lippman1125 you mean sets, dicts are ordered in any python version that we'd care about now, but sets like this are not. However, I really don't see the problem here, it's a convenience alias to find a suitable subdir to avoid extra typing or multiple args, the assumption is only one of those names would be used, if you have a dataset with say both 'val' and 'eval' in it that's a problem regardless of which order it searches...

@lippman1125 you mean sets, dicts are ordered in any python version that we'd care about now, but sets like this are not. However, I really don't see the problem here, it's a convenience alias to find a suitable subdir to avoid extra typing or multiple args, the assumption is only one of those names would be used, if you have a dataset with say both 'val' and 'eval' in it that's a problem regardless of which order it searches...

Its a corner case in my environment, details as follow:
My imagenet directory contains val and valid. val is for imagent evaluation, valid is not.  When I launch a distributed training, some processes get val, others get valid, it will cause incorrect evaluation results. But I think it's a bug, because evalution is not always incorrect, if all processes concidently get val.(repeated launch)  This phenomenon confused me a lot.  If using lists instead of sets, the program will behaves consistently.

repo: rwightman/pytorch-image-models


text:
[Snyk] Security upgrade python from 3.13.0a3-slim to 3.13-slim

Snyk has created this PR to fix 4 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

examples/v1beta1/trial-images/mxnet-mnist/Dockerfile

We recommend upgrading to python:3.13-slim, as this image has only 37 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Integer Overflow or Wraparound SNYK-DEBIAN12-EXPAT-7855502
  714

Integer Overflow or Wraparound SNYK-DEBIAN12-EXPAT-7855503
  714

XML External Entity (XXE) Injection SNYK-DEBIAN12-EXPAT-7855507
  614

Allocation of Resources Without Limits or Throttling SNYK-DEBIAN12-SYSTEMD-6277507
  614

Allocation of Resources Without Limits or Throttling SNYK-DEBIAN12-SYSTEMD-6277507
  614

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 XML External Entity (XXE) Injection
🦉 Allocation of Resources Without Limits or Throttling

Pull Request Test Coverage Report for Build 11471119340
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 72.974%

Totals

Change from base Build 8152929967:
0.1%

Covered Lines:
3116

Relevant Lines:
4270

💛  - Coveralls

authors: coveralls ryan-ally

repo: ryan-ally/katib


text:
Consider requestAnimationFrame doc explanation

In considering reflex DOM, I'd really like to know if you use requestAnimationFrame to batch your updates, or if you do them directly. I have an app which uses ClojureScript, Reagent and therefore ReactJS, and Reagent uses a requestAnimationFrame batching for efficiency reasons.
Have you done performance tests with thousands of components passing data on the same page? My app has this context.
It's my aim to migrate the app that runs our content management system to purely be written in Haskell, but I'd like to know whether it'll run performantly in Reflex-DOM before I consider it.
Also what's the debugging story like in Reflex-DOM? (Meaning, if something odd happens in the DOM, does it report error messages nicely so that one can track down which component has done something weird if that's the case? Or are these kinds of errors just not an issue?)

Hi @GetContented,

Reflex-DOM doesn't currently use requestAnimationFrame, but it is on the short list of features to add next.
I have written large apps with reflex.  The total number of components does not impact the performance of the FRP system - only the number of components actually changing in a given frame.  If you have a specific component you're thinking of, I'll be happy to look into it in more depth.
Debugging is much like debugging in Haskell in general.  It's possible to run Reflex-DOM apps in ghci, so you can follow a pretty standard workflow.  You can also use traceEvent/traceBehavior/traceDyn to show FRP signals as they are propagating, and you can use 'display', which is like 'print' except that it dumps a dynamic thing into the DOM.  In my experience, not a lot of debugging has been required for Reflex apps.  We don't have DOM-element-based exception handling; it's an interesting idea, but I haven't seen too many places where I needed it.

Hi Ryan. Thanks so much for your response. I guess I'll just have to give it a try :) (Which may take some time, given my app is written half in ClojureScript, half in Ruby! LOL)
My app sometimes loads sets of hundreds of items of data from the backend, then updates the view. All good, though.

authors: GetContented ryantrinkle

repo: ryantrinkle/try-reflex


text:
開くボタンを作成

概要
WebKitを使いAPIで取得したURLを開く

完了


text:
Distributed load orchestrator

The load patterns as in ramp-up phase, or throughout the load testing run needs to be synced by a central orchestration component, that is DLO, distributed load orchestrator.

Not in scope.

repo: ryos-io/Rhino


text:
IntelliJ IDEA does not generate equals () and hashCode () using Lombok.

https://youtrack.jetbrains.com/issue/IDEA-164829

I don't think that we can help here. Possibly you should file a bug report on the Lombok IntelliJ plug-in project.

the bug has already been fixed in the Jetbrains IDEA link above

authors: BorzdeG rspilker

repo: rzwitserloot/lombok


text:
Concatenation extension

This tus protocol extension is described here: https://tus.io/protocols/resumable-upload.html#concatenation

Added in #26.


text:
Dark mode automatically applies and looks ugly on oculus browser

I don't know if this is upstream, but dark mode turns on oculus browser, and it looks pretty ugly. Like some background colors just go black while text color doesn't change to white.

Considering github is also dark mode, it would seem dark mode on the whole isn't something you want to look at with daisyui. I have a striped table with disabled buttons, and you can't tell whats in those rows.

Quick fix for this would be just not having having dark mode.

I don't have access to an Oculus browser to test this but here's how it works:
By default, theme applies to <html> tag and there's a style that sets text color and background color to the root element. If it's light theme, text color will be dark. If it's dark theme, text color will be light.
So, there shouldn't be any issues. However, if you're seeing dark text on dark background, try adding text-base-content class to the root element or the section that has this issue. this will fix the text color.
Also, you can add your own custom theme with customized colors: https://daisyui.com/docs/add-themes
You can name it as dark to replace the default dark theme
Let me know if you have any questions.

I fixed it. it would seem default theme didnt apply, until specified.
data-theme="lagh" in html tag as attribute. Some elements are still dark
for some reason, but stuff looks much better now. I didn't use daisyui
through out, so stuff looks pretty bad when you apply a theme.

repo: saadeghi/daisyui


text:
SelectedVideoInputId is null

For some reason the SelectedVideoInputId is null.
private void DecodingChanged(DecodingChangedArgs args)
{
    var test = _barcodeReader.SelectedVideoInputId;
    // test is null and I don't know why :/
}

What's the status of IsDecoding when you encounter that issue? - SelectedVideoInputId is set prior changing IsDecoding to true. Yet it's not set at all if IsDecoding is going false.
What I could imagine is though, that I created a race due to async execution of the start command. Did you check the console output? Is it possible, that you receive the DecodingChanged-Event before you see Started continous decode from camera with id ... in the console?

I can't reproduce this issue, @Hackmodford  can you provide an example?

Long time no input, closing.

authors: Hackmodford sabitertan uniederer

repo: sabitertan/BlazorBarcodeScanner


text:
Object type/syntax for 'responsive' parameter

You haven't mentioned in options or examples about the input parameter for 'responsive' setting.

See the first example http://sachinchoolur.github.io/lightslider/examples.html
responsive : [
    {
        breakpoint: 800,
        settings: { // settings for width 480px to 800px
            item: 3,
            slideMove: 1,
            slideMargin: 6
          }
    },
    {
        breakpoint: 480,
        settings: {  // settings for width 0px to 480px
            item: 2,
            slideMove: 1
          }
    }
]

authors: sachinchoolur scazzy

repo: sachinchoolur/lightslider


text:
xCode 7 beta 5 warning for synthesis

In SKSplashIcon.m, animationDuration var is not synthesized. I keep getting this warning:
Auto property synthesis will not synthesize 'animationDuration'; it will be implemented by it's superclass, use @dynamic to acknowledge intention.
If you synthesize animationDuration, the warning goes away.

delete that line will also solve the issue

Fixed in c5e45c0

authors: PascoCoder mokshkhurana sachinkesiraju

repo: sachinkesiraju/SKSplashView


text:
🛑 PEAKE CW Control is down

In 921ec9f, PEAKE CW Control (https://help.peakesupport.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PEAKE CW Control is back up in 2bde9bf after 10 minutes.


text:
Refactored mafia and mafia_param

did some stuff to increase readability and code quality:

commented code.
reduced cognitive complexity of god_page function
refactored some of the code into functions
removed duplicate code
split mafia_param code into multiple files
game now uses json to store it's configuration and texts
added some whitespace
converted player class into a data class

Also added some functionality:

moved player related code from mafia into its own class
added team and role classes
(todo:
. use these to refer to roles instead of strings
. add all roles)

did some stuff to increase readability and code quality:

commented code.
reduced cognitive complexity of god_page function
refactored some of the code into functions
removed duplicate code
split mafia_param code into multiple files
game now uses json to store it's configuration and texts
added some whitespace
converted player class into a data class

Also added some functionality:

moved player related code from mafia into its own class
added team and role classes
(todo:
. use these to refer to roles instead of strings
. add all roles)

If you are not going to solve todo section in this PR, please issue it.

did some stuff to increase readability and code quality:

commented code.
reduced cognitive complexity of god_page function
refactored some of the code into functions
removed duplicate code
split mafia_param code into multiple files
game now uses json to store it's configuration and texts
added some whitespace
converted player class into a data class

Also added some functionality:

moved player related code from mafia into its own class
added team and role classes
(todo:
. use these to refer to roles instead of strings
. add all roles)

added enums for roles, replacing their string representation in the code.
added a few classes, trying to give the project a better design.
silenced code factor warnings.

needless to say this issue links directly to #6

authors: aeirya sadrasabouri

repo: sadrasabouri/mafia


text:
fix(relay-kit): User Operation gas estimation ignored

What it solves
We have a bug in the getEstimateFee calculation

Pull Request Test Coverage Report for Build 9031452881
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 78.565%

Totals

Change from base Build 9030216652:
-0.02%

Covered Lines:
710

Relevant Lines:
844

💛  - Coveralls

authors: coveralls yagopv

repo: safe-global/safe-core-sdk


text:
hi! please fix API method api/v1/owners/

gives either an empty number (although there must be an address) or 502

@rocketport the endpoint is working correctly, could you provide more information? at least the request that you are trying to do? ensure that you are in the correct chain.

repo: safe-global/safe-transaction-service


text:
tvOS compability

tvOS compability

@safx please check the PR. Thanks!

Current coverage is 99.00% (diff: 100%)

Merging #14 into master will not change coverage

@@             master        #14   diff @@
==========================================
  Files             2          2
  Lines           704        704
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            697        697
  Misses            7          7
  Partials          0          0

Powered by Codecov. Last update 5617c13...4e12cfd

Thanks! I'll release new version if test will be passed.

Need to fix Signing for iOS target. I chose Don't code sign otherwise in Travis it fails.

authors: codecov-io fassko safx

repo: safx/ObservableArray-RxSwift


text:
$auth.authenticate(provider).catch() not working

I am trying to implement Oauth2 login with github which works fine. However, whenever there is an error on my server, the catch() method doesnt get fired. I have even tried to throw an error manually on the server side,  which is reflected on the console, but only the then() method gets fired. Is there some additional configuration that I need to add or what?
On the server (using laravel):
//this method is part of my AuthController on the php server side
public function github(){
    //just for testing
    abort(500, 'Something went wrong');
}

On the client side controller
//this method is part of the controller on the js client, with all dependencies injected
github(){
    this.$auth.authenticate('github')
          .then((data) => {console.log('success response', data)})
          .catch((err) => {alert('something went wrong')});
}

Looking at the console, the request was sent to the url mapped to that AuthController method with the correct payload ie clientId, code and redirectUri, the server response is also logged in the console as 500. However, also logged in the console is success response undefined meaning the callback passed to then() was fired despite the server error, but not the one passed to catch(), confirmed by the fact that I did not see the alert. What could I be doing wrong? Please help...

Ignore this, I had an issue with my interceptor for error responses. Its amazing what a simple return can do.

I'm also using this to auth github, and I get a pop-up window, which brings me to a 404. Nothing else happens in the main window, no then or catch is invoked.

repo: sahat/satellizer


text:
🛑 Christen Gartenbau AG is down

In a1977d4, Christen Gartenbau AG (https://www.christen-gartenbau.ch) was down:

HTTP code: 403
Response time: 139 ms

Resolved: Christen Gartenbau AG is back up in c607a2b.


text:
sailpoint.beta.IdentityHistoryApi.get_historical_identity fails to deserialize results

Problem:
using a valid account id (see postman output below) the following API call fails.
identity_snapshot = sailpoint.beta.IdentityHistoryApi(beta_client).get_historical_identity(id=deleted_account.id)
results in:
Traceback (most recent call last):
File "", line 1, in
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/pydantic/validate_call_decorator.py", line 59, in wrapper_function
return validate_call_wrapper(*args, **kwargs)
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/pydantic/_internal/_validate_call.py", line 81, in call
res = self.pydantic_validator.validate_python(pydantic_core.ArgsKwargs(args, kwargs))
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/sailpoint/beta/api/identity_history_api.py", line 893, in get_historical_identity
return self.api_client.response_deserialize(
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/sailpoint/beta/api_client.py", line 316, in response_deserialize
return_data = self.deserialize(response_text, response_type)
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/sailpoint/beta/api_client.py", line 392, in deserialize
return self.__deserialize(data, response_type)
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/sailpoint/beta/api_client.py", line 431, in __deserialize
return self.__deserialize_model(data, klass)
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/sailpoint/beta/api_client.py", line 733, in __deserialize_model
return klass.from_dict(data)
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/sailpoint/beta/models/identity_history_response.py", line 89, in from_dict
_obj = cls.model_validate({
File "/Users/rob.buskens/Documents/Code/isc-hidden-identities/venv/lib/python3.9/site-packages/pydantic/main.py", line 551, in model_validate
return cls.pydantic_validator.validate_python(
pydantic_core._pydantic_core.ValidationError: 5 validation errors for IdentityHistoryResponse
accessItemCount.app
Input should be a valid string [type=string_type, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.7/v/string_type
accessItemCount.role
Input should be a valid string [type=string_type, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.7/v/string_type
accessItemCount.entitlement
Input should be a valid string [type=string_type, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.7/v/string_type
accessItemCount.accessProfile
Input should be a valid string [type=string_type, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.7/v/string_type
accessItemCount.account
Input should be a valid string [type=string_type, input_value=0, input_type=int]
For further information visit https://errors.pydantic.dev/2.7/v/string_type
in postman for that API and id:
{
"snapshot": "2024-04-16T17:10:15.485Z",
"id": "a772b05d2d1d400a873985f4261a9323",
"displayName": "10 Black",
"attributes": {},
"deletedDate": "2024-04-16T17:10:15.485Z",
"latestEventSnapshotDate": null,
"accessItemCount": {
"app": 0,
"role": 0,
"entitlement": 0,
"accessProfile": 0,
"account": 0
}
}
doesn't like the counts coming back as numbers? may be other issues as the response object is doing validation for strings.
class IdentityHistoryResponse(BaseModel):
"""
IdentityHistoryResponse
""" # noqa: E501
id: Optional[StrictStr] = Field(default=None, description="the identity ID")
display_name: Optional[StrictStr] = Field(default=None, description="the display name of the identity", alias="displayName")
snapshot: Optional[StrictStr] = Field(default=None, description="the date when the identity record was created")
deleted_date: Optional[StrictStr] = Field(default=None, description="the date when the identity was deleted", alias="deletedDate")
access_item_count: Optional[Dict[str, StrictStr]] = Field(default=None, description="A map containing the count of each access item", alias="accessItemCount")
attributes: Optional[Dict[str, StrictStr]] = Field(default=None, description="A map containing the identity attributes")
__properties: ClassVar[List[str]] = ["id", "displayName", "snapshot", "deletedDate", "accessItemCount", "attributes"]
using 1.0.4 of the python-sdk
running under Python 3.9.6 in a venv
used the sail cli to create the project.

code sample fails on deleted identities that have accounts.

access item counts, are numbers, not strings.
deleted identities don't have attributes

import sailpoint.v3
import sailpoint.beta
from sailpoint.configuration import Configuration
from sailpoint.paginator import Paginator
from sailpoint.v3.models.search import Search
from pprint import pprint

configuration = Configuration()

matches = 0
count = 0

with sailpoint.v3.ApiClient(configuration) as v3_client, \
     sailpoint.beta.ApiClient(configuration) as beta_client:

    deleted_accounts = Paginator.paginate(sailpoint.beta.IdentityHistoryApi(beta_client).list_historical_identities, result_limit=1000, is_deleted=True)

    for deleted_account in deleted_accounts:
        print(f'checking  account {deleted_account.display_name:<60}', end='\r')

        identity_snapshot = sailpoint.beta.IdentityHistoryApi(beta_client).get_historical_identity(id=deleted_account.id)

        if (identity_snapshot.access_item_count["account"] > 0):
            matches += 1
            print(identity_snapshot.id, identity_snapshot.display_name, "is deleted but has accounts")

        count += 1

print(f'{count} accounts were checked')

Changing two of the StrictStr to Any highlights what's off in the generated code as this allows the code to run:
class IdentityHistoryResponse(BaseModel):
IdentityHistoryResponse
access_item_count: Optional[Dict[str, ***Any***]] = Field(default=None, description="A map containing the count of each access item", alias="accessItemCount")
attributes: Optional[Dict[str, ***Any***]] = Field(default=None, description="A map containing the identity attributes")
__properties: ClassVar[List[str]] = ["id", "displayName", "snapshot", "deletedDate", "accessItemCount", "attributes"]

Seems something needs to be tweaked in the api spec, or the generator config.

Hey @rob-buskens-sp, I am using the same code as you and I don't see any errors. I believe there were some changes to the identity history specs because I do see that the access_item_count attributes were updated to be integers.
If you try this code again and still see errors, please re-open this issue!

authors: rob-buskens-sp tyler-mairose-sp

repo: sailpoint-oss/python-sdk


text:
Add new operation on sets

Is your feature request related to a problem? Please describe.
I want to add a new operation in sets. I have read this section in this website and there is only four operation as: Union, Intersection, Difference and complement. But there is also an another operation exist in sets which is "symmetric difference of sets", So I want to add this new one operation in this section.
Can you please assign me for this ? I can do it perfectly.
Thank you!

@sairish2001 Can you please assign me?

Are your talking about Calculator?

No sir


text:
Bar graph

Related Issuse

Bar Graph

fix #1096
Describe the changes you've made
Add functionality to create a bar graph by taking user input along the x and y-axis.
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.

Screenshots

Output

Hey, I am getting a lint code base issue. Can you please tell me why am I getting this?

Hey, I am getting a lint code base issue. Can you please tell me why am I getting this?


text:
pipeline: fix missing pipelines in listPipelines

/sajari.pipeline.v2.PipelineAdmin/ListPipelines can return an empty
object {} with no pipelines field.

Looks good to me! Might be worth checking with @benhinchley if the switch to npm from yarn was intentional? We seem to use yarn everywhere else 🤷🏼♂

authors: jonathaningram sampotts

repo: sajari/sajari-sdk-js


text:
SAK-44938 - Update subetha in mailarchive to newer fork

The version we're using is from
I tried to update to the latest 6.0.0 but it looks like they changed some dependencies on jakarta.mail and doesn't seem to be working with the version we have in master, so just went back a version. There was also an open PR for this so might not be completed.
Data got changed to support a string value of the return. It only suggests returning "OK message received" or null which will just return 250 OK. So there might be better returns we can use here but it seemed to be working okay.

@jonespm /kernel/kernel-impl/src/test/java/org/sakaiproject/email/impl/test/EmailServiceTest.java org.subethamail:subethamail?

Thanks @axxter99 I didn't see that this was also used in kernel.

repo: sakaiproject/sakai


text:
Unable to configure payment gateway

Summary
hello sir, I host and pass nginx proxy react-storefront:3000 and saleor-app-checkout:3001 on two different subdomain respectively. Both are working but in a saleor-dashboard i am unable to configure payment gateway. Getting an error
dashboard.5d80776fede891bce276.js?be297ff5ee0ee0bed80e:7728 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://saleor-app-checkout.lan') does not match the recipient window's origin ('https://saleor-dashboard.lan').
Versions:
dashboard v3.7.9
core v3.7.22

Steps to reproduce

Go to "dashboard v3.7.9"
Click On "Apps"
Click On "Third Party Apps"
Check On Installed payment "Checkout" app
Check the errors in a browser console as shown in figure above

A link to a reproduction repository
https://github.com/saleor/saleor-dashboard
Output from envinfo
System:

OS: Linux 5.15 Ubuntu 20.04.5 LTS (Focal Fossa)
CPU: (4) arm64 Neoverse-N1
Memory: 21.39 GB / 23.43 GB
Container: Yes
Shell: 5.0.17 - /bin/bash

Binaries:

Node: 16.18.0 - ~/.nvm/versions/node/v16.18.0/bin/node
npm: 8.19.2 - ~/.nvm/versions/node/v16.18.0/bin/npm
pnpm 7.13.4

Thank you for reporting the problem!
Does the error prevent you from configuring the app?

Yes Sir Its preventing to configring the app. Settings are not saved

These console errors are unrelated to the problem. Can you go to the Network tab in devtools and check which request is returning 500 error for you?

Thanks for reply sir
500 Error https://app-checkout.dingpack.com/api/payment-provider-settings/
Okay sir, Can u guide me on configuring part
My storefront is running at storefront.example.com from root of the project and app checkout saleor-app-checkout.lan running from /project-root/apps/saleor-app-checkout
On strapi dev console i configured webhook as saleor-app-checkout.lan/api/webhooks/stripe, i dont know where i am doing the mistake

might be nginx is blocking
My config file as
upstream app_checkout
{
server localhost:3001;
keepalive 64;
}
server
{
server_name app-checkout.dingpack.com;
error_log   /var/log/nginx/app-checkout-dingpack-com.error.log;
root /var/www/html/saleor/react-storefront/apps/saleor-app-checkout;
location /
    {
            include /etc/nginx/snippets/cors-wildcard.conf;
            proxy_pass http://app_checkout/;
            proxy_set_header    Host                $host;
            proxy_set_header    X-Real-IP           $remote_addr;
            proxy_set_header    X-Forwarded-Host    $host;
            proxy_set_header    X-Forwarded-Server  $host;
            proxy_set_header    X-Forwarded-Proto   $scheme;
            proxy_set_header    X-Forwarded-For     $remote_addr;
            proxy_redirect off;
            proxy_connect_timeout 90s;
            proxy_read_timeout 90s;
            proxy_send_timeout 90s;
    }

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/app-checkout.dingpack.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/app-checkout.dingpack.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server
{
if ($host = app-checkout.dingpack.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name app-checkout.dingpack.com;
listen 80;
return 404; # managed by Certbot

}

and same config file for storefront running at storefront.dingpack.com

no other end point is falling except https://app-checkout.dingpack.com/api/payment-provider-settings/

What's the response body?
Do you see any error logs where you're running app-checkout?

Yes Sir, There are some error logs
Error Log On Saleor Core (nginx or pm2)
tail -f ~/.pm2/logs/djnago-with-pm2-error-2.log
2022/10/21 16:46:53 [error] 2146#2146: *660 access forbidden by rule, client: 152.67.1.40, server: lcosapi.dingpack.com, request: "GET /.well-known/jwks.json HTTP/1.1", host: "lcosapi.dingpack.com"

Error Log On Saleor Storefront (nginx or pm2)
No error log found for
Error Log On Saleor App Checkout (nginx or pm2)
2022/10/21 16:43:32 [crit] 8008#8008: *63 SSL_do_handshake() failed (SSL: error:141CF06C:SSL routines:tls_parse_ctos_key_share:bad key share) while SSL handshaking, client: 80.82.77.33, server: 0.0.0.0:443

Error Log On Saleor Dashboard (nginx or pm2)
2022/10/21 16:46:50 [error] 8008#8008: *4 open() "/var/www/html/saleor/dashboard/dash-3-7-9/sw.js.map" failed (2: No such file or directory), client: 223.178.211.241, server: seller.dingpack.com, request: "GET /sw.js.map HTTP/2.0", host: "seller.dingpack.com"

Gm, Happy Diwali, Any rewiew or update on this sir?
On Fri, 21 Oct 2022, 16:08 Michał Miszczyszyn, @.***>
wrote:

What's the response body?
Do you see any error logs where you're running app-checkout?
—
Reply to this email directly, view it on GitHub
https://github.com/saleor/react-storefront/issues/566#issuecomment-1286775830,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD4NU72LGGP3EQYAIKFJUKTWEJXCJANCNFSM6AAAAAARKZGNPU
.
You are receiving this because you authored the thread.Message ID:
@.***>

As you can see in the first log, there's access forbidden by rule error for the GET /.well-known/jwks.json.
It's not something we can help you with as it's unrelated to the codebase in this repository – the underlying cause is likely a misconfiguration of your server.
We make available Docker images that you might find useful: https://github.com/saleor/saleor-platform

Hello sir, i still strugling to configure payment gateway through dashboard --> apps
ReactStorefront console output
saleor-app-checkout:start: JwksError: Forbidden
saleor-app-checkout:start:     at JwksClient.getKeys (/var/www/html/saleor/react-storefront/node_modules/.pnpm/jwks-rsa@2.1.5/node_modules/jwks-rsa/src/JwksClient.js:48:25)
saleor-app-checkout:start:     at runMicrotasks (<anonymous>)
saleor-app-checkout:start:     at processTicksAndRejections (node:internal/process/task_queues:96:5)
saleor-app-checkout:start:     at async JwksClient.getSigningKeys (/var/www/html/saleor/react-storefront/node_modules/.pnpm/jwks-rsa@2.1.5/node_modules/jwks-rsa/src/JwksClient.js:53:18)
saleor-app-checkout:start:     at async JwksClient.getSigningKey (/var/www/html/saleor/react-storefront/node_modules/.pnpm/jwks-rsa@2.1.5/node_modules/jwks-rsa/src/JwksClient.js:71:18)

Google Chrome console output

Please guide me sir

it's done sir by configuring redis and celery

authors: ashishkpaul mmiszy

repo: saleor/react-storefront


text:
Bug: An impure function tries to update given arguments

What are you trying to achieve?
To mr @patrys !
Please take a look at this function https://github.com/saleor/saleor/blob/45cfb26218c8b0e59be8409bdbfd14ec7189f4d0/saleor/order/utils.py#L425
You can observe it updates given total_price_left and balance_data parameters given.
This function is called exactly ONCE, (same file).
https://github.com/saleor/saleor/blob/45cfb26218c8b0e59be8409bdbfd14ec7189f4d0/saleor/order/utils.py#L391
I think the person who made this call was about to update the parameters directly without returning new values.
Thankfully, this works.
However, in my opinion, this code is a little **dangerous**,
some people may don't know that it's updating value under the hood.
Steps to reproduce the problem
You can look at the code and understand what I mean to say.
What did you expect to happen?
We can make the update_gift_card_balance function to return values instead, that makes the code meaningful, pure
Logs
No response
Environment
Saleor version: … master branch
OS and version: … linux

The parameters the function is given are immutable, so it's not actually modifying them, but the logic is weird. It may be hiding a different bug so we'll take a closer look.

repo: saleor/saleor


text:
Bug: Cannot delete demo account in Dashboard

What are you trying to achieve?
I'm trying to delete a superuser account with email "anna.jenkins@example.com. Nor can I disable this account.
Steps to reproduce the problem
Go to Staff Members and delete unnecessary accounts.

What did you expect to happen?
As other demo accounts, I can delete this account.
Logs
No response
Environment
dashboard v3.20.20
core v3.20.56
OS and version: debian 12

Thank you for the report @charleslcso, I have created a bug report for our team.
Internal link to track: MERX-1323: Apps Marketplace not loading in Dashboard 3.20.20

Hey, you essentially cannot delete the user that is a "superuser" - when you bootstrap the Saleor with an empty DB there is no possibility to create accounts except you superuser account thus, it's being populated.
We are going to change it a bit in the future and probably stop creating these accounts without demand.

Thank you for your info.
Now I have created extra users, and I’m not sure if they are superusers or just some other users. How can I check this?
Also I’m leaving my Saleor instance open to the net. Even though I can’t remove it, is there a way to:

disable it
Change password

Leaving it there exposed should create security risks.

authors: andrzejewsky aniav charleslcso


text:
fix thumbnail generation long image names.

I want to merge this change because...

Fix issue: https://github.com/saleor/saleor/issues/12314
Added function for cutting long file names to max length.
Thumbnails files with name length <= 55 works as expected
Impact

[ ] New migrations
[x] New/Updated API fields or mutations
[ ] Deprecated API fields or mutations
[ ] Removed API types, fields, or mutations
[ ] Documentation needs to be updated

Pull Request Checklist

[x] Privileged queries and mutations are guarded by proper permission checks
[x] Database queries are optimized and the number of queries is constant
[x] Database migration files are up to date
[x] The changes are tested
[x] GraphQL schema and type definitions are up to date
[x] Changes are mentioned in the changelog

I have 3 files:
File 1, 60 characters: 55_characters_FILE_NAME_MAX_LENGTH_random_rame_0123456789abc.jpg
File 2, 55 characters: 55_characters_FILE_NAME_MAX_LENGTH_random_rame_01234567.jpg
File 3, 54 characters: 55_characters_FILE_NAME_MAX_LENGTH_random_rame_0123456.jpg
When I try to upload those files to the same products in order: File 3, File 2, File 1,
Then
File 3 and File 2 are uploaded
File 1 is loading
https://user-images.githubusercontent.com/30683248/229500601-84c0430d-b120-4fc4-b4fa-2c34b0942d49.mov

This issue with loading occurs also on my local env build from main

authors: KirillPlaksin szczecha