text:
Support for sqlite vtables as loadable extensions

Try to fix PR #532

api_routines_stub feature does not seem to be used anywhere !
Am I missing something ?

The api_routines_stub feature existed to indicate that the underlying libsqlite3 version was one that included the typedef stub in sqlite.h:
/*
** CAPI3REF: Loadable Extension Thunk
**
** A pointer to the opaque sqlite3_api_routines structure is passed as
** the third parameter to entry points of [loadable extensions].  This
** structure must be typedefed in order to work around compiler warnings
** on some platforms.
*/
typedef struct sqlite3_api_routines sqlite3_api_routines;

It was not referenced from rust code, only serving as a more semantically meaningful alias that required the earliest version of sqlite that we support that includes that stub in the header file (which is libsqlite3-sys/min_sqlite_version_3_20_0). sqlite 3.14.0 is actually the earliest version that has that code, but libsqlite3-sys does not have support for that version, so the api_routines_stub feature was aliased to the earliest version that do have support for, which is 3.20.0.

Would it possible to generate only one other bindgen file instead of two ?
Because the difference between the two is only:
--- sqlite3/bindgen_bundled_version-ext.rs	2020-02-15 11:50:57.736323438 +0000
+++ sqlite3/bindgen_bundled_version-ext-embed.rs	2020-02-15 11:51:14.337342051 +0000
@@ -7895,11 +7895,13 @@
     );
 }

-// bindings were built with (non-embedded) loadable_extension:
-// we define our own sqlite_api static variable and export it
-// to C
-#[no_mangle]
-pub static mut sqlite3_api: *mut sqlite3_api_routines = 0 as *mut sqlite3_api_routines;
+// bindings were built with loadable_extension_embedded:
+// define sqlite3_api as an extern since this code will be embedded
+// within a loadable extension that defines and exports this itself
+extern "C" {
+    #[no_mangle]
+    pub static mut sqlite3_api: *mut sqlite3_api_routines;
+}

 // sqlite3 API wrappers to support loadable extensions (Note: these were generated from build.rs - not by rust-bindgen)

I don't know why we cannot use loadable_extension with the bundled version ?
            if cfg!(feature = "loadable_extension") {
                panic!("Building a loadable extension bundled is not supported");
            }

Any idea of a minimal test ?

Would it possible to generate only one other bindgen file instead of two ?
Because the difference between the two is only:
--- sqlite3/bindgen_bundled_version-ext.rs	2020-02-15 11:50:57.736323438 +0000
+++ sqlite3/bindgen_bundled_version-ext-embed.rs	2020-02-15 11:51:14.337342051 +0000
@@ -7895,11 +7895,13 @@
     );
 }

-// bindings were built with (non-embedded) loadable_extension:
-// we define our own sqlite_api static variable and export it
-// to C
-#[no_mangle]
-pub static mut sqlite3_api: *mut sqlite3_api_routines = 0 as *mut sqlite3_api_routines;
+// bindings were built with loadable_extension_embedded:
+// define sqlite3_api as an extern since this code will be embedded
+// within a loadable extension that defines and exports this itself
+extern "C" {
+    #[no_mangle]
+    pub static mut sqlite3_api: *mut sqlite3_api_routines;
+}

 // sqlite3 API wrappers to support loadable extensions (Note: these were generated from build.rs - not by rust-bindgen)

I guess we could remove this block entirely and hard-code the code in libsqlite3-sys/src/lib.rs instead (with the two versions controlled by #cfg directives)? I am not certain why I did not do that in the first place, but at the moment I see no reason why that shouldn't work.

Any idea of a minimal test ?

The best test would be to have an example vtable implementation that is loaded as an extension and then tested via queries. We are actively using (the old version of this code) with dozens of vtables, so I ought to be able to put together an example. Demonstrating the embedded version is a little more work (in our system we have a core extension that is based in C which registers with the sqlite core and then loads the rust vtable extensions (and non-rust vtable extensions).
I think it ought to be possible to have an example in which there is a non-embedded rust-based vtable that loads another (embedded) rust vtable within it, which should demonstrate all of the functionality.

I don't know why we cannot use loadable_extension with the bundled version ?
            if cfg!(feature = "loadable_extension") {
                panic!("Building a loadable extension bundled is not supported");
            }

This is probably a mistake, apologies - I suspect this dates from before I added the -ext-embed.rs versions of bundled libsqlite-sys.

On what basis have you removed our copyright statement?

Ah, I see - the Genomics plc copyright statement has been moved to the top-level LICENSE file (I missed that as the removal was in a separate commit). That is acceptable for us, although it does confuse the matter of which portions of rusqlite include code under our copyright (we didn't want it to seem that we were claiming copyright over the whole thing).
No problem here if you are happy to include it in the top-level LICENSE.

Would it possible to generate only one other bindgen file instead of two ?
Because the difference between the two is only:
--- sqlite3/bindgen_bundled_version-ext.rs	2020-02-15 11:50:57.736323438 +0000
+++ sqlite3/bindgen_bundled_version-ext-embed.rs	2020-02-15 11:51:14.337342051 +0000
@@ -7895,11 +7895,13 @@
     );
 }

-// bindings were built with (non-embedded) loadable_extension:
-// we define our own sqlite_api static variable and export it
-// to C
-#[no_mangle]
-pub static mut sqlite3_api: *mut sqlite3_api_routines = 0 as *mut sqlite3_api_routines;
+// bindings were built with loadable_extension_embedded:
+// define sqlite3_api as an extern since this code will be embedded
+// within a loadable extension that defines and exports this itself
+extern "C" {
+    #[no_mangle]
+    pub static mut sqlite3_api: *mut sqlite3_api_routines;
+}

 // sqlite3 API wrappers to support loadable extensions (Note: these were generated from build.rs - not by rust-bindgen)

I guess we could remove this block entirely and hard-code the code in libsqlite3-sys/src/lib.rs instead (with the two versions controlled by #cfg directives)? I am not certain why I did not do that in the first place, but at the moment I see no reason why that shouldn't work.

I've now implemented the alternative, eliminating the need to generated the separate -ext-embed.rs bindings. See https://github.com/gwenn/rusqlite/pull/2

This PR works beautifully for me. I'm using it to create this extension: https://github.com/phiresky/sqlite-zstd
One question I couldn't figure out by reading https://github.com/jgallagher/rusqlite/issues/524#issuecomment-507787350:
How is the best way to test an extension created this way? Basically I usually want to build my extension as a .so/.dll, but for tests I probably want to directly load it.
I tried disabling the loadable_extension feature for tests and just calling my init function myself by doing this:
[dependencies.rusqlite]
git = "https://github.com/Genomicsplc/rusqlite", branch="pr/loadable-extensions"
features=["functions", "blob", "loadable_extension"]

[dev-dependencies.rusqlite]
git = "https://github.com/Genomicsplc/rusqlite", branch="pr/loadable-extensions"
features=["functions", "blob"]

But cargo test just crashes with thread 'zstd_fns::tests::sanity' panicked at 'sqlite3_api is null', cargo-target/sqlite-zstd/debug/build/libsqlite3-sys-13edb0ce376f5abc/out/bindgen.rs:6864:9, and I can't figure out why.

I don't know how to test the dummy-extension module ?
Generate another module with load_extension and use a relative path while calling sqlite3_load_extension ?

I tried to manually check the generated extension but failed:
rusqlite % /usr/local/opt/sqlite/bin/sqlite3
SQLite version 3.31.1 2020-01-27 19:55:54
sqlite> .load target/debug/libdummy_extension.dylib
sqlite> SELECT * FROM dummy();
zsh: segmentation fault  /usr/local/opt/sqlite/bin/sqlite3

A simple scalar function works:
sqlite> .load target/debug/libdummy_extension.dylib
sqlite> SELECT half(6);
3.0

There is test-cdylib but we need incompatible features to test the generated extension !
[dependencies.rusqlite]
path = ".."
default-features = false
features = ["loadable_extension", "functions", "vtab"]
version = "0.21.0"

[dev-dependencies]
test-cdylib = "1"

[dev-dependencies.rusqlite]
path = ".."
default-features = false
features = ["bundled", "load_extension"]
version = "0.21.0"

?

Extension API function wrappers will be generated for all API functions in the sqlite bindings present at build time. It seems there is a trend towards encouraging building rusqlite against a very recent version of sqlite when any non-ancient features are requested (gating them all with the modern_sqlite feature - see #639 ). If this is the case, vtable authors will have little choice but to disable the version check in order to make it possible for end users to use their extension in a variety of environments. This presents a serious safety risk as an attempt to call an API function froma  newer version (i.e. from the wrapper at https://github.com/rusqlite/rusqlite/blob/cf658af142399be749bacb0387d54ce836b85f1a/libsqlite3-sys/build.rs#L638) would result in reading past the end of that struct into memory we don't own, and then executing what we find at the target of a pointer we find there.
If we are going to encourage people to disable the version check by making it difficult to build against a minimum required version of sqlite, then we should probably protect the wrappers by including a runtime version check in them (probably using Once) and refusing to attempt to execute any belonging to a version newer than the runtime environment supports.

Extension API function wrappers will be generated for all API functions in the sqlite bindings present at build time. It seems there is a trend towards encouraging building rusqlite against a very recent version of sqlite when any non-ancient features are requested (gating them all with the modern_sqlite feature - see #639 ). If this is the case, vtable authors will have little choice but to disable the version check in order to make it possible for end users to use their extension in a variety of environments. This presents a serious safety risk as an attempt to call an API function froma newer version (i.e. from the wrapper at
https://github.com/rusqlite/rusqlite/blob/cf658af142399be749bacb0387d54ce836b85f1a/libsqlite3-sys/build.rs#L638
) would result in reading past the end of that struct into memory we don't own, and then executing what we find at the target of a pointer we find there.
If we are going to encourage people to disable the version check by making it difficult to build against a minimum required version of sqlite, then we should probably protect the wrappers by including a runtime version check in them (probably using Once) and refusing to attempt to execute any belonging to a version newer than the runtime environment supports.

Version requirements for the API routines are documented in comments in sqlite3ext.h (e.g. https://github.com/rusqlite/rusqlite/blob/master/libsqlite3-sys/sqlite3/sqlite3ext.h#L287) but I am not sure what the best way would be to capture this and pass it through to the wrapper function generator so we can populate a required version test in each of them.

Sorry, last commits (on Jun 13) are wrong: at least changes on bindgen files...

I've updated this PR to work with the current version of rusqlite here: https://github.com/phiresky/rusqlite/tree/gwenntest
Seems to work, just needs recreation of the bindgen files for the non-bundled versions.

I've updated this PR to work with the current version of rusqlite here: https://github.com/phiresky/rusqlite/tree/gwenntest
Seems to work, just needs recreation of the bindgen files for the non-bundled versions.

Thanks. Maybe I should close this PR/branch ?

Uh probably not, I'm just a random person, I don't have access to this branch and not enough knowledge to actually champion these changes (e.g. I might have broken Windows builds with this change https://github.com/phiresky/rusqlite/commit/c409018608e22cf54975143a8d39f77577b78551#diff-c1c013e096409a5aea1f123c04254379057791785963eba5ef253fdd686570b8L526 )

I have opened a new PR here: #868

See a note in #910 regarding this PR not adhering to the conditions of the license under which code contributed in #532 was provided: https://github.com/rusqlite/rusqlite/pull/910#issuecomment-791485983
The issue here appears to have arisen out of a commit in which the "Genomics plc" copyright notice was removed and not (as far as I can tell) recreated elsewhere: https://github.com/rusqlite/rusqlite/pull/631/commits/68bea40e806df992d11ff8d12480738fc34bb611
I am sure this was not done maliciously, but these contributions are not owned by me and I only have permission from the owner (my employer) to contribute it under the terms of the license, including the specific copyright notice.

See a note in #910 regarding this PR not adhering to the conditions of the license under which code contributed in #532 was provided: #910 (comment)
The issue here appears to have arisen out of a commit in which the "Genomics plc" copyright notice was removed and not (as far as I can tell) recreated elsewhere: 68bea40
I am sure this was not done maliciously, but these contributions are not owned by me and I only have permission from the owner (my employer) to contribute it under the terms of the license, including the specific copyright notice.
Please stop distributing this code without including the required copyright notice. The easiest way to do that might be to revert (or rebase out of existence) the commit 68bea40

See https://github.com/rusqlite/rusqlite/blob/68bea40e806df992d11ff8d12480738fc34bb611/LICENSE

Copyright (c) 2019 Genomics plc info@genomicsplc.com

So [68bea40] explicitly removed Genomics plc from build.rs but kept it untouched in global LICENCE file (there is no file with copyright header in this repo)...
And https://github.com/rusqlite/rusqlite/pull/631#discussion_r404001452
Genomics plc was removed from global LICENSE file when master branch was merged.

See a note in #910 regarding this PR not adhering to the conditions of the license under which code contributed in #532 was provided: #910 (comment)
The issue here appears to have arisen out of a commit in which the "Genomics plc" copyright notice was removed and not (as far as I can tell) recreated elsewhere: 68bea40
I am sure this was not done maliciously, but these contributions are not owned by me and I only have permission from the owner (my employer) to contribute it under the terms of the license, including the specific copyright notice.
Please stop distributing this code without including the required copyright notice. The easiest way to do that might be to revert (or rebase out of existence) the commit 68bea40

See https://github.com/rusqlite/rusqlite/blob/68bea40e806df992d11ff8d12480738fc34bb611/LICENSE

Copyright (c) 2019 Genomics plc info@genomicsplc.com

So [68bea40] explicitly removed Genomics plc from build.rs but kept it untouched in global LICENCE file (there is no file with copyright header in this repo)...
And #631 (comment)
Genomics plc was removed from global LICENSE file when master branch was merged.

@gwenn apologies for missing the move of our notice from build.rs to LICENSE had already happened by the time of 68bea40e and we are happy with that move.
The problem actually occurred as you point out when master was merged: https://github.com/rusqlite/rusqlite/pull/631/commits/cb9e7025a45fe98698285336cd9be84d4ecbc4a5#diff-c693279643b8cd5d248172d9c22cb7cf4ed163a3c98c8a3f69c2717edd3eacb7

Discussion moved to https://github.com/rusqlite/rusqlite/pull/910/files#r765327393

Extension API function wrappers will be generated for all API functions in the sqlite bindings present at build time. It seems there is a trend towards encouraging building rusqlite against a very recent version of sqlite when any non-ancient features are requested (gating them all with the modern_sqlite feature - see #639 ). If this is the case, vtable authors will have little choice but to disable the version check in order to make it possible for end users to use their extension in a variety of environments. This presents a serious safety risk as an attempt to call an API function froma newer version (i.e. from the wrapper at
https://github.com/rusqlite/rusqlite/blob/cf658af142399be749bacb0387d54ce836b85f1a/libsqlite3-sys/build.rs#L638
) would result in reading past the end of that struct into memory we don't own, and then executing what we find at the target of a pointer we find there.
If we are going to encourage people to disable the version check by making it difficult to build against a minimum required version of sqlite, then we should probably protect the wrappers by including a runtime version check in them (probably using Once) and refusing to attempt to execute any belonging to a version newer than the runtime environment supports.

Discussion moved to: https://github.com/rusqlite/rusqlite/pull/910/files#r765327393

authors: gwenn jrandall phiresky

repo: rusqlite/rusqlite


text:
Ability to condition outputs on deploy settings

Allow outputs to be conditioned on

simtype
devicefamily
platform
deploytype
command

did some testing; appears to work

source: gharchive/issue

repo: russfrank/renderizer

license: MIT

license_type: permissive

license_source: github-api


text:
Consider adding pattern-matching for attribute filtering

Data attributes is a common pattern in modern web apps
<div data-foo="42" />
and sometimes it's ok to preserve them. Consider adding a pattern-matching based API to whitelist by a prefix.

Anyone on this? I can provide a patch for whitelist supporting. Wonder if it can get these changes feature gated and merged to the upstream.

more specifically, since prefix data- is widely adopted as "Data attributes", can we simply provide an API to allow the data- prefix?
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes

seems we can close this by #131 :-)

authors: dingelish shekyan

repo: rust-ammonia/ammonia


text:
Example fails

The example given at https://docs.rs/countme/3.0.1/countme fails at runtime, with both Rust 1.61.0 and 1.63-nightly. My guess is non-lexical lifetimes make the local variables disappear early?
(The following is from https://github.com/peter-kehl/countme_test, which has the aforementioned example pasted in.)
thread 'tests::countme_orig_example' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `2`', src/lib.rs:23:9

Works fine if you use the feature "enable". Don't know why that feature isn't on by default.

authors: crazymerlyn peter-lyons-kehl

repo: rust-analyzer/countme


text:
Multi-line doc in macro expands to multiple paragraphs, instead of concatenating the lines

I'm using stable versions:

rust-analyzer v0.2.408
Rust 1.48.0
VSCode 1.51.1
Windows 10 x64

This is the minimal reproducible code:
/// Long
/// line.
pub struct Normal {}

macro_rules! gen_struct {
    (
        $(#[$attr: meta])*
        $name:ident
    ) => {
        $(#[$attr])*
        pub struct $name {}
    }
}

gen_struct! {
    /// Long
    /// line.
    Generated
}

fn main() {
    let n = Normal{};
    let g = Generated{};
}

The Normal struct doc is displayed correctly:

But the Generated struct shows like this:

Actually I thought I was using the wrong syntax, and I asked this on StackOverflow. But, as the answer says, rust doc generates the correct output, so it seems to be an issue with rust-analyzer.

The problem here are doc attributes which the macro creates, for those we push a blank line in between their texts when collecting them instead of just a newline. Is that intended? https://github.com/rust-analyzer/rust-analyzer/blob/403ed489ff51e4b1d9b1bbde1ddb6f765ebcbd1f/crates/hir_def/src/docs.rs#L106-L121

authors: Veykril rodrigocfd

repo: rust-analyzer/rust-analyzer


text:
Fails to resolve methods on Option<impl Trait>

fn make() -> Option<impl Copy> {
    Some(())
}

fn main() {
    make().unwrap();
}

Here, the .unwrap() stays unresolved, and no completions after make(). are offered.

That's weird :thinking:

It works for me :thinking:

It doesn't work for me (current master, stable).

It indeed doesn't work with current master, so this seems to be a regression.

authors: flodiebold jonas-schievink lnicola


text:
Add no-std feature

Without the no-std feature, rust-bip39 wouldn't work in no-std scenarios
because of bitcoin_hashes
Putting in the Cargo.toml of your project:
bip39 = { version = "1.0", default-features = false }

and compiling would give:
❯ cargo build
    Updating crates.io index
   Compiling bitcoin_hashes v0.9.7
error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabihf` target may not support the standard library
  = note: `std` is required by `bitcoin_hashes` because it does not declare `#![no_std]`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `bitcoin_hashes` due to previous error

Strange, I use this script to test MSRV and feature support and it works for me:
#!/bin/sh

set -e

MSRV="1.29.0"

CMD="rustup run ${MSRV}"

rm -f Cargo.lock
$CMD cargo generate-lockfile

$CMD cargo test --no-default-features
$CMD cargo test --no-default-features --features all-languages
$CMD cargo test --features rand,all-languages

Shouldn't the --no-default-features do it?

Sorry if it wasn't clearly specified in the PR description, I am trying to build with target "thumbv7m-none-eabi", your script doesn't seem to try different targets?
With the Cargo.toml as:
[dependencies]
bip39 = { version = "1.0", default-features = false }

running cargo build --target "thumbv7m-none-eabi" gives a lot of errors because of bitcoin_hashes.
If, instead, I use:
[dependencies]
bip39 = { git = "https://github.com/danielabrozzoni/rust-bip39.git", branch = "no_std_support", default-features = false, features = ["no-std"] }

it compiles correctly :)
I'm definitely not an expert tho, so I might be missing something!
If you need a project to test this out: https://github.com/danielabrozzoni/test-bip39

I think the PR is correct but the description/discussion is a bit confusing. The problem is not with the feature combinations, your script correctly test those @stevenroose, the problem is we cannot build a no-std crate that depends on rust-bip39 with the current bitcoin_hashes dependency because bitcoin_hashes default features includes std features.
Cargo.toml that does not build, the commented out line is whats needed to build along with this PR.
[package]
name = "play"
version = "0.1.0"
edition = "2021"

[dependencies]
bip39 = { version = "1.0.1", default-features = false }
# bip39 = { path = "/home/tobin/build/github.com/tcharding/rust-bip39", default-features = false, features = ["no-std"] }
wee_alloc = "0.4.5"

[dev-dependencies]

[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"

And a main.rs
#![no_std]
#![no_main]
#![feature(default_alloc_error_handler)]

use core::panic::PanicInfo;

extern crate wee_alloc;

#[global_allocator]
static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;

#[panic_handler]
fn panic(_panic: &PanicInfo<'_>) -> ! {
    // Dummy usage of something from rust-bip39
    let _ = bip39::Language::English;

    loop {}
}

ACK 5855105c2a6bd1077fba130330b9c695dd55e1f5

Cheers mate.

Sorry for me being slow here (and in all my github stuff lately, unfortunately). I don't think we use the alloc feature of hashes, so I don't really see the need for the no-std feature enabling this. I tried to build without using no-std and it works. The only think that needs adding is to re-enable the default features in the dev-dependencies because the tests use them:
diff --git a/Cargo.toml b/Cargo.toml
index 6b7757d..28ff9fc 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -50,4 +50,5 @@ serde = { version = "1.0", default-features = false, optional = true }

 [dev-dependencies]
 rand = { version = "0.6.0", optional = false }
+bitcoin_hashes = "0.9.4" // enable default features for test

But yeah otherwise good catch that we were silently relying on std through _hashes.

Closing superseded by #25.

source: gharchive/pull-request

authors: danielabrozzoni stevenroose tcharding


text:
non_exhaustive on tuple struct with inner pub is not correct

We have
/// This type is consensus valid but an input including it would prevent the transaction from
/// being relayed on today's Bitcoin network.
#[derive(Debug, Clone, PartialEq, Eq)]
#[non_exhaustive]
pub struct NonStandardSighashTypeError(pub u32);

There are two problems with the code above:

non_exhaustive on tuple structs does not serve our forward comparability intentions because we cannot modify the error type to make it use named fields (assuming adding more details requires that).
The error type cannot be constructed by users of the library.

Possible solutions

Stop using tuple structs for errors, use named fields instead.
Remove the non_exhaustive
Remove the pub

I think it should be safe to remove #[non_exhaustive] in this specific case.

authors: Kixunil tcharding

repo: rust-bitcoin/rust-bitcoin


text:
aarch64-unknown-linux-musl: do not set RUSTFLAGS

https://github.com/rust-lang/rust/issues/46651 has been fixed, and this helps with https://github.com/rust-embedded/cross/issues/463

Hmm, seems like we need to wait for the next Rust release (or 2) until this can be removed

bors r+

bors retry

@reitermarkus this doesn't look spurious to me

You're right.

bors cancel

Cool, everything except asmjs-unknown-emscripten seems to be working with beta Rust. The remaining issue is caused by https://github.com/rust-lang/rust/issues/76679.

PR #497 is an alternative to this PR that should also work with old toolchains (1.42)

https://github.com/rust-embedded/cross/pull/497 has landed, so closing this!

authors: japaric jonas-schievink reitermarkus

repo: rust-embedded/cross


text:
don't set RUSTFLAGS in aarch64-musl image

instead use a linker wrapper to work around issue rust-lang/rust#46651
not setting RUSTFLAGS inside the container lets end users pass rustc flags via .cargo/config
this is an alternative to #464 that doesn't require bumping the MSRV of the aarch64-unknown-linux-musl target (that is the aarch64-musl image will continue to work with Rust 1.42 where bug rust-lang/rust#46651 is still presen )

Note that the reported CI failures are unrelated to this PR. CI is broken on the main branch; PR #498 fixes that.

bors r+

authors: japaric reitermarkus


text:
Add rutenspitz trophies

cc @jakubadamw

@Shnatsel, thank you, I'm honored! 🙂

authors: Shnatsel jakubadamw

repo: rust-fuzz/trophy-case


text:
Support Windows

original.

It does build on Microsoft Windows, here are some of the current examples.

Oh nice ! It's good to close then ! :-)

authors: GuillaumeGomez StephanvanSchaik

repo: rust-gnome/gtk

license: mit

license_source: bigquery


text:
Avoid extra comma in vertical single-field struct patterns

We previously double-added a trailing comma for single-member struct patterns that were arranged vertically. One was added by write_list (since such structs return true for needs_trailing_separator), and another is added by the if in rewrite_struct_path. This patch corrects this by checking for vertical layout before deciding whether to add a comma before ... This fixes #1397.

Thank you!

authors: jonhoo nrc

repo: rust-lang-nursery/rustfmt


text:
rustc-link-arg wrong order

Problem
I'm trying to link to a static library with an absolute path using build scripts and rustc-link-arg, but I found that its additional arguments are appended to the end instead of in the middle This is different from rustc-link-lib.
CARGO=/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=webp_encoder CARGO_MANIFEST_DIR=/home/circleci/project CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='libwebp bindings' CARGO_PKG_HOMEPAGE='https://crates.io/crates/webp_encoder' CARGO_PKG_LICENSE=MIT CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=webp_encoder CARGO_PKG_README=README CARGO_PKG_REPOSITORY='https://github.com/zzwxh/webp_encoder' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.6.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=6 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 LD_LIBRARY_PATH='/home/circleci/project/target/debug/deps:/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib:/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib' OUT_DIR=/home/circleci/project/target/debug/build/webp_encoder-0c3cef5dbd1f28c0/out /home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/bin/rustc --crate-name webp_encoder --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test -C metadata=c4c034865c8a8c44 -C extra-filename=-c4c034865c8a8c44 --out-dir /home/circleci/project/target/debug/deps -C incremental=/home/circleci/project/target/debug/incremental -L dependency=/home/circleci/project/target/debug/deps --extern anyhow=/home/circleci/project/target/debug/deps/libanyhow-a37ff87074167c9e.rlib -C link-arg=/home/circleci/project/lib/aarch64_linux/libwebp.a -C link-arg=/home/circleci/project/lib/aarch64_linux/libsharpyuv.a`
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin:/home/circleci/.cargo/bin:/home/circleci/bin:/home/circleci/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" VSLANG="1033" "cc" "/tmp/rustcn2eHDg/symbols.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.112o565stcsx42k3.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.1402l4488wnfwz7p.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.14a0vgkshv24t96a.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.1df8bj1iwhnbxiya.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.1gclg6ud69kz7r9l.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.1i9n3vfzrfafx7n7.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.1yyves5ncxaxpkyo.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.243dij62b8xkjpv6.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.2hjhdw30iaiygg26.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.2o4uz89asyvh1sbu.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.2q2ipx714ns09xri.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.2sfvofsvl3241egi.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.2xz866bts4ib9upk.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.35y0n1fz63q8tczx.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.39anztfvym4kgo8.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3be1czdt70qr2bsy.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3hlaw4a8jjs20bsq.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3i6txbjf01e5l7lu.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3iqtshl28lr0pohm.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3lm7chbphff68930.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3whybj2iuj7lg0rx.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.3xxx9iul6hggsq89.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.41dob2gpsfkfso90.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.48d1vk8lcw2ni6kw.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.4ay89d2m98eerpl2.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.4b9gaj2u8gfr8gue.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.4ciypgjjw3u9xai5.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.4n1c8i8xc94a3wbf.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.4rgbslz13lbhevqp.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.4szyq1b19rv9uu5y.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.50et8fa0pneyne3v.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.52l3awz6prln2x6z.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.5cd2297fll9y9h39.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.5f9vt4tgg2weyjnk.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.6e98exmdfdai8ru.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.6hrtabypo4xcq78.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.6tp528t6jvyek2w.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.7y3qw53hmvpdurc.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.evbnqyi6x2dryc0.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.icicj590tpqdkqs.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.ulvhf58hkcbjge.rcgu.o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44.1pwmjjgamne63hb8.rcgu.o" "-Wl,--as-needed" "-L" "/home/circleci/project/target/debug/deps" "-L" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libtest-4a0f7947e972e52d.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgetopts-fe53f665c7592316.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunicode_width-58c2b5e1ca5d5575.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_std-ec19369c5bbef562.rlib" "/home/circleci/project/target/debug/deps/libanyhow-a37ff87074167c9e.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-1af56df70101340f.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-2d201e9ec773e2b2.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-11edaa83ea3f42ca.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-be5d62f450379333.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-48892539e9a2c4de.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-f8eb1df1397eacbf.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-2e09868052a8b2d5.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-a7e259ed513c618c.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-791329d15b754d4d.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-00676b12b0ca4248.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-77a22a58722b5fb2.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-e9ab6f5f15790e88.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-fab82cfa2048cd45.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-21f6d61e1c83d48b.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-bac7f74953c2c715.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-9b674ebb751cb2fa.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-088fae249a1081ae.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-29f211c7751ad68b.rlib" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-26783adfa77949da.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/circleci/.rustup/toolchains/1.73.0-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "/home/circleci/project/target/debug/deps/webp_encoder-c4c034865c8a8c44" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "/home/circleci/project/lib/aarch64_linux/libwebp.a" "/home/circleci/project/lib/aarch64_linux/libsharpyuv.a"
  = note: /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libwebp.a(picture_csp_enc.o): in function `ImportYUVAFromRGBA':
          picture_csp_enc.c:(.text+0x1cdc): undefined reference to `pow'
          /usr/bin/ld: picture_csp_enc.c:(.text+0x1d34): undefined reference to `pow'
          /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libwebp.a(webp_enc.o): in function `WebPEncode':
          webp_enc.c:(.text+0x84c): undefined reference to `log10'
          /usr/bin/ld: webp_enc.c:(.text+0x884): undefined reference to `log10'
          /usr/bin/ld: webp_enc.c:(.text+0x8b4): undefined reference to `log10'
          /usr/bin/ld: webp_enc.c:(.text+0x8e8): undefined reference to `log10'
          /usr/bin/ld: webp_enc.c:(.text+0x918): undefined reference to `log10'
          /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libwebp.a(frame_enc.o):frame_enc.c:(.text+0x1714): more undefined references to `log10' follow
          /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libwebp.a(quant_enc.o): in function `VP8SetSegmentParams':
          quant_enc.c:(.text+0x2798): undefined reference to `pow'
          /usr/bin/ld: quant_enc.c:(.text+0x27d8): undefined reference to `pow'
          /usr/bin/ld: quant_enc.c:(.text+0x2818): undefined reference to `pow'
          /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libwebp.a(lossless_enc.o): in function `FastSLog2Slow_C':
          lossless_enc.c:(.text+0x13c8): undefined reference to `log'
          /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libwebp.a(lossless_enc.o): in function `FastLog2Slow_C':
          lossless_enc.c:(.text+0x1470): undefined reference to `log'
          /usr/bin/ld: /home/circleci/project/lib/aarch64_linux/libsharpyuv.a(sharpyuv_gamma.o): in function `SharpYuvInitGammaTables':
          sharpyuv_gamma.c:(.text+0x88): undefined reference to `pow'
          /usr/bin/ld: sharpyuv_gamma.c:(.text+0x11c): undefined reference to `pow'
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `webp_encoder` (lib test) due to previous error

In this example, the pow and log10 function exist in libm, but due to the issue, the linker is unable to resolve it.
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
No response

I can look into the log and guess how it failed. However, to avoid misunderstanding, could you provide a minimal reproducer if possible, or at least a part of your build script related to linker args?

commands:
clang -c test.c
ar crv libtest.a test.o
cargo run

test.c:
#include <math.h> // This links to libm

double test_pow(double x, double y) {
    return pow(x,y);
}

build script:
use std::{env, path::PathBuf};

fn main() {
    // Won't compile:
    let manifest = PathBuf::from(env::var("CARGO_MANIFEST_DIR").unwrap());
    println!("cargo:rustc-link-arg={}", manifest.join("libtest.a").display());

    // Will compile:
    // let manifest = PathBuf::from(env::var("CARGO_MANIFEST_DIR").unwrap());
    // println!("cargo:rustc-link-lib=static=test");
    // println!("cargo:rustc-link-search={}",manifest.display());
}

main.rs:
fn main() {
    unsafe {
        let result = test_pow(2.0, 2.0);
        println!("2^2={}", result);
    }
}

extern "C" {
    fn test_pow(x: f64, y: f64) -> f64;
}

link error:
LC_ALL="C" PATH="/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/root/.vscode-server/bin/f1b07bd25dfad64b0167beb15359ae573aecd2cc/bin/remote-cli:/root/.cargo/bin:/root/.local/bin:/root/bin:/usr/share/Modules/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin" VSLANG="1033" "cc" "-m64" "/tmp/rustcSHqNGI/symbols.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.1hvbnfr1jy5zofa1.rcgu.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.225pt77pqbp0tbas.rcgu.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.2uz0pdvo9swd7e21.rcgu.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.4dbmrkve9u9anz3c.rcgu.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.4kc5hef30jejk8x.rcgu.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.hc8vrf1cjlf0dt9.rcgu.o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea.25hh53sj8pek5rlo.rcgu.o" "-Wl,--as-needed" "-L" "/root/code/minimal/target/debug/deps" "-L" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6498d8891e016dca.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-3debdee1a9058d84.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-8339c5bd5cbc92bf.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-160ebcebb54c11ba.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-95c75789f1b65e37.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-7e8094f2d6258832.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-bac9783ef1b45db0.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-a1cd87df2f2d8e76.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-7fd06d468d7dba16.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-5ac19487656e05bf.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-c7c35d32cf825c11.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-c523f1571362e70b.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-85f17c92b770a911.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-598d3ba148dadcea.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-a58ec2dab545caa4.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f9dda8cca149f0fc.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-7ba4c315dd7a3503.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-5ac2993e19124966.rlib" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-df2fb7f50dec519a.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/root/code/minimal/target/debug/deps/minimal-d03d5d681f5a51ea" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "/root/code/minimal/libtest.a"

...
"-Wl,-Bdynamic"
 "-lgcc_s"
"-lutil"
 "-lrt"
"-lpthread"
"-lm" // <------------------ links to libm
 "-ldl"
 "-lc"
...
 "-Wl,--gc-sections"
"-pie"
"-Wl,-z,relro,-z,now"
"-nodefaultlibs"
"/root/code/minimal/libtest.a" // <------------------ libtest.a is at the very end

= note: /usr/bin/ld: /root/code/minimal/libtest.a(test.o): in function `test_pow':
          test.c:(.text+0x1d): undefined reference to `pow'
          collect2: error: ld returned 1 exit status

@weihanglo

Hi. Thanks for the example.
cargo:rustc-link-arg under the hood passed in -C link-arg= to rustc. there order link args is out of Cargo's control. From where I can tell, rustc appends -C link-arg options at the very end of the linker invocation. This is for overriding options passed in earlier. See https://github.com/rust-lang/rust/issues/99427. Note that this behavior is not guaranteed but IMO is unlikely changed.
I can see what you did with cargo:rustc-link-lib and cargo:rustc-link-search, which is pretty much the way people doing for linking your lib. You can also add a line cargo:rustc-link-arg=-lm" right after the previuos cargo:rustc-link-arg=<yourlib>. It may link to the right lib you want, though not ideal.
Close as Cargo has no control over how rustc manages the order of linker arguments for -C link-arg.

authors: weihanglo zzwxh

repo: rust-lang/cargo


text:
Cargo generates lockfile with duplicate package

When rebuilding this project which overrides rustc's libc_shim I get the error thread 'main' panicked at 'a package was referenced twice in the lockfile', src/cargo\core\resolver\encode.rs:51
The lockfile with multiple libc packages
This is on my cargo branch based on e95828103a1d8be1161adf394434b18e2e708954

Hi, I have the same problem. I'm having the following project structure:
Masterproject uses ProjectA and ProjectB. ProjectB and ProjectA both using ProjectC(same version for both). Now cargo generates a Cargo.lock file with ProjectC being present two times. All of these projects are included by being git submodules and the Cargo.toml uses the path to the submodule.
My cargo version: cargo 0.19.0 (28d1d60d4 2017-05-16)
Removing the duplicate entry by hand let's cargo compile the project, but the duplicate is added again..

Does anyone have a minimal reproduction case for this?
I tried loading up the avery one in case I could reproduce with HEAD but there are other setup steps that I didn't want to guess my way through as then I wouldn't be sure if  see no bug if cargo is fixed or if I did something wrong.
In avery's case, a replace is being used.  Unsure about the other case.  I'd be surprised if these are still busted 7 years later and wonder if we should close if we there aren't more details to go off of.

I would not be surprised if a bug still exists, but without a reproducer 🤷. +1 on closing if a no activity soon.

authors: Eh2406 Zoxc bkchr epage


text:
silly fix, pointer to the empty slice

Just a silly thing. I don't know when this was fixed. NLL? But we no longer need a real Vec to produce a pointer to the empty slice.

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

@bors: r+

:pushpin: Commit 2f7009f52aa18023084fb1d9268c81ca05c54db4 has been approved by alexcrichton

:hourglass: Testing commit 2f7009f52aa18023084fb1d9268c81ca05c54db4 with merge 59076352592712c4efe11e916cc23ad47785bab2...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 59076352592712c4efe11e916cc23ad47785bab2 to master...

authors: Eh2406 alexcrichton bors rust-highfive


text:
Add some documentation on writing cross-compilation tests

This adds an overview of what you need to know to write tests that do cross-compilation.

@bors r+

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

:hourglass: Testing commit 9e6d0c0500e88225b8b423c99dac3d8372b2f33a with merge 7b2fabf785755458ca02a00140060d8ba786a3ff...

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

authors: bors ehuss weihanglo


text:
Create examples directory by default when creating a lib crate (#5114)

PR for https://github.com/rust-lang/cargo/issues/5114

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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.

@alexcrichton Ping.

Ah sorry for the delay here @teovoinea!
We discussed this yesterday during our Cargo triage meeting and our conclusion though was that we probably don't want to do this just yet. We're very likely to get around to working on a larger templates feature for Cargo later this year and in the meantime we're hesitant to change the templates as-is today. We decided to have a policy of for now not changing the default templates while we sort that out, but if it doesn't pan out on our end we can certainly revisit this!

authors: alexcrichton rust-highfive teovoinea


text:
error: could not compile autocfg

error: failed to build archive: Function not implemented
error: aborting due to previous error
error: could not compile autocfg
Caused by:
process didn't exit successfully: rustc --crate-name autocfg E:\Cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\autocfg-1.0.1\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off -C metadata=b51e4be1685d4f2e -C extra-filename=-b51e4be1685d4f2e --out-dir Z:\TEMP\cargo-installjcbT8F\release\deps -L dependency=Z:\TEMP\cargo-installjcbT8F\release\deps --cap-lints allow (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: failed to build archive: Function not implemented
error: aborting due to previous error
error: failed to build archive: Function not implemented
error: aborting due to previous error
error: could not compile unicode-xid
Caused by:
process didn't exit successfully: rustc --crate-name unicode_xid E:\Cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\unicode-xid-0.2.2\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off --cfg "feature=\"default\"" -C metadata=c17fc33cedd6e2f6 -C extra-filename=-c17fc33cedd6e2f6 --out-dir Z:\TEMP\cargo-installszMnQh\release\deps -L dependency=Z:\TEMP\cargo-installszMnQh\release\deps --cap-lints allow (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: failed to build archive: Function not implemented
error: aborting due to previous error

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.
Please see the contribution instructions for more information.

I'm not sure why this is opened as a PR, but I'm going to close.  Problems should be filed as an issue.  This looks to be related to LLVM archive writing which is part of rustc. If you want to follow up, I suggest filing an issue at https://github.com/rust-lang/rust/issues/new?assignees=&labels=C-bug&template=bug_report.md, and try to include as much information as you can.  Most importantly, what is the filesystem of Z:, as it appears to not be supporting some operation.

authors: crackfan ehuss rust-highfive


text:
[meta] add more tests

Most of these are partially addressed in https://github.com/rust-lang/docs.rs/pull/524https://github.com/rust-lang/docs.rs/pull/524, but it would be better to have unit tests.
Off the top of my head:

proc macros should work (but only for default target because of bugs in cargo)
all targets are built
anything that's not only bin is built, including cdylib, rlib, etc.
[x] viewing source works (#570 )
building with docker-compose from scratch (no cache) works (expensive, doesn't need to be run on every commit)

including on hosts other than x86_64-unknown-linux-gnu

renamed crates work (e.g. constellation-rs -> constellation)
[x] 'go to latest version' works and doesn't crash (#570 )
A default-target other than the host builds successfully and is uploaded to the database as the default target

This would make me much more comfortable fixing https://github.com/rust-lang/docs.rs/issues/544 and https://github.com/rust-lang/docs.rs/issues/459.

Blocked on #822

Crates that depend on yanked crates #903

Crates that depend on yanked crates #903

These should give an error and show up on the website as a failed build, they shouldn't succeed.

The build failure that #903 is referencing isn't from a yanked crate, it's failing because the semver version constraint specified is unsatisfiable, it required something matching ^1.0.0 but the only available version was 0.1.2; which I don't think was yanked at that point (the logs were from 17:09, the crate was yanked at 17:42). The error message in that case just seems to be incorrect.

The error message in that case just seems to be incorrect.

Sounds like a rustwide bug.


text:
run cargo update

    Adding android-tzdata v0.1.1
    Updating aws-config v0.55.2 -> v0.55.3
    Updating aws-sdk-sso v0.27.0 -> v0.28.0
    Updating aws-sdk-sts v0.27.0 -> v0.28.0
    Updating aws-smithy-query v0.55.2 -> v0.55.3
    Updating aws-smithy-types-convert v0.55.2 -> v0.55.3
    Updating base64 v0.21.0 -> v0.21.2
    Updating bitflags v2.2.1 -> v2.3.1
    Updating bstr v1.4.0 -> v1.5.0
    Updating bumpalo v3.12.2 -> v3.13.0
    Updating chrono v0.4.24 -> v0.4.26
    Updating clap v4.2.7 -> v4.3.0
    Updating clap_builder v4.2.7 -> v4.3.0
    Updating clap_derive v4.2.0 -> v4.3.0
    Updating clap_lex v0.4.1 -> v0.5.0
    Updating curl-sys v0.4.61+curl-8.0.1 -> v0.4.63+curl-8.1.2
    Updating digest v0.10.6 -> v0.10.7
    Updating git2 v0.17.1 -> v0.17.2
    Updating gix-packetline v0.16.0 -> v0.16.1
    Updating hashlink v0.8.1 -> v0.8.2
    Updating io-lifetimes v1.0.10 -> v1.0.11
    Updating js-sys v0.3.62 -> v0.3.63
    Updating libgit2-sys v0.15.1+1.6.4 -> v0.15.2+1.6.4
    Updating linux-raw-sys v0.3.7 -> v0.3.8
    Updating log v0.4.17 -> v0.4.18
    Updating mio v0.8.6 -> v0.8.8
    Updating moka v0.11.0 -> v0.11.1
    Updating once_cell v1.17.1 -> v1.17.2
    Updating openssl v0.10.52 -> v0.10.54
    Updating openssl-sys v0.9.87 -> v0.9.88
    Updating proc-macro2 v1.0.56 -> v1.0.59
    Updating pulldown-cmark v0.9.2 -> v0.9.3
    Updating quote v1.0.27 -> v1.0.28
    Updating regex v1.8.1 -> v1.8.3
    Updating regex-syntax v0.7.1 -> v0.7.2
    Updating reqwest v0.11.17 -> v0.11.18
    Updating rustix v0.36.13 -> v0.36.14
    Updating security-framework v2.9.0 -> v2.9.1
    Updating sentry v0.31.0 -> v0.31.3
    Updating sentry-anyhow v0.31.0 -> v0.31.3
    Updating sentry-backtrace v0.31.0 -> v0.31.3
    Updating sentry-contexts v0.31.0 -> v0.31.3
    Updating sentry-core v0.31.0 -> v0.31.3
    Updating sentry-debug-images v0.31.0 -> v0.31.3
    Updating sentry-panic v0.31.0 -> v0.31.3
    Updating sentry-tower v0.31.0 -> v0.31.3
    Updating sentry-tracing v0.31.0 -> v0.31.3
    Updating sentry-types v0.31.0 -> v0.31.3
    Updating serde_spanned v0.6.1 -> v0.6.2
    Updating subtle v2.4.1 -> v2.5.0
    Updating syn v2.0.15 -> v2.0.18
    Updating tokio v1.28.1 -> v1.28.2
    Updating toml v0.7.3 -> v0.7.4
    Updating toml_datetime v0.6.1 -> v0.6.2
    Updating toml_edit v0.19.8 -> v0.19.10
    Updating unicode-ident v1.0.8 -> v1.0.9
    Updating uuid v1.3.2 -> v1.3.3
    Updating wasm-bindgen v0.2.85 -> v0.2.86
    Updating wasm-bindgen-backend v0.2.85 -> v0.2.86
    Updating wasm-bindgen-futures v0.4.35 -> v0.4.36
    Updating wasm-bindgen-macro v0.2.85 -> v0.2.86
    Updating wasm-bindgen-macro-support v0.2.85 -> v0.2.86
    Updating wasm-bindgen-shared v0.2.85 -> v0.2.86
    Updating web-sys v0.3.62 -> v0.3.63
    Updating zip v0.6.5 -> v0.6.6

(needs updating after the upgrades merged)

@Nemo157 done


text:
Support empty SelectAll

As documented, select_all asserts that the iterator is non-empty. When this assertion is removed, the empty SelectAll is always pending. This behavior is more convenient in some cases, like when using select! on multiple SelectAll. For example, this code currently panics, but runs fine without the assertion:
async fn example() {
    let mut ints = future::select_all([future::ready(1), future::ready(2)]).fuse();
    let mut floats = future::select_all([future::ready(3.), future::ready(4.)]).fuse();
    loop {
        futures::select! {
            (val, _, rest) = ints => {
                println!("int: {}", val);
                ints = future::select_all(rest).fuse();
            },
            (val, _, rest) = floats => {
                println!("float: {}", val);
                floats = future::select_all(rest).fuse();
            },
            default => break,
        }
    }
}

I don't know whether modifying select_all or adding another function that accepts empty iterators is the better solution.

Same as https://github.com/rust-lang/futures-rs/issues/1765. In this issue, FuturesUnordered is proposed as an alternative. With it, the example code looks like this:
async fn example() {
    let mut ints = FuturesUnordered::from_iter([future::ready(1), future::ready(2)]);
    let mut floats = FuturesUnordered::from_iter([future::ready(3.), future::ready(4.)]);
    loop {
        futures::select! {
            val = ints.next() => {
                if let Some(val) = val {
                    println!("int: {:?}", val);
                }
            },
            val = floats.next() => {
                if let Some(val) = val {
                    println!("float: {:?}", val);
                }
            },
            complete => break,
        }
    }
}

(By the way, it would be nice to allow non-exhaustive patterns in futures::select! with default.)
Maybe, add a note in the select_all documentation that FuturesUnordered is the alternative for pending indefinitely in case of no futures.

repo: rust-lang/futures-rs


text:
Set up Mastodon instance

Following a request from the leadership council, we want to set up a Mastodon instance for news from the Rust project and incident/status reports from services like crates.io.
The crates.io team has already started to explore the Mastodon integration, using a hosted server at masto.host (@LawnGnome has been working on this).
There is general consensus in the team to use a managed server instead of self-hosting an instance.
Questions

toot.io mentions optional SSO in their features list. Can we use that to grant multiple users control over the same account (e.g. @rustlang)?

Tasks

[x] Sign up for a hosted server at masto.host
[x] Create a new account with admin@rust-lang.org as the owner

[x] Grant this account owner privileges

[x] Clarify with council who will configure the server (brand, about, privacy policy, ...)
[x] Create invite link for @rustlang account and share with council
[ ] Create a new account for @status
~Configure WebFingers for the rust-lang.org domain~

References

Social media topic in council on Zulip
Mastodon topic in t-infra on Zulip

The instance is running and the project is now tooting from the rust account.
After some research and a chat with masto.host's support, we probably cannot safely enable different domains for our server anymore. This must be done before federating with other servers, which is now too late. Investigating this further seems not worth the effort given the small, purely visual difference this change would have.
The status account hasn't been created yet, but I'll do that whenever @LawnGnome wants to continue with the implementation.

repo: rust-lang/infra-team


text:
RFC: DynTrait and VTable

Add a DynTrait trait and a VTable type to provide access to the components of a fat pointer to a trait object dyn SomeTrait, and the ability to reconstruct such a pointer from its components.

HTML view
This RFC is based on @Gankro’s proposal at https://gist.github.com/Gankro/b053cb4d1cb3bcaec070de89734720f7. By the time I got it into a submittable state however, I because increasingly convinced that it would be better replaced by a more general design that would apply not just to trait objects but all pointers, with an associated type for (fat) pointer metadata. I’m submitting this as a PR anyway for posterity and comparison, but I’ll be closing it immediately.

Closing in favor of https://github.com/rust-lang/rfcs/pull/2580.

repo: rust-lang/rfcs


text:
Make generate-book.sh work on macOS.

The macOS ln command does not support the -r or -t flags.  This changes it so that it should work on all platforms.

Closing per #3215.


text:
Enable CI on Fuchsia

r? @Thomasdezeeuw

Oops, forgot this in #191. Thanks @tamird.

Oops, forgot this in #191. Thanks @tamird.

authors: Thomasdezeeuw tamird


text:
Correctness fixes for stage2

Correctness fixes to allow the bootloader to work on bochs and kvm.
closes #327

Thanks a lot!

repo: rust-osdev/bootloader


text:
Fixed bug with supply_args filtering for cargo arg

Before this commit I was getting the following error:
    Finished dev [unoptimized + debuginfo] target(s) in 1m 07s
     Running `target/debug/cargo-supply-chain`
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', src/main.rs:80:8
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Context is this statement:
// When invoked via `cargo supply-chain update`, Cargo passes the arguments it receives verbatim.
// So instead of "update" our binary receives "supply-chain update".
// We ignore the "supply-chain" in the beginning if it's present.
if supply_args[0] == "supply-chain" {
    supply_args.remove(0);
}

After a simple cargo run of this crate. I fixed the bounds error which may have been caused by pico-args not always returning the first argument as the caller

Ah, my bad. Thanks for catching this!

Ah, my bad. Thanks for catching this!

authors: Owez Shnatsel

repo: rust-secure-code/cargo-supply-chain


text:
Remove libc runtime dependency

Summary of the PR
With this PR the library has no runtime dependencies  except rust's global allocator. This could mean an ever so slightly security increase, because raw syscalls are not subject to LD_PRELOAD.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:

[x] All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.
[x] All added/changed functionality has a corresponding unit/integration
test.
[x] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.

Thanks for the recent contributions.
I am not sure this brings any improvement. First of all, it uses an external dependency that is quite new and unused (compared to libc at the very least). I'd much rather depend on the C standard library and the rust libc wrapper. The libc wrapper should also be very thin and just delegate to inline assembly for making the syscall. Secondly, almost every application depends on libc already (unless you're trying to use it in a [no_std] environment?).
The apply_filter function of the library is quite a thin wrapper over a couple of syscalls. If the consumer of the library has a more opinionated way of installing the filters, it's quite easy to do this in the application code.

authors: Kijewski alindima

repo: rust-vmm/seccompiler


text:
Use predictable/persistent/stable/etc. names for gpio and i2c

Currently device index is used for gpio/i2c, but in some cases same controller can have different index from boot to boot.

@vvavrychuk I am not sure I understood the problem properly.
The device information is passed by the user while starting the daemon. Are you suggesting to pass a string for the name of the device instead, which the code should use to get the device index ?

Yes, exactly.

@vvavrychuk I have tried an implementation, please see if it looks okay or not. Thanks.

I2C is fixed. GPIO is left.

There is no sane way of doing this for GPIO as discussed in the other pull request. Mark this resolved now.

authors: vireshk vvavrychuk

repo: rust-vmm/vhost-device


text:
ffi function xcb_xkb_get_names_value_list_unpack is not generated

Looking at the python script, it doesn't generate any unpack functions? Or at least that variable is defined but never used. Is this an oversight?

It's quite likely that not all functions are generated.
XKB in particular is very complex to handle.

This is not needed anymore in v1.0.
The extensions are implemented in rust directly, no more bindings to C functions need to be generated.

v1.0.0 is released.

authors: Timidger rtbo

repo: rust-x-bindings/rust-xcb


text:
Rustic opendal:b2 doesn't work on Windows

It works fine on Linux, but on Windows I get hit with:
[INFO] using config C:\Users\Douglas Parker\AppData\Roaming\rustic\config\rustic.toml
[WARN] service=b2 operation=stat path=keys\a78464a933185e874b3f08533249cef3dacdfc52c5895a86fefd4ab889400c6f -> NotFound (persistent) at stat, context: { service: b2, path: keys\a78464a933185e874b3f08533249cef3dacdfc52c5895a86fefd4ab889400c6f } => no such file or directory
error: incorrect password!

Same rustic.toml between platforms.

Rclone backend works fine on Windows with the same API keys.

I would guess that this is an opendal issue..
I just updated to the newest opendal version. @douglasparker Can you please test if the latest nightly version still has this problem?

@aawsome I also have this issue with Rustic v0.9.3!
The same exact rustic.toml works with Linux. opendal is definitely not working properly on Windows.
Trace Logging
PS C:\Users\Neureka> rustic backup
[INFO] using config C:\Users\Neureka\AppData\Roaming\rustic\config\rustic.toml
[DEBUG] (1) opendal::services::b2::backend: backend build started: B2Builder { config: B2Config { root: None, application_key_id: Some("<redacted>"), bucket_id: "<redacted>", bucket: "<redacted>", .. }, .. }
[DEBUG] (1) opendal::services::b2::backend: backend use root /
[DEBUG] (1) opendal::services::b2::backend: backend use bucket <redacted>
[DEBUG] (1) opendal::services::b2::backend: backend bucket_id <redacted>
[DEBUG] (1) opendal::services: service=b2 name= : metadata started
[DEBUG] (1) opendal::services: service=b2 name= : metadata finished
[DEBUG] (1) opendal::services: service=b2 name= : metadata started
[DEBUG] (1) opendal::services: service=b2 name= : metadata finished
[DEBUG] (1) opendal::services: service=b2 name= : metadata started
[DEBUG] (1) opendal::services: service=b2 name= : metadata finished
[DEBUG] (1) opendal::services: service=b2 name= : metadata started
[DEBUG] (1) opendal::services: service=b2 name= : metadata finished
[TRACE] (1) rustic_backend::opendal: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\rustic_backend-0.4.1\src\opendal.rs:158] listing tpe: Config
[DEBUG] (1) opendal::services: service=b2 name= path=config: stat started
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:671] checkout waiting for idle connection: ("https", api.backblazeb2.com)
[DEBUG] (1) reqwest::connect: starting new connection: https://api.backblazeb2.com/
[TRACE] (1) hyper_util::client::legacy::connect::http: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\connect\http.rs:372] Http::connect; scheme=Some("https"), host=Some("api.backblazeb2.com"), port=None
[DEBUG] (1) hyper_util::client::legacy::connect::dns: resolve; host=api.backblazeb2.com
[TRACE] (1) tracing::span: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\connect\dns.rs:121] -- resolve;
[DEBUG] (34) hyper_util::client::legacy::connect::dns: resolving host="api.backblazeb2.com"
[DEBUG] (1) hyper_util::client::legacy::connect::http: connecting to 104.153.233.176:443
[DEBUG] (1) hyper_util::client::legacy::connect::http: connected to 104.153.233.176:443
[TRACE] (1) hyper_util::client::legacy::client: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\client.rs:592] http1 handshake complete, spawning background dispatcher task
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:713] checkout dropped for ("https", api.backblazeb2.com)
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:349] put; add idle connection for ("https", api.backblazeb2.com)
[DEBUG] (1) hyper_util::client::legacy::pool: pooling idle connection for ("https", api.backblazeb2.com)
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:671] checkout waiting for idle connection: ("https", api002.backblazeb2.com)
[DEBUG] (1) reqwest::connect: starting new connection: https://api002.backblazeb2.com/
[TRACE] (1) hyper_util::client::legacy::connect::http: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\connect\http.rs:372] Http::connect; scheme=Some("https"), host=Some("api002.backblazeb2.com"), port=None
[DEBUG] (1) hyper_util::client::legacy::connect::dns: resolve; host=api002.backblazeb2.com
[TRACE] (1) tracing::span: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\connect\dns.rs:121] -- resolve;
[DEBUG] (34) hyper_util::client::legacy::connect::dns: resolving host="api002.backblazeb2.com"
[DEBUG] (1) hyper_util::client::legacy::connect::http: connecting to 149.137.142.15:443
[TRACE] (2) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:808] idle interval checking for expired
[DEBUG] (1) hyper_util::client::legacy::connect::http: connected to 149.137.142.15:443
[TRACE] (1) hyper_util::client::legacy::client: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\client.rs:592] http1 handshake complete, spawning background dispatcher task
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:713] checkout dropped for ("https", api002.backblazeb2.com)
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:349] put; add idle connection for ("https", api002.backblazeb2.com)
[DEBUG] (1) hyper_util::client::legacy::pool: pooling idle connection for ("https", api002.backblazeb2.com)
[DEBUG] (1) opendal::services: service=b2 name= path=config: stat finished
[TRACE] (1) rustic_backend::opendal: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\rustic_backend-0.4.1\src\opendal.rs:158] listing tpe: Key
[DEBUG] (1) opendal::services: service=b2 name= path=keys/: list started
[DEBUG] (1) opendal::services: service=b2 name= path=keys/: list created lister
[TRACE] (1) opendal::services: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\opendal-0.50.0\src\layers\logging.rs:222] service=b2 name= path=keys/ listed=0: List::next started
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:645] take? ("https", api002.backblazeb2.com): expiration = Some(90s)
[DEBUG] (1) hyper_util::client::legacy::pool: reuse idle connection for ("https", api002.backblazeb2.com)
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:349] put; add idle connection for ("https", api002.backblazeb2.com)
[DEBUG] (1) hyper_util::client::legacy::pool: pooling idle connection for ("https", api002.backblazeb2.com)
[TRACE] (1) opendal::services: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\opendal-0.50.0\src\layers\logging.rs:222] service=b2 name= path=keys/ listed=1 entry=keys/: List::next succeeded
[TRACE] (1) opendal::services: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\opendal-0.50.0\src\layers\logging.rs:222] service=b2 name= path=keys/ listed=1: List::next started
[TRACE] (1) opendal::services: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\opendal-0.50.0\src\layers\logging.rs:222] service=b2 name= path=keys/ listed=2 entry=keys/e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85: List::next succeeded
[TRACE] (1) opendal::services: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\opendal-0.50.0\src\layers\logging.rs:222] service=b2 name= path=keys/ listed=2: List::next started
[TRACE] (1) opendal::services: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\opendal-0.50.0\src\layers\logging.rs:222] service=b2 name= path=keys/ listed=2: List::next finished
[TRACE] (1) rustic_backend::opendal: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\rustic_backend-0.4.1\src\opendal.rs:210] reading tpe: Key, id: e0667b00
[DEBUG] (1) opendal::services: service=b2 name= path=keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85: stat started
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:645] take? ("https", api002.backblazeb2.com): expiration = Some(90s)
[DEBUG] (1) hyper_util::client::legacy::pool: reuse idle connection for ("https", api002.backblazeb2.com)
[TRACE] (1) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:349] put; add idle connection for ("https", api002.backblazeb2.com)
[DEBUG] (1) hyper_util::client::legacy::pool: pooling idle connection for ("https", api002.backblazeb2.com)
[WARN] service=b2 name= path=keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85: stat failed NotFound (persistent) at stat, context: { service: b2, path: keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85 } => no such file or directory
[DEBUG] (1) opendal::services: service=b2 name= path=keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85: stat failed
error: NotFound (persistent) at stat, context: { service: b2, path: keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85 } => no such file or directory
[TRACE] (31) hyper_util::client::legacy::pool: [C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\hyper-util-0.1.9\src\client\legacy\pool.rs:791] pool closed, canceling idle interval

I think this is the same problem as https://github.com/rustic-rs/rustic/issues/1302

[WARN] service=b2 name= path=keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85: stat failed NotFound (persistent) at stat, context: { service: b2, path: keys\e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85 } => no such file or directory

This is the problem. We should look for keys/e0667b00138865aaadec6b32ae1ac40cf5c63138c912b60c07e8a0e37e17df85 instead. I think the PR fixes this as it uses unix-style paths instead of OS-dependent paths from std Rust.

You guys are awesome! Thanks for the quick fix!

authors: NeurekaSoftware aawsome douglasparker

repo: rustic-rs/rustic


text:
Fix typo in GLM Mat4 docs

Was reading through the docs for the new GLM library (which looks fantastic, by the way - looking forward to trying it out!) and spotted a very small typo/copy and paste error  - it says that Mat4 is a 4x3 matrix, rather than a 4x4 matrix.

Thanks!

repo: rustsim/nalgebra


text:
left: 2, right: 1,  crates/cli-support/src/js/mod.rs:2745:17

Describe the Bug
I have made a few innocent looking changes to my code that was previously working fine. Now it wasmpack fails when I run this command:
wasm-pack build --target web --no-typescript

...

[INFO]: ⬇  Installing wasm-bindgen...
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `1`', crates/cli-support/src/js/mod.rs:2745:17
stack backtrace:
   0:        0x1090da304 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hcfc48256a5ab8835
   1:        0x1090f8a00 - core::fmt::write::haf3903118f694c48
   2:        0x1090d7496 - std::io::Write::write_fmt::h7385463ac87804ed
   3:        0x1090dbd7f - std::panicking::default_hook::{{closure}}::h91bd4c58cf71392b
   4:        0x1090dba4d - std::panicking::default_hook::h7bd29c87df967048
   5:        0x1090dc34b - std::panicking::rust_panic_with_hook::hae2b05f08a320721
   6:        0x1090dbecb - std::panicking::begin_panic_handler::{{closure}}::h72d68d3a77e0b718
   7:        0x1090da778 - std::sys_common::backtrace::__rust_end_short_backtrace::h7c5e286792f94edb
   8:        0x1090dbe8a - _rust_begin_unwind
   9:        0x10912b15b - std::panicking::begin_panic_fmt::h6826a3ebe3a95a51
  10:        0x108e18d8a - wasm_bindgen_cli_support::js::Context::invoke_import::h1346e568022b27de
  11:        0x108e6c18c - wasm_bindgen_cli_support::js::binding::instruction::h3ab0e8c1f837816a
  12:        0x108e628c3 - wasm_bindgen_cli_support::js::binding::Builder::process::ha097d07b4a8b00f8
  13:        0x108e10ebf - wasm_bindgen_cli_support::js::Context::generate::hebc298268fc9acc3
  14:        0x108e27654 - wasm_bindgen_cli_support::Bindgen::generate_output::hebe5328caf510c3f
  15:        0x108de8592 - wasm_bindgen_cli_support::Bindgen::generate::h6e6e49d758260885
  16:        0x108debb21 - wasm_bindgen::main::hc3ab957f18625d20
  17:        0x108de9aba - std::sys_common::backtrace::__rust_begin_short_backtrace::h3315c83da1796513
  18:        0x108de9afc - std::rt::lang_start::{{closure}}::h0a054103414d967f
  19:        0x1090dc7a4 - std::rt::lang_start_internal::hd38bb63f9540b327
  20:        0x108dec059 - _main
Error: Running the wasm-bindgen CLI
Caused by: failed to execute `wasm-bindgen`: exited with exit code: 101

Steps to Reproduce
I am sorry but I can't find simple steps to reproduce. I realize this makes it very hard to find out what's wrong, but I am creating this ticket to at least get some assistance on what can be the root cause of the error, given that the error message does not provide any hints.
Expected Behavior
The code compiles with Rustc and wasmpack should either work or give an error message explaining what's wrong.
Actual Behavior
Error message does not make sense:
'assertion failed: `(left == right)`
  left: `2`,
 right: `1`'

Additional Context
Versions (latest stable):
wasm-pack 0.9.1
cargo 1.49.0 (d00d64df9 2020-12-05)
rustc 1.49.0 (e1884a8e3 2020-12-29)

It was very hard to find out which line of code was causing the issue, but now I have narrowed it down to a usage of async fn which returned a Result<Response, JsValue>, breaking the rule at https://rustwasm.github.io/wasm-bindgen/reference/js-promises-and-rust-futures.html#return-values-of-async-fn that says async fn cannot return just any type.
I fixed that, but now it's still failing to compile.
Here's the signature of my function now:
pub async fn send_dpop_request(data: &HttpRequestData, key: &Key) -> Result<JsValue, JsValue>

Which I use elsewhere like this:
async fn handle_http_req_message(trace_id: JsValue, data: JsValue) -> Result<JsValue, JsValue> {
   ...
        let resp_js = send_dpop_request(&request_data, &key).await?;
        let response: Result<Response, JsValue> = resp_js.dyn_into();
   ...

This also fails to compile.
If I replace the last line with this, it compiles:
let response: Result<Response, JsValue> = unimplemented!();

It seems that dyn_into() cast is what's failing.

Thanks for the report! Unfortunately I probably can't help much without a reproduction. This definitely looks like a bug in wasm-bindgen, but I'm not sure where it is or what would trigger it :(

Yeah, sorry about that. But I can tell you for sure that it seems related to moving the Response object from async fn then trying to do dyn_into() from a JsValue. Should be easy to reproduce, but I already spent 2 days on this bug so wont' be able to help you right now.

By the way: I didn't overcome the issue, I just wrote this part of the code in Js :/

Probably unrelated but, I got a very similar error (note the different line number), when I had accidentally marked a method #[wasm_bindgen(getter)] with no self parameter
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `1`', crates/cli-support/src/js/binding.rs:166:9

I also ran into a similar issue recently with this rust input:
#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(extends = js_sys::Object)]
    pub type Panels;

    #[wasm_bindgen(method, getter)]
    pub fn create(this: &Panels, title: &str, icon_path: &str, page_path: &str);
}

Obviously create can't be a getter with the additional arguments.
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `1`', crates/cli-support/src/js/mod.rs:3033:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/panicking.rs:65:14
   2: core::panicking::assert_failed_inner
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/panicking.rs:246:17
   3: core::panicking::assert_failed
   4: wasm_bindgen_cli_support::js::Context::invoke_import
   5: wasm_bindgen_cli_support::js::binding::instruction
   6: wasm_bindgen_cli_support::js::binding::Builder::process
   7: wasm_bindgen_cli_support::js::Context::generate
   8: wasm_bindgen_cli_support::Bindgen::generate_output
   9: wasm_bindgen_cli_support::Bindgen::generate
  10: wasm_bindgen::main

I seem to recall that bugs like this used to be caught in the rust compilation phase and never making it to the wasm-bindgen phase.
Unfortunately if bugs like this are making it to the wasm-bindgen phase the assertions make it quite difficult to figure out the exact issue. For my case I added a bail! statement instead of an assert and it helped me figure out my issue. I wonder if it would be worth it to move our assertions to bail! so we at least get the context of where the failure is coming from.
My change: https://github.com/dylanowen/wasm-bindgen/commit/c09af342108a509e7b29a0886ec70bcf0ef3e80e

authors: alexcrichton dylanowen prestwich renatoathaydes

repo: rustwasm/wasm-bindgen


text:
torch sparse version bug

! pip install torch-scatter==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
! pip install torch-sparse==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
! pip install torch-cluster==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
! pip install torch-spline-conv==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
! pip install torch-geometric

normally, it works.
I can not import any from torch_geometric.
Error
OSError: /usr/local/lib/python3.6/dist-packages/torch_sparse/_version.so: undefined symbol: _ZN3c105ErrorC1ENS_14SourceLocationERKSs

the same problem on Google Colab.
first I wanted to install torch-geometric using this code (based on versions of pytorch and cuda):
%pip install torch-scatter==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.6.0.html
%pip install torch-sparse==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.6.0.html
%pip install torch-cluster==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.6.0.html
%pip install torch-spline-conv==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.6.0.html
%pip install torch-geometric

but torch-sparse and torch-cluster couldn't be installed because of following Error:
ERROR: No matching distribution found for torch-cluster==latest+cu101

so I Uninstalled all and reinstalled using:
%pip install torch-scatter==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-sparse==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-cluster==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-spline-conv==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-geometric

which installed properly. but this time when I import torch-geometric I get the following error:
OSError: /usr/local/lib/python3.7/site-packages/torch_sparse/_version.so: undefined symbol: _ZN3c105ErrorC1ENS_14SourceLocationERKSs

Seems like a versioning conflict. Are you sure that you are using torch<1.6.0 when using the 1.5.0 wheels?

in addition, when i run e.g. dgcnn_classification.py, it shows i should use pytorch 1.4.0, then i follow the instruction delete torch and install. but 1.4.0 complie only with cuda 9.2.

Why does it say you should install torch==1.4.0? And what‘s the problem with this?

i think i found the problem, with following install code:
%pip install torch-scatter==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-sparse==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-cluster==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-spline-conv==latest+cu101 -f https://pytorch-geometric.com/whl/torch-1.5.0.html
%pip install torch-geometric
my torch version shows 1.6.0+cu101.
after running pip install torch-geometric, it will install the torch.1.6.0 automatically instead of 1.5.0. Is there anyway to fix this?

Seems like a versioning conflict. Are you sure that you are using torch<1.6.0 when using the 1.5.0 wheels?

i delete torch.1.6.0, install torch. 1.5.0,  OSError: is gone. but new error occurs.

Why does it say you should install torch==1.4.0? And what‘s the problem with this?
it said that support 1.4.0 not 1.6.0.
one week ago, everything works fine. i think the problem is between colab and your new update.

@asalimih
do you know other platform with GPU other than colab? i really need run some test within this week

Your installation if torch==1.5.0 is fine, the problem is within torchvision. You either need the correct torchvision version for PyTorch 1.5.0, or uninstall it completely for PyG (it‘s not really needed).

Your installation of torch==1.5.0 is fine, the problem is within torchvision. You either need the correct torchvision version for PyTorch 1.5.0, or uninstall it completely for PyG (it‘s not really needed).
@asalimih
Fixed by following
pip install torch==1.5.0+cu101 torchvision==0.6.0+cu101 -f https://download.pytorch.org/whl/torch_stable.html


text:
add to-do-list deploy scripts and shared resources

add to-do-list deploy scripts and shared resources

ok


text:
Synced/fixed SoS2 allowed torpedo changing

Relies on rwmt/Multiplayer#305 to work

Should I merge this one? rwmt/Multiplayer#305 was merged and published.

Honestly, this one is a bit obsolete at this point. SoS2 will require a completely new patch for 1.4, so those changes would matter for 1.3 only. So honestly, it doesn't really matter if it's accepted or closed at this point.

authors: SokyranTheDragon notfood

repo: rwmt/Multiplayer-Compatibility


text:
Complexify method is doing a shift in received array

Hey,
I'm using the complexify method in a plain array of locations and I realized that the method is eating the first position of the input array.
Looking at the code I found this entry:
cur = linestring.shift();
That could be changed to cur = linestring[0]?
Thanks
Julian

Hey Julian,
I've set a reminder to fix this in the next day. I'll push an update after
looking at the code. Thanks
On Mon, 18 Apr 2016 10:36 pm Julian Monteiro, notifications@github.com
wrote:

Hey,
I'm using the complexify method in a plain array of locations and I
realized that the method is eating the first position of the input
array.
Looking at the code I found this entry:
cur = linestring.shift();
That could be changed to cur = linestring[0]?
Thanks
Julian
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/rwt-to/GeoJSON-Tools/issues/9

Hi @jmfly I've released 0.2.2 with the fix

authors: jmfly nevi-me

repo: rwt-to/GeoJSON-Tools


text:
Why does the pipeline create a branch that starts with changeset-release

First of all, thank you for your work! I used this package in self-hosted gitlab, but I found it create a branch that starts with changeset-release , such as  changeset-release/master.

It needs to create a PR for releasing. Is there any downside?

repo: rx-ts/changesets-gitlab


text:
Error

expected ':' after key at line 1 col 5

This is an error emitted by the library when the json passed to it is not valid. You'll have to provide a bit more information if you're confused about how to use the library or if you suspect there is a bug in the library.

authors: doouglasabreu rxi


text:
Start in the current directory rather than EXEDIR

This changes the behavior when lite is started without arguments,
e.g. from a terminal. Rather than showing lite installation
directory, it shows current directory, removing the need to
start lite as lite ..

Looks like I am not the only one confused by lite starting in EXEDIR and ignoring the current path: #177
. is available both on *nix and windows, so this change should be portable.

Looks like I am not the only one confused by lite starting in EXEDIR and ignoring the current path: #177
. is available both on *nix and windows, so this change should be portable.

It seems to me that the author will ignore this pr. Perhaps if you add reading the path(optional) from the config file without overcomplicating the code, the author will accept the change.

It seems to me that the author will ignore this pr. Perhaps if you add reading the path(optional) from the config file without overcomplicating the code, the author will accept the change.

What is the reasoning behind using EXEDIR? Are users supposed to copy lite + data/ to every project dir?

What is the reasoning behind using EXEDIR? Are users supposed to copy lite + data/ to every project dir?

I think rxi, the author of lite, already made clear he doesn't want to change this. You are supposed to launch from the command line using the path of the project as argument or, on windows, drag the path into the lite's executable.
I am the author of lite xl. You may have a look at my fork. I am less strict about the simplicity and lite-xl is a little bit more user friendly for many things.

I think rxi, the author of lite, already made clear he doesn't want to change this. You are supposed to launch from the command line using the path of the project as argument or, on windows, drag the path into the lite's executable.
I am the author of lite xl. You may have a look at my fork. I am less strict about the simplicity and lite-xl is a little bit more user friendly for many things.

Another problem: if you pass a file as an argument, the editor will not open its directory.
It also won't create a new document if the file doesn't exist.
I fixed it via bash:
function dlite () {
   if [ "$#" -gt 0 ]; then
      touch "$1"
      devour lite $(dirname "$1") "$1"
   else
      devour lite .
   fi
}

Another problem: if you pass a file as an argument, the editor will not open its directory.
It also won't create a new document if the file doesn't exist.
I fixed it via bash:
function dlite () {
   if [ "$#" -gt 0 ]; then
      touch "$1"
      devour lite $(dirname "$1") "$1"
   else
      devour lite .
   fi
}

I think rxi, the author of lite, already made clear he doesn't want to change this.
Where? I searched the issue tracker and only found #177

You are supposed to launch from the command line using the path of the project as argument or, on windows, drag the path into the lite's executable.
But this PR does not change behavior in both of these cases.

I think rxi, the author of lite, already made clear he doesn't want to change this.
Where? I searched the issue tracker and only found #177

You are supposed to launch from the command line using the path of the project as argument or, on windows, drag the path into the lite's executable.
But this PR does not change behavior in both of these cases.

Where? I searched the issue tracker and only found #177

https://github.com/rxi/lite/issues/153

But this PR does not change behavior in both of these cases.

I think your patch implements the old behavior that rxi changed (just before https://github.com/rxi/lite/issues/153 if I remember correctly). The idea of starting in the current directory is reasonable but there is a big problem when an user launch it unknowingly from the home directory. In this case lite will eat all your memory trying to scan recursively the whole home directory. If you are on linux it may even make your PC completely unresponsive because of swap-trashing (this is a know problem on linux). There was an issue on github about that.
By the way I fixed the problem of directories too big in lite-xl with a stop-gap solution that limit the maximum number of files to scan. Just to make sure it doesn't kill your system.
Otherwise lite-xl keeps trace of the most recent directories you used and it opens the last one if you don't provide any argument from the command line. It seems the only sensible behavior to me. Starting from the current directory is unfriendly for people launching lite-xl from the graphical user interface.
I think this explains why rxi choose to use EXEDIR by default changing the previous behavior that was to open the current directory.

Where? I searched the issue tracker and only found #177

https://github.com/rxi/lite/issues/153

But this PR does not change behavior in both of these cases.

I think your patch implements the old behavior that rxi changed (just before https://github.com/rxi/lite/issues/153 if I remember correctly). The idea of starting in the current directory is reasonable but there is a big problem when an user launch it unknowingly from the home directory. In this case lite will eat all your memory trying to scan recursively the whole home directory. If you are on linux it may even make your PC completely unresponsive because of swap-trashing (this is a know problem on linux). There was an issue on github about that.
By the way I fixed the problem of directories too big in lite-xl with a stop-gap solution that limit the maximum number of files to scan. Just to make sure it doesn't kill your system.
Otherwise lite-xl keeps trace of the most recent directories you used and it opens the last one if you don't provide any argument from the command line. It seems the only sensible behavior to me. Starting from the current directory is unfriendly for people launching lite-xl from the graphical user interface.
I think this explains why rxi choose to use EXEDIR by default changing the previous behavior that was to open the current directory.

Great, thanks, closing the PR then. I've linked #177 to #153 so it's easier to find next time.

Great, thanks, closing the PR then. I've linked #177 to #153 so it's easier to find next time.

authors: Jipok francesco-st link2xt

repo: rxi/lite