text:
Support github auth for private repos.

It would be nice to be able to supply github oauth creds so that we can run this for private repos.

@seawatts this is also on my radar

Great! Thanks :+1:

#16

authors: runspired seawatts

repo: runspired/ember-cli-changelog


text:
Fix issue with mac / safari

We seem to have a problem with the plugin when run either on Safari or on mac.
No tests are generated.
Illustrative screenshot attached.
Capture d’écran 2023-10-16 à 10.53.14.pdf

Tested on @anvacaru M1, ventura OS 13.1, Safari v16.2
Local VSCode works as expected.
In safari github.dev wouldn't even load.

I am closing this as I think this is being addressed.

source: gharchive/issue

authors: jinxinglim radumereuta yfalcone

repo: runtimeverification/ercx-vscode

license_type: permissive

license_source: github-api


text:
Kompile uses new type inference algorithm

A new type inference algorithm has been introduced to K. This PR opts into using that algorithm by setting the appropriate flags in kbuild.toml

I am popping this up since the type-inference feature is supported by pyk by PR https://github.com/runtimeverification/pyk/pull/767.

Created an issue here

@Baltoli Things should be working now, I am still a bit unsure how to determine if it is using the new algorithm or not. How would be determine this? If you would like to see differences in timing I am recording local timing in #308

source: gharchive/pull-request

repo: runtimeverification/mir-semantics


text:
Updates to README and cabal files for native tokens generation

File native-tokens/README.md explains how to run the native tokens policy generation script without entering nix-shell.

Two compiler options were added to native-tokens.cabal:
-fplugin-opt PlutusTx.Plugin:no-simplifier-inline
-fplugin-opt PlutusTx.Plugin:no-simplifier-beta

They seem to help with code inlining in the context of this thread and issue #269.

@Guy Repta @.***> MD viewer enumerate this
properly.
On Mon, Aug 15, 2022 at 10:26 AM gtrepta @.***> wrote:

@.**** requested changes on this pull request.
Just a quick formatting error. LGTM otherwise, so I'll approve after it's
fixed.
In native-tokens/README.md
https://github.com/runtimeverification/plutus-core-semantics/pull/279#discussion_r945728871
:

+1. Change to native-tokens/native-tokens.

+1. Create a symbolic link from plutus/shell.nix to native-tokens/native-tokens.
+1. Run nix-shell --command 'cabal build'.
+1. Run nix-shell --command 'cabal run native-tokens-scripts out_scripts scripts'.
+1. There will be 5 flat format files in out_scripts.
+1. In bash, run the following command. (Make sure
⬇ Suggested change
-1. Change to native-tokens/native-tokens.
-1. Create a symbolic link from plutus/shell.nix to native-tokens/native-tokens.
-1. Run nix-shell --command 'cabal build'.
-1. Run nix-shell --command 'cabal run native-tokens-scripts out_scripts scripts'.
-1. There will be 5 flat format files in out_scripts.
-1. In bash, run the following command. (Make sure
+1. Change to native-tokens/native-tokens.
+2. Create a symbolic link from plutus/shell.nix to native-tokens/native-tokens.
+3. Run nix-shell --command 'cabal build'.
+4. Run nix-shell --command 'cabal run native-tokens-scripts out_scripts scripts'.
+5. There will be 5 flat format files in out_scripts.
+6. In bash, run the following command. (Make sure

In native-tokens/README.md
https://github.com/runtimeverification/plutus-core-semantics/pull/279#discussion_r945731335
:

+1. In bash, run the following command. (Make sure

plutus/dist-newstyle/build/x86_64-linux/ghc-8.10.4.20210212/plutus-core-0.1.0.0/x/uplc/build/uplc/uplc is in your PATH.)

Is there some canonical way to get the plutus binaries onto PATH with nix?
I just did a manual export PATH... command the last time I followed these
instructions.
—
Reply to this email directly, view it on GitHub
https://github.com/runtimeverification/plutus-core-semantics/pull/279#pullrequestreview-1072676880,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNNCEMWTKG6YROQXPJ2EFTVZJARXANCNFSM56MZ3D2Q
.
You are receiving this because you authored the thread.Message ID:
<runtimeverification/plutus-core-semantics/pull/279/review/1072676880@
github.com>


text:
Add: Patrick Collins Yt

Fixes Issue

Closes #1760
Changes proposed

I have added Patric Collins' YouTube channel to the project.
Screenshots

Note to reviewers

I am taking part in Hacktoberfest 2023, kindly include the corresponding label.

@CBID2 , does this fix?

@CBID2 , does this fix?

Yup

Hey @CBID2, I've updated the description as per your suggestion. Will the merged Codecademy pull request be affected by my commit reversal?

Hey @CBID2, I've updated the description as per your suggestion. Will the merged Codecademy pull request be affected by my commit reversal?

No @Shiva-Sai-ssb. It's already merged :)

Hey @CBID2, I've updated the description as per your suggestion. Will the merged Codecademy pull request be affected by my commit reversal?

No @Shiva-Sai-ssb. It's already merged :)

okay, thank you for your assistance.

@Shiva-Sai-ssb
It's codecademy not codeacademy

@Anmol-Baranwal, that change was made in a different PR

@Shiva-Sai-ssb
It's codecademy not codeacademy

@Anmol-Baranwal, that change was made in a different PR: #1707

Yeah! @Shiva-Sai-ssb changed that, so she needs to revert to correct the spelling of brand Codecademy.

@Shiva-Sai-ssb
It's codecademy not codeacademy

@Anmol-Baranwal, that change was made in a different PR: #1707

Yeah! @Shiva-Sai-ssb changed that, so she needs to revert to correct the spelling of brand Codecademy.

What do I do next? Should I rename Codecademy?

Yeah! @Shiva-Sai-ssb changed that, so she needs to revert to correct the spelling of brand Codecademy.

What should I do? Should I rename Codecademy?

You have changed codecademy to codeacademy.

what you did.

check ur deployed link

Leave it, I have done it.

@CBID2
Good to go now.

Thanks for the contribution @Shiva-Sai-ssb!😊 It was wonderful working with you! 😄 If you want to stay updated on LinksHub, join our Discord community! :) We'd love to have you! :)

authors: Anmol-Baranwal CBID2 Shiva-Sai-ssb

repo: rupali-codes/LinksHub

license: MIT


text:
OpenCV 3.0.0-beta (was: OS X GStreamer.framework <-> ZLIB assert error)

On my OS X system /Library/Frameworks/GSTreamer.framework seems to be first in line for providing ZLIB (and possibly PNG) dependencies.  That framework provides an assert.h file which ends up leaving the assert macro undefined in files which rely on the standard /usr/include/assert.h macro.
I believe that is responsible for the errors I'm seeing in the OpenCV build now.  If I temporarily move GStreamer out of the way, that fixes the undeclared identifiers issues in the OpenCV assert calls.
Errors:
[ 53%] Building CXX object modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/src/loadsave.cpp.o
cd /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/modules/imgcodecs && /usr/bin/clang++   -DOPENCV_NOSTL -D__OPENCV_BUILD=1 -std=c++11 -stdlib=libc++ -fPIC   -fsigned-char -W -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -fdiagnostics-show-option -Wno-long-long -Wno-semicolon-before-method-body -fno-omit-frame-pointer -msse -msse2 -msse3 -fvisibility=hidden -fvisibility-inlines-hidden -Wno-deprecated-declarations -O3 -DNDEBUG  -DNDEBUG -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/3rdparty/libjasper -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/3rdparty/libjpeg -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/3rdparty/ippicv/unpack/ippicv_osx/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build -isystem /usr/local/include/eigen3 -isystem /Library/Frameworks/GStreamer.framework/Headers -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/modules/imgcodecs -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include -I/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include    -o CMakeFiles/opencv_imgcodecs.dir/src/loadsave.cpp.o -c /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/loadsave.cpp
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/loadsave.cpp:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/precomp.hpp:50:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/imgproc_c.h:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/types_c.h:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/core_c.h:48:
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:485:5: error: use of undeclared identifier 'assert'
    assert( (unsigned)CV_MAT_DEPTH(type) <= CV_64F );
    ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:526:5: error: use of undeclared identifier 'assert'
    assert( (unsigned)row < (unsigned)mat->rows &&
    ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:533:9: error: use of undeclared identifier 'assert'
        assert( type == CV_64FC1 );
        ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:543:5: error: use of undeclared identifier 'assert'
    assert( (unsigned)row < (unsigned)mat->rows &&
    ^
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/types_c.h:550:9: error: use of undeclared identifier 'assert'
        assert( type == CV_64FC1 );
        ^
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/loadsave.cpp:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgcodecs/src/precomp.hpp:50:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/imgproc_c.h:46:
In file included from /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/imgproc/include/opencv2/imgproc/types_c.h:46:
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Source/modules/core/include/opencv2/core/core_c.h:1133:5: error: use of undeclared identifier 'assert'
    assert( _elem->flags >= 0 /*&& (elem->flags & CV_SET_ELEM_IDX_MASK) < set_header->total*/ );
    ^
6 errors generated.
make[5]: *** [modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/src/loadsave.cpp.o] Error 1
make[4]: *** [modules/imgcodecs/CMakeFiles/opencv_imgcodecs.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [OpenCV-release-prefix/src/OpenCV-release-stamp/OpenCV-release-build] Error 2
make[1]: *** [CMakeFiles/OpenCV-release.dir/all] Error 2
make: *** [all] Error 2

[hunter ** FATAL ERROR **] Build step failed (dir: /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV
[hunter ** FATAL ERROR **] [Directory:/Users/dhirvonen/devel/hunter/cmake/projects/OpenCV]

This really seems to have nothing to do with hunter, although it does affect hunter packages, and I'm posting this in case other people run into this same issue, which appears to be a side effect of the GStreamer framework shadowing the assert.h file locally.
UPDATE: Looking at the CMakeCache.txt of the OpenCV recipe, it seems GStreamer is picked up for both PNG and TIFF packages (which ends up putting the GStreamer assert.h in the preprocessor path), so providing a top level PNG_ROOT and TIFF_ROOT hint could be a work around.
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/CMakeCache.txt:WITH_GSTREAMER:INTERNAL=OFF
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt:PNG_PNG_INCLUDE_DIR:PATH=/Library/Frameworks/GStreamer.framework/Headers
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt:TIFF_INCLUDE_DIR:PATH=/Library/Frameworks/GStreamer.framework/Headers
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt://Enable Gstreamer 0.10 support (instead of 1.x)
/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV/Build/OpenCV-release-prefix/src/OpenCV-release-build/CMakeCache.txt:WITH_GSTREAMER_0_10:BOOL=OFF
/

/Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe

xxxxxxx means you're using Hunter cloned from git. This usage case is for development and mean that HunterGate is not actually loading anything. So you need to update local git repository manually. In general you don't need to clone Hunter, HunterGate will do all the job for you.

On my OS X system /Library/Frameworks/GSTreamer.framework seems to be first in line for providing ZLIB (and possibly PNG) dependencies

It's not the case of Hunter. There must be a string ZLIB::zlib in cache. Please try to find CMakeCache.txt first in /Users/dhirvonen/devel/hunter/_Base/xxxxxxx/ccec2c2/b2b5fbe/Build/OpenCV directory. And this file must contain information about zlib:
> grep -i zlib /.../CMakeCache.txt

I'm testing libcxx toolchain on OS X, I see this flag in build:
-isystem /.../_Base/9308d01/ccec2c2/c018e63/Install/include

and some important info from cache /Build/OpenCV/Build/OpenCV-release-prefix/src/CMakeCache.txt:
> grep -i zlib
//The directory containing a CMake configuration file for ZLIB.
ZLIB_DIR:PATH=/.../_Base/9308d01/ccec2c2/c018e63/Install/lib/cmake/ZLIB
//Build zlib from source
BUILD_ZLIB:INTERNAL=OFF
//Details about finding ZLIB
FIND_PACKAGE_MESSAGE_DETAILS_ZLIB:INTERNAL=[ZLIB::zlib][/.../_Base/9308d01/ccec2c2/c018e63/Install/include][v1.2.8()]

I'm using:
HunterGate(
    URL "https://github.com/ruslo/hunter/archive/v0.8.10.tar.gz"
    SHA1 "9308d01ea52c7b8cf1347073c982c679dbac3c09"
)

xxxxxxx means you're using Hunter cloned from git. This usage case is for development and mean that HunterGate is not actually loading anything. So you need to update local git repository manually. In general you don't need to clone Hunter, HunterGate will do all the job for you.

I have a few new hunter packages I've defined locally, so I've been using a hunter clone to support that (they are slowly getting pushed to hunter, but I'll probably always need to maintain some set of local package definitions for things I'm experimenting with).
I believe in this case GStreamer is picked up to satisfy OpenCV TIFF and PNG dependencies, but the new hunter.cmake OpenCV recipe is disabling those
hunter_cmake_args(
    OpenCV
    CMAKE_ARGS
        BUILD_DOCS=OFF
        BUILD_TESTS=OFF
        BUILD_PERF_TESTS=OFF
        BUILD_opencv_apps=OFF
        BUILD_EXAMPLES=OFF
        # Find packages in Hunter (instead of building from OpenCV sources)
        BUILD_ZLIB=OFF
        BUILD_TIFF=OFF
        BUILD_PNG=OFF
)

I hadn't looked through the updates to that file carefully, but they all make sense.    You had added that to  help hunterize OpenCV in the new "2.4.11-p1" release (to fix 3rd party conflicts), but my code is still dependent on the unhunterized "3.0.0-beta" release, so when it is told to use (but not build) TIFF, for example, it looks elsewhere.   When a 3.0.0-beta-p1 release is made that will probably fix the issue.  In short, this is probably due to an OpenCV module that is under construction, combined with a broken GSTreamer release.  After some more searching, I fetched the latest GStreamer.framework, and they have apparently renamed their internal assert.h file to something much friendlier.

I'm going to leave this open until the other opencv releases are hunterized (or temporarily removed).

I have a few new hunter packages I've defined locally, so I've been using a hunter clone to support that (they are slowly getting pushed to hunter, but I'll probably always need to maintain some set of local package definitions for things I'm experimenting with)

I was thinking about implementing injections correctly in smoother way. As I mentioned earlier take a look at this feature: https://github.com/ruslo/hunter/issues/56
Spoiler: in such way aslo can be supported GIT_SHA1 or even reading GIT_SHA1 from git submodule

Talking about c++11. I've got this error on my OS X build:
/.../hunter-packages/opencv/modules/highgui/src/window_cocoa.mm:153:42: error: cannot initialize a parameter of type 'NSApplicationActivationPolicy' with an rvalue of type 'int'

window_cocoa.mm:
147 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
148
149 #ifndef NSAppKitVersionNumber10_5
150 #define NSAppKitVersionNumber10_5 949
151 #endif
152     if( floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_5 )
153         [application setActivationPolicy:0/*NSApplicationActivationPolicyRegular*/]; // <<< conversion error
154 #endif

Which version of OS X and Xcode do you have installed?  I'm on OS X 10.9.5
and Xcode 6.2.
Is this the same error that was fixed by switching to ios-8-2-cxx98?  I'd
be curious if running the stock opencv framework python script points to
any solutions:
opencv//platforms/ios/build_framework.py
python platforms/ios/build_framework.py ios
I don't see anything that would seem to be specific to c++11 in those few
lines of code.
I noticed I still have these configurations in my CMakeLists.txt.  I'm
assuming your original ios-8-2 was similar.
list(APPEND CMAKE_CXX_FLAGS "-std=c++11")
list(APPEND CMAKE_CXX_FLAGS "-stdlib=libc++")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++11")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_ENABLE_OBJC_ARC YES)
On Sat, Apr 18, 2015 at 1:27 PM, Ruslan Baratov notifications@github.com
wrote:

Talking about c++11. I've got this error on my OS X build:
/.../hunter-packages/opencv/modules/highgui/src/window_cocoa.mm:153:42: error: cannot initialize a parameter of type 'NSApplicationActivationPolicy' with an rvalue of type 'int'
window_cocoa.mm:
147 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6
148
149 #ifndef NSAppKitVersionNumber10_5
150 #define NSAppKitVersionNumber10_5 949
151 #endif
152     if( floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_5 )
153         [application setActivationPolicy:0/NSApplicationActivationPolicyRegular/]; // <<< conversion error
154 #endif
—
Reply to this email directly or view it on GitHub
https://github.com/ruslo/hunter/issues/72#issuecomment-94184856.

running the stock opencv framework python script points to any solutions

this build doesn't set c++11 flags

Is this the same error that was fixed by switching to ios-8-2-cxx98

I think yes

Which version of OS X and Xcode do you have installed?  I'm on OS X 10.9.5 and Xcode 6.2

I'm using Xcode 6.2 too, I don't think OS X version matter, but I have 10.10.3

I don't see anything that would seem to be specific to c++11 in those few lines of code

I think some conversion policies are just more pedantic. I've used NSApplicationActivationPolicyRegular instead of 0 and it works. I'm applying hunterize patches anyway, so I will apply this one too.

I noticed I still have these configurations in my CMakeLists.txt.  I'm
assuming your original ios-8-2 was similar

list(APPEND CMAKE_CXX_FLAGS "-std=c++11")
list(APPEND CMAKE_CXX_FLAGS "-stdlib=libc++")

Does it work for you? If this is toolchain file then this flags will be ignored, you need to set to CACHE. Also CMAKE_CXX_FLAGS is not a list but a string, so you need to set it like this:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

@headupinclouds OpenCV 3.0.0 added: https://github.com/ruslo/hunter/commit/eb7658b101ba9f0c7f80227fde8196a5363cd2c0 please pull branch develop. c++11 patches applied too, so must work fine with ios-8-2 toolchain.

@headupinclouds Hi David. So OpenCV 3.0.0 works for you and this bug can be closed?

Yes.

authors: headupinclouds ruslo

repo: ruslo/hunter

license_source: bigquery


text:
Update required?

Hi,
I notice that this was written a while ago, and the official documentation of Hunter says nothing about Sugar. Is that a completely different too from Hunter, or is it deprecated?
Thanks,
Colin

I notice that this was written a while ago

Yes, it's true. Have not such time to apply updates. Do you have any problems? It should work I think.

and the official documentation of Hunter says nothing about Sugar

Sugar is a package, so you can find pkg.sugar link which will lead to the documentation.

Hi,
After matching up all versions to latest, it seems to have brought me an error on gcc 4.9.3
sober/log/Severity.cpp:28:13: error: ‘runtime_error’ is not a member of ‘std’
       throw std::runtime_error("sober::log::Severity switch");

Seems like fixed but not released: https://github.com/ruslo/sober/commit/10617830dd6a3fb79abd97af7b46bdc9ef4d33c0

Fixed in master: https://github.com/ruslo/weather/commit/56eee62eaac327e1a048165aaa868c2f3a71972f

authors: ColinGilbert ruslo

repo: ruslo/weather


text:
Code regenerated for Rust 1.31.0 AKA Rust 2018.

Please help keep the CHANGELOG up to date by providing a one sentence summary of your change:
(N/A)

Semaphore is unable to complete this due to:
nightly-x86_64-unknown-linux-gnu installedB - rustc 1.32.0-nightly (4a45578bc 2018-12-07)

error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download

https://github.com/rusoto/rusoto/pull/1204 works so we may want to rebase that and see if it works - it'll pick up all the changes done in this PR as well. Rebase that PR, regenerate the code, push the branch again and make sure it works.  👍

Closing in favor of https://github.com/rusoto/rusoto/pull/1204 .

repo: rusoto/rusoto

license: mit


text:
Added new_with_size to ByteStream

S3's PutObject doesn't work if there isn't a content-length, for
ByteStream's that length comes from size_hint, previously this was set
to None in the case of an unsized stream, which then made it unusable
for PutObject. Since there are many cases where this would be useful for
putting to S3, this commit adds a new_with_size constructor that takes a
size_hint.
Fixes Issue #1752

Thanks!

authors: emeryc iliana


text:
Increase in type mismatches on webrender and diesel

These went yesterday from 16 and 84 to 23 and 116, presumably because of a change in 1.59.

Repro for the webrender errors:
fn foo() -> i32 {
    unreachable!();
 // ^ Expected i32, got ()
}

This is because the definition of unreachable! changed from:
#[macro_export]
#[stable(feature = "rust1", since = "1.0.0")]
macro_rules! unreachable {
    () => ({
        $crate::panic!("internal error: entered unreachable code")
    });
    ($msg:expr $(,)?) => ({
        $crate::unreachable!("{}", $msg)
    });
    ($fmt:expr, $($arg:tt)*) => ({
        $crate::panic!($crate::concat!("internal error: entered unreachable code: ", $fmt), $($arg)*)
    });
}

to:
#[cfg(not(bootstrap))]
#[macro_export]
#[rustc_builtin_macro(unreachable)]
#[allow_internal_unstable(edition_panic)]
#[stable(feature = "rust1", since = "1.0.0")]
#[cfg_attr(not(test), rustc_diagnostic_item = "unreachable_macro")]
macro_rules! unreachable {
    // Expands to either `$crate::panic::unreachable_2015` or `$crate::panic::unreachable_2021`
    // depending on the edition of the caller.
    ($($arg:tt)*) => {
        /* compiler built-in */
    };
}

repo: rust-analyzer/rust-analyzer


text:
Implement Missing Members Adds Breaking Code

I have a Struct that I am implementing the Display trait for.  I added:
impl fmt::Display for Person {

}

And then I used the Quick Fix to "Implement Missing Members" and the result was:
impl fmt::Display for Person {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        ${0:todo!()}
    }
}

The line inside of the fmt() function, ${0:todo!()}, isn't valid.  I feel like in the past, and even very recently, Analyzer used to just insert todo!() and nothing else, which was valid on its own.
rust-analyzer: 0.2.432
VS Code: 1.52.1
macOS 10.15.7

Just spotted https://github.com/rust-analyzer/rust-analyzer/issues/7037, so I suppose this can be closed.  My apologies.  I missed it when I first looked through existing issues.


text:
Semantic Highlighting: Function called str is considered builtin type

str();

is considered the builtin str type. Probably similar issues with the others.

Hmm we don't seem to resolve these properly at all when classifying them as goto def and all the other stuff doesn't work. Oh wait this actually seems to be related to the fact that the type namespace shadows the value namespace here again similar to the problem here https://github.com/rust-analyzer/rust-analyzer/issues/7408 😕

Hmm we don't seem to resolve these properly at all when classifying them as goto def and all the other stuff doesn't work. Oh wait this actually seems to be related to the fact that the type namespace shadows the value namespace here again similar to the problem here https://github.com/rust-analyzer/rust-analyzer/issues/7408 😕

authors: CryZe Veykril


text:
Make incremental sync opt-in

@matklad do you want to merge this? I'd make it opt-out, but it's fine to test it more.

bors r+
Yeah, let's make this opt-in, and next week switch it to opt-out if we fail to find the issue ourselves.

bors retry

@matklad you should probably retrigger the nightly build.

Hm, I haven't seen panics after the utf16 fix, and I now have a hypothesis that that might actually be a real fix:

I've wrote that the code I worked on when I hit the panic didn't contain non-ascii characters
I also wrote that the moment we hit a panic is not necessary the moment the error happens
And I do sometimes type Rust code in Кирилица, by accident

So let's hope that everything is fine. We'll know for sure later today :D We need to enjoy the last opportunities to break things.
Though, we still need to revert the opt-in, and we also need to implement "iterrate every char" test for line index.

There might still be a bug in the tracking of line index validity range. I can't check right now, but I think we invalidate the lines below the edited range. The UTF-16 character list for the current line might also become invalid. I'll fix that when enabling it again.

And I do sometimes type Rust code in Кирилица, by accident

XD. That's why I prefer per-window, not global, IME config.

XD. That's why I prefer per-window, not global, IME config.

Hm, I think I should try this out -- originally I disliked it, because I was always confused about which language I am using right now, as the tray indication would just change when flipping the windows. However as of couple of years ago, I am using a custom layout, which just doesn't work with the tray indicator, so I got used to not knowing which layout is active at the moment :D

authors: edwin0cheng lnicola matklad


text:
hashes: Remove casts in bench code

Casts are hard to read because they may loose data, if into works it is easier to read.
Use into instead of casting to u64.

CI is failing because the PR does not make sense. There is no From<usize> impl for u64.

Ouch that means that my naive calls to cargo bench during dev were wrong.

Did you set RUSTFLAGS to enable the benchmarks?

Nope, doing that would require that I actually know how we do things round here :)

@tcharding you should always look at the output when testing/benching. If there are no benches/tests being run or if you've changed anything and everything magically works, chances are you're not actually running the tests. I've recently caught exactly this in our repo by paying attention to the output. :)

ha, the million orange "ignored" should have been a clue.

authors: Kixunil apoelstra tcharding

repo: rust-bitcoin/rust-bitcoin


text:
Bump to secp256k1 0.20 and don't enable recovery of secp256k1 in the dependency declaration

rust-secp256k1 version 0.20 was recently released: https://github.com/rust-bitcoin/rust-secp256k1/pull/257
This PR updates rust-bitcoin to this latest version.

I think we meant to turn off the default features in our secp dep.

I think we meant to turn off the default features in our secp dep.

I'm a bit curious @apoelstra, what's the thought behind feature-gating key recovery? There aren't any more deps afaik. Is it so unstable? I'm pretty sure that LN invoices use this and it seems to be fine.

I'm a bit curious @apoelstra, what's the thought behind feature-gating key recovery? There aren't any more deps afaik. Is it so unstable? I'm pretty sure that LN invoices use this and it seems to be fine.

@sgeisler it pulls in the key recovery module from libsecp. This is morally an extra dep, and on code with a questionable patent story and no non-legacy usecases.
If we had been better about feature-gating this historically maybe LN would not have used it :(

@sgeisler it pulls in the key recovery module from libsecp. This is morally an extra dep, and on code with a questionable patent story and no non-legacy usecases.
If we had been better about feature-gating this historically maybe LN would not have used it :(

concept nack removing the feature - can you instead change this to disable the secp default features so that secp/recovery actually does something?

Is e52e48e what you had in mind?

concept nack removing the feature - can you instead change this to disable the secp default features so that secp/recovery actually does something?

Is e52e48e what you had in mind?

Side note: removing a feature from defaults is also semver breaking (although this PR is breaking anyway).

Side note: removing a feature from defaults is also semver breaking (although this PR is breaking anyway).

Yep, this looks great!
Can you also add a commit which sets `RUSTFLAGS=--cfg=

Yep, this looks great!
Can you also add a commit which sets `RUSTFLAGS=--cfg=

Actually we don't need this. See https://github.com/rust-bitcoin/rust-secp256k1/pull/269

Actually we don't need this. See https://github.com/rust-bitcoin/rust-secp256k1/pull/269

ack 8f071d1

I am afraid that commit is no longer part of this PR, e52e48e is the latest commit.

ack 8f071d1

I am afraid that commit is no longer part of this PR, e52e48e is the latest commit.

authors: Kixunil apoelstra sgeisler thomaseizinger


text:
Build fails with recent nightly

It looks like a recent nightly has renamed the internal syntax crate to rustc_ast, and the syntax_pos crate seems gone as well, though I've yet to find where it went.
Edit: Ah, syntax_pos is now rustc_span
Edit 2: Doesn't seem like a simple find/replace, other stuff has changed in rustc as well :disappointed: It might be nice to pin the toolchain to the last nightly that can be used to build.

I am aware of the breakage but currently unable to work on this, sorry.
I will get back to fixing everything in roughly two weeks, please hold on :)

The right think to do is to pin a specific nightly, and then bump that once in a while

Yeah, pinning to a specific nightly would be very helpful

What is a nightly that is known to work?

What is a nightly that is known to work?

https://github.com/rust-dev-tools/rust-semverver/pull/131

authors: elichai ibabushkin jhpratt jrmuizel jrobsonchase

repo: rust-dev-tools/rust-semverver


text:
Add free function to UsbAllocator

Allowing users to free the UsbBus from the UsbAllocator.

Yeah I'm also not sure this makes sense to allow. Can you elaborate on what the necessary use case is here?

Hello,
Thank you for your feedback. I've added this function to make the link with the PR725 (https://github.com/rp-rs/rp-hal/pull/725) from rp-hal.
The problem is that creating a UsbBus requires ownership of two peripherals (USBCTRL_REGS and USBCTRL_DPRAM) and a clock. But if you want to stop the USB, it's not possible to recover these resources, and you end up, for example, with a Partially move error (in my case from the clockManager).

authors: jnthbdn ryan-summers

repo: rust-embedded-community/usb-device


text:
Add two new helper methods to Unstructured

I've used these extensively in other test case generators. Should be generally helpful to anyone using this crate.

Ah nice I didn't know about ControlFlow, let alone that it was stable. I'll switch to using that.

repo: rust-fuzz/arbitrary


text:
Event structs need safe wrappers

Some discussion here: #21

I wonder why event struct don't have [derive(Debug)]?

Thanks for pointing this out. These structs can now just be deleted from the crate, as the sys crate provides them, but the latter are missing the Debugs as well.

repo: rust-gnome/gdk


text:
code size

why is futures so large? It's even bigger than std.
this is with lto, in release mode.
$ cargo bloat --release --crates -w -n 0 --full-fn
    Finished release [optimized] target(s) in 0.13s
   Analyzing target/release/carrier

 File  .text     Size Name
 9.6%  20.9% 606.3KiB futures
 9.2%  20.1% 584.0KiB std
...

 0.3%   0.8% 22.0KiB                futures <futures::stream::fold::Fold<S, F, Fut, T> as futures::future::Future>::poll::h3c2b7ae24026580c

 0.3%   0.6% 17.8KiB                futures <futures::future::or_else::OrElse<A, B, F> as futures::future::Future>::poll::hf6b5022846370fb2

 0.3%   0.6% 16.8KiB                futures <futures::future::into_stream::IntoStream<F> as futures::stream::Stream>::poll::h01f8c585ae211b25

All of the functions in futures are monomorphized for your particular usage of them, so any code that you wrote using futures combinators will show up as monomorphized futures code. Your cargo bloat invocation above is likely showing the size of all the futures code that is generated as a result of compiling your application, as well as any of your non-futures code that is inlined into the futures functions.

So do I understand correctly that's this cannot be fixed because it's an inherit property of the typing system?

authors: aep cramertj

repo: rust-lang-nursery/futures-rs


text:
add feature based on issue #1033

im still new in open source community please guide me :)

:umbrella: The latest upstream changes (presumably #1390) made this pull request unmergeable. Please resolve the merge conflicts.

Hi @serabiasin, thanks for the PR.
However, the issue you referenced describes adding a message to the rustup self help subcommand. I also think it should be something other than a hard-coded quote. If you have any ideas for an interesting/fun easter-egg here, feel free to comment on the issue or open a new PR.
Also, as @cyplo explained, it's a good idea to include a more descriptive title, and link to the relevant issue in the PR description.

authors: Diggsey bors serabiasin


text:
Add a flag for pretending to be a stable compiler when bisecting.

This should avoid having to patch ahash and similar crates to not do nightly feature detection and break the bisection (see https://github.com/rust-lang/rust/issues/123276#issuecomment-2075001510 for an example).
We could also do this by default and add an opt-out flag for when you want to bisect code that uses feature gates

thank youuu :pray:

authors: apiraino oli-obk

repo: rust-lang/cargo-bisect-rustc


text:
Duplicated warnings in JetBrains editors

Problem
Hi, I think I've found one case where warnings are still duplicated, or perhaps is a regression.
I'm using 1.62.1, and I see them doubled on Pycharm (up to date, with Rust plugin up to date).
To simulate, just create a new binary project, and insert any use:
use std::sync::Arc;

fn main() {
    println!("Hello, world!");
}

Then, create a quick Run Configuration with cargo check --all-targets:

Note the "1 warning" on the left, but doubled on the complete output.
Also note that Pycharm uses JSON: cargo check --color=always --message-format=json-diagnostic-rendered-ansi --all-targets
On the terminal, I can reproduce with the exact same command, but not with either cargo check --color=always --message-format=json-diagnostic-rendered-ansi or cargo check --color=always --all-targets, hence I think the problem is on the interaction between these two options.
Thanks!
Steps

create a new bin project
insert any use
in Run -> Edit Configurations, add a cargo one with command: check --all-targets and your current workdir
run it (^R on macOS)

Possible Solution(s)
No response
Notes
No response
Version
No response

Thanks for your step-by-step report!
There are two rustc invocations in your reproducible example (a test target and a bin target. check them with --verbose flag on). Both of them emit the same "unused import" diagnostics.
The deduplication behaviour was introduced since 1.55 by #9675. Cargo deduplicates rustc diagnostics message with a rudimental hash-them-all approach. For formats not primary for human to consume, such as json and json-diagnostic-rendered-ansi, Cargo would leave them as-is in order to open a door for downstream tools to program. We might consider introducing a new flag --dedup-message or so to explicitly deduplicate all kinds of messages, though I tend to avoid adding a bunch of flags onto Cargo's already complex surface. IMHO the current status is a good balance between human-readability and extensibility.
I am going to close this. If anyone gets a different thought, please leave comment below and we can revisit it. Thank you!

authors: rsalmei weihanglo

repo: rust-lang/cargo


text:
cargo clean doesn't work well from Windows

Problem
I tried to build rust project with Cargo but faced Blocking waiting for xxxxx.
So I tried to clean cargo cache as following
cargo clean
But caches are not cleared from Windows OS so I manually remove those files from System drive.
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
No response

Due to the lack of a minimal set of steps to reproduce, it's hard to help with this issue. Could you add a minimal reproducer and attach the version information via cargo -vV as well?
Besides, a related pull request just got merged https://github.com/rust-lang/cargo/pull/11442. The fix should be released in the next few days on nightly channel.

Sorry for lack information.

cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: x86_64-pc-windows-msvc
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:Schannel)
os: Windows 10.0.19044 (Windows 10 Pro N) [64-bit]

What did you want to achieve, what have you done, and what did it exactly mean by “caches are not cleared”?
We need a clear description and a reproducer of the problem to proceed. Thank you.

Dud you have any other editor opening the same project? Usually Rust Analyzer or some IDE integration will run cargo check which does block other command from running, as they are downloading and unpacking dependency source code.
If you were stuck in “Blocking waiting for xxxx” for a long while, say 3 minutes, without any IDE integration in the background, it might be a real issue.
If in that case you could try deleting ~/.cargo/registry/.package-cache. That should unlock your registry cache.

Thank you for your advice.
In addition, there are no other editor opening the same project.
Anyway, I manually deleted the above file and after than, it worked well.
Thank you.

Cargo uses LockFileEx on Windows to do file locking on .package-cache, if that makes any sense to you.
If you can reproduce it very constantly, would you be willing to provide a minimal reproducible example?

authors: emptyfist weihanglo


text:
std::env env! Cannot expand binary crate name for helper libraries

Hi everyone, my first issue. I've run into this situation a few times, where I structure my projects as libraries of a very small binary crate. This is because of the speed up that happens from this, I forget exactly what it's called. However one major disadvantage of doing this is you lose access to a lot of the env variables that binary crates have.
This is a good example, but I've had many in the past.
fn list_profiles() -> Vec<Profile> {
    let path = config_dir()
        .expect("Unsupported platfrom by `dirs` crate")
        .join(env!("CARGO_BIN_NAME").to_owned() + "/LethalCompany" + "/profiles");

    debug!("Looking for config path at {:?}", path);

    // ...

It just seems silly to me that this is a limitation of this great language. I should never have to choose to make my project slower to compile because of a silly macro not expanding correctly. Ideally this code should just work whether or not if this code is in my binary crate or a helper library.

I am not sure if I understand it correctly. You want to access CARGO_BIN_NAME inside a [lib] target, right? If yes, could you elaborate more on the reason and your use case behind?
Note that usually [lib] doesn't know about which [[bin]] will depend on it. That is, when a [lib] compiles it doesn't know what CARGO_BIN_NAME is going to expand to.

I am not sure if I understand it correctly. You want to access CARGO_BIN_NAME inside a [lib] target, right? If yes, could you elaborate more on the reason and your use case behind?
Note that usually [lib] doesn't know about which [[bin]] will depend on it. That is, when a [lib] compiles it doesn't know what CARGO_BIN_NAME is going to expand to.

Yes, because of dep parallel compilation is faster when a project is split up my project looks like this.
mod-loader v0.1.0 (/home/redhawk/code/mod-loader)
├── mod-loader_gui v0.1.0 (/home/redhawk/code/mod-loader/gui)
│   ├── dirs v5.0.1
│   │   └── dirs-sys v0.4.1
│   │       ├── libc v0.2.168
│   │       └── option-ext v0.2.0
│   ├── iced v0.13.1
...

Where I have many libraries just to keep other deps lower for faster compile times. The con of this is that env variable is no longer accessible. So I have to trade faster compile time or this variable working properly.

I got around this by just making a consist in the gui library above, but that obviously isn't ideal.

I got around this by just making a consist in the gui library above, but that obviously isn't ideal.

Is the mod-loader_tui a bin crate?
By the nature of dependency relation, I don't think lib can expand env! compile time to get a value it doesn't even know. Making env an function argument and letting bin crate pass it is what I can think of now. Or alternatively export another macro wrap env! so it will delay the expansion on call site

I got around this by just making a consist in the gui library above, but that obviously isn't ideal.

Is the mod-loader_tui a bin crate?
By the nature of dependency relation, I don't think lib can expand env! compile time to get a value it doesn't even know. Making env an function argument and letting bin crate pass it is what I can think of now. Or alternatively export another macro wrap env! so it will delay the expansion on call site

Yes, but I don't understand what you mean about creating another macro that wraps around env!.

Make your fn list_profiles() a macro so it would be expanded at callsite.
BTW, where is list_profiles defined, a dependency of mod-loader?
Having a minimal reproducible example would help explore workaround.

Make your fn list_profiles() a macro so it would be expanded at callsite.
BTW, where is list_profiles defined, a dependency of mod-loader? Having a minimal reproducible example would help explore workaround.

Here, I pushed and linked the entire project. This should be a good mre to review.

I see. Thanks for the MRE.
In this case, you're inverting the dependency relation. mod-loader_gui, as a dependency of mod-loader should know nothing about who is using it. I don't foresee anything Cargo will make any change to break the dependency relation.
I am not familiar with iced. By just looking at how iced::application works, you might want to add an &str argument to fn run(), and call mod_loader_gui::run(std::env!("CARGO_BIN_NAME")) so you bin has access to some env vars. With that you could also have more runtime configuration logic in bin, and make a generic AppConfig struct to pass into fn run(). As a result, when you test and change any config-related settings, say you want to change "/LethalCompany/profiles" path to "MyAwesomeAppCompany/profiles", you then don't need to recompile lib mod_loader_gui.

I see. Thanks for the MRE.
In this case, you're inverting the dependency relation. mod-loader_gui, as a dependency of mod-loader should know nothing about who is using it. I don't foresee anything Cargo will make any change to break the dependency relation.

No I understand this why it works like this, and I could pass it through iced. But if this is required through a deeper crate that has more common code that the gui crate depends on then I would have the same problem.

If you have a deeper crate that is under your control, you could make then accept AppConfig struct as well. This is better when you have more run time logic when you break gui to more crate, and don't need to recompile because of any compile-time env change.
If the deeper crate is from crates.io, it is unlikely to happen because [lib] crate never compile with env!("CARGO_BIN_NAME") exists. It will just fail to upload when running cargo publish.
Another scenario this is unlikely to be supported: If you have 3 [[bin]] crates depending on the same lib, you then need to compile the lib three times because each of them expands CARGO_BIN_NAME to differents name at compile time. This doesn't make the compilation faster.

That's a good point, maybe the approach isn't to expand CARGO_BIN_NAME but instead somehow embed consist into the cargo.toml that can be set at compile time for non-build scripts?

You could have package.metadata or workspace.metadata in your Cargo.toml and use whatever tool to help you inject compile time environment variable when building.
(Note that Cargo doesn't support workspace inheritance for package.metadata, as it is intended to be read and used by external tools directly)
The other way is defining your environment variable in  the [env] table in .cargo/config.toml, so they would be picked up automatically when compiling.

The most similar feature request you may be interested in is https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618. However, I don't think it is really relevant and still think a runtime config struct is better for things like for application, see some examples,

https://github.com/sharkdp/bat/blob/3e07483f7a5b54ce574485ce38792c70a675e05d/src/bin/bat/main.rs#L316-L321 — a popular CLI bat loading config and asset files in bin crate.
https://github.com/rust-lang/cargo/blob/769f622e12db0001431d8ae36d1093fb8727c5d9/src/bin/cargo/main.rs#L24 — Cargo itself reads and setup configuration in fn main().

Upon this point, I am going to close as not-planned, specifically for supporting reading bin-only env in lib crate. Please refer to other feature requests and alternatives. Thank you.


text:
add a way to share Cargo.lock information

We would like some way for a crate to depend on libservo and inherit (in some fashion) the pinned dependencies. Currently libraries have their Cargo.locks ignored, which is the correct behavior, but there are special cases where this doesn't work, and Servo's dependence on pinned versions of nightly Rust are one of these cases.
At the Mozilla All Hands this was discussed and a cargo update --lockfile was proposed.

cc @shinglyu @paulrouget

One thing which may work today (I'd have to check) is to just copy some other project's Cargo.lock into the current directory. In theory that should work just fine and the next cargo build will simply update the lock file accordingly, doing rough conservative updates where it can (and sticking to what's in the lock file if it can).
Maybe worth testing?

This is what we do as of now, and it works.
The problem is that we have to manually copy and update the lock.

Oh awesome! In that case this should be a very easy feature to implement! We'd just need to add a flag and thread it through.

How would cargo update --lockfile work?
Let's imagine I put together a rust project that depends on the libservo crate, I want the Cargo.lock of my project to use the libservo lock file. So I would do cargo update --lockfile libservo ?

Oh I'm thinking that you'd have a checkout of the Servo lockfile somewhere locally, so you'd do somethign like cargo update --start-from path/to/servo/Cargo.lock (or something like that)

Is it possible we could specify it from a dependency? So you could do cargo update --start-from servo?

I think it may be pretty tricky to get that working. Cargo doesn't even know what the crate servo is until it's halfway through resolution, and if it found at that point a Cargo.lock it'd have to abort everything and restart. From a conceptual point of view I think it'd make more sense to take a raw file, but I can see from a UI perspective it'd be nicer to take a crate on crates.io.

What about putting in a git url to the project? File system is so clumsy. I don't have particular suggestions on mechanism, but I would like it not to be point to a file deep in some tree. For starters, what if you don't have servo checked out?

Cargo doesn't even know what the crate servo is until it's halfway through resolution, and if it found at that point a Cargo.lock it'd have to abort everything and restart.

How long does it take to get to that state, for a decent-sized Cargo.toml file? If it's still (maybe even dozens of) seconds, perhaps worth considering?
I get that it's conceptually dissatisfying, but I don't think it's too hard to reason about from a user's point of view (which otherwise I'd be concerned about.)

GitHub seems to have an API to get the file [0] (not sure about other git hosting sites). Maybe we can scan for Cargo.lock in the top level directory first and then download it to the right location? We don't need to do it recursively, right? Because the top-level Cargo.lock is flattened?
[0] https://developer.github.com/v3/repos/contents/#get-contents

I wonder: is this still a requirement for libservo users?

I wonder: is this still a requirement for libservo users?

Yes.

Is this feature open for contributions?

Is this feature open for contributions?

I think this is still along the lines of a reasonable feature to contribute, but I don't think we know well enough what the feature should look like. The first thing to do here is to get a consensus about what the requirements are for a solution and then sketch what the solution might look like.

I think this is still along the lines of a reasonable feature to contribute, but I don't think we know well enough what the feature should look like. The first thing to do here is to get a consensus about what the requirements are for a solution and then sketch what the solution might look like.

See also #5332

As this looks like a duplicate of #5332 and that one has the more interesting conversations, I'm going to close this in favor of that one.  If there is a reason this should be open still, let us know!

authors: alexcrichton dwijnand epage metajack paulrouget samyak-jain shinglyu tschneidereit


text:
The --bin flag on the install subcommand doesn't work

% cargo install --force --bin svgcleaner --git https://github.com/RazrFalcon/svgcleaner
    Updating git repository `https://github.com/RazrFalcon/svgcleaner`
error: multiple packages with binaries found: docgen, files-testing, stats, svgcleaner, use_as_lib

% cargo -V
cargo 0.23.0 (61fa02415 2017-11-22)

All the packages are installed using install function in src/cargo/ops/cargo_install.rs. This function takes a krate: Vec<&str> which is created from options.arg_crate in execute function in src/bin/install.rs.
In the command,
cargo install --force --bin svgcleaner --git https://github.com/RazrFalcon/svgcleaner

options.arg_crate is an empty vector. The value of --bin flag(svgcleaner) is used to generate CompileFilter but never used. So, You are getting this error.
@RazrFalcon,
For your case, You can use cargo install --force svgcleaner --git https://github.com/RazrFalcon/svgcleaner and it'll work just fine. I'll try to send a PR to fix this before Monday.

@ishanjain28 thanks, that worked.

I've ran into the same problem:
cargo install --bin cargo-deb --git https://github.com/mmstick/cargo-deb --force
    Updating git repository `https://github.com/mmstick/cargo-deb`
error: multiple packages with binaries found: cargo-deb, example

I see from this issue that skipping --bin solves the problem. However, I wouldn't have figured it out myself, because:

I assumed cargo install foo refers to foo on crates.io only, and --git foo is a replacement for the package name, not an independent argument.
Other cargo commands use -p to select the package, but not this one.
cargo install [OPTIONS] [--] [crate]... says crate, but the error is about packages.
cargo install --help has "--bin ...          Install only the specified binary" which sounded exactly like what I wanted.

Things that could help:

Add help text to the error message suggesting adding crate name as the first arg
When --bin is specified, but not the crate/package, either search all of them, or show an error explaining specifically why --bin was ignored.
Support -p, --package to specify the package for consistency with other commands.

#8958 had some more suggestions which should be considered.

#8958 had some more suggestions which should be considered.

Just copying those suggestions here:

--bin zebrad should install the binary with that name, if there are multiple packages with binaries
--bins should install all binaries, if there are multiple packages with binaries
if there is only one binary in the workspace default-members, that binary should be installed
a multiple packages with binaries found error should give users a hint about how to specify a single crate

Just copying those suggestions here:

--bin zebrad should install the binary with that name, if there are multiple packages with binaries
--bins should install all binaries, if there are multiple packages with binaries
if there is only one binary in the workspace default-members, that binary should be installed
a multiple packages with binaries found error should give users a hint about how to specify a single crate

Here's another possible solution:
5. add a default-install key to the package section of the manifest, which acts like default-run
default-run configures the default binary for cargo run, where:

there are multiple binaries in a crate, default-run is set in the crate Cargo.toml, and cargo run is run in the crate directory, or
there are multiple binaries in a workspace, default-run is set in exactly one crate's Cargo.toml, and cargo run is run in the workspace directory

This second behaviour was a bit surprising, but I think it's actually a good thing.

Here's another possible solution:
5. add a default-install key to the package section of the manifest, which acts like default-run
default-run configures the default binary for cargo run, where:

there are multiple binaries in a crate, default-run is set in the crate Cargo.toml, and cargo run is run in the crate directory, or
there are multiple binaries in a workspace, default-run is set in exactly one crate's Cargo.toml, and cargo run is run in the workspace directory

This second behaviour was a bit surprising, but I think it's actually a good thing.

I’m new to rust but my understanding is a package (cargo.toml) can have multiple crates in the form of 1 library and/or multiple binaries.  (ref: The Book section 7.1 2nd paragraph).   But crate is also used to refer to a published package on crates.io.  And since a package can contain multiple binaries i would assume a published crate on crates.io can as well.  So there is a conflict of what this term crate means.
The cargo install command help is incorrect in that it states the default arg is a crate.   If you are installing a crate from crates.io this is true.  But if you calling install with either —path or —git option the default arg is actually a package.  I’m referring to this being a package since it is referring to the name property inside a cargo.toml file, not a published crate.  Additionally the error messages such as the “multiple package error” in the original post refer to it as a package not a crate.
cargo install —help:
--git                  Git URL to install the specified crate from
--path                Filesystem path to local crate to install
…
ARGS:
...
When using the path option, the path must point to the folder with the package.   So a package is not required, as there can only be one cargo.toml per folder.  But if provided, the package most match the name of the one in the path provided.
When using the git option, the package is required only when there are multiple packages in the repo.   It will not default to the root package.  And a path can not be provided with a git option to point to a subfolder containing a package.
I would like to do the following if its agreed as valid solution:
1.) change the help to name the default ARGS from  to <crate/package>.
2.) change the functionality of the git option to the following:
default to the only package with a binary or the root package
if there are multiple packages with binaries and none in the root folder then raise an error:
error: package is required when unable to find default package

I'm also good with any of the suggestions made in #8958.

When using the path option, the path must point to the folder with the package. So a package is not required, as there can only be one cargo.toml per folder. But if provided, the package most match the name of the one in the path provided.

I think we've used --path with a workspace containing multiple library and binary packages. But I'd have to double-check how we made it work.

authors: RazrFalcon dpurfield ehuss ishanjain28 kornelski teor2345


text:
Crate not found in integration tests if crate-type = ["cdylib"]

Problem
I am developing code that needs to work with python, which requires me to have a crate type of cdylib.  It turns out that when you follow the recommendation to use a tests directory, the code within the directory cannot find the crate, failing with an error like the following:
   Compiling cargo_issue_6659 v0.1.0 (/home/cfkaran2/Desktop/cargo_issue_6659)
     Running `rustc --edition=2018 --crate-name tester tests/tester.rs --color always --emit=dep-info,link -C debuginfo=2 --test -C metadata=0525a91fc572753f -C extra-filename=-0525a91fc572753f --out-dir /home/cfkaran2/Desktop/cargo_issue_6659/target/debug/deps -C incremental=/home/cfkaran2/Desktop/cargo_issue_6659/target/debug/incremental -L dependency=/home/cfkaran2/Desktop/cargo_issue_6659/target/debug/deps`
     Running `rustc --edition=2018 --crate-name cargo_issue_6659 src/lib.rs --color always --emit=dep-info,link -C debuginfo=2 --test -C metadata=b9fa70b838dfddae -C extra-filename=-b9fa70b838dfddae --out-dir /home/cfkaran2/Desktop/cargo_issue_6659/target/debug/deps -C incremental=/home/cfkaran2/Desktop/cargo_issue_6659/target/debug/incremental -L dependency=/home/cfkaran2/Desktop/cargo_issue_6659/target/debug/deps`
error[E0463]: can't find crate for `rustc_issue_report_cdylib`
 --> tests/tester.rs:1:1
  |
1 | extern crate rustc_issue_report_cdylib;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: Could not compile `cargo_issue_6659`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name tester tests/tester.rs --color always --emit=dep-info,link -C debuginfo=2 --test -C metadata=0525a91fc572753f -C extra-filename=-0525a91fc572753f --out-dir /home/cfkaran2/Desktop/cargo_issue_6659/target/debug/deps -C incremental=/home/cfkaran2/Desktop/cargo_issue_6659/target/debug/incremental -L dependency=/home/cfkaran2/Desktop/cargo_issue_6659/target/debug/deps` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed

Steps

Checkout the repository at https://github.com/ckaran/cargo_issue_6659.
Follow the instructions in the README.md

Possible Solution(s)
None known.
Notes
$ cargo -V -vvv
cargo 1.32.0 (8610973aa 2019-01-02)
release: 1.32.0
commit-hash: 8610973aaf48615ba7dc9a38a9a2795ba6f36a31
commit-date: 2019-01-02

$ rustc -Vv
rustc 1.32.0 (9fda7c223 2019-01-16)
binary: rustc
commit-hash: 9fda7c2237db910e41d6a712e9a2139b352e558b
commit-date: 2019-01-16
host: x86_64-unknown-linux-gnu
release: 1.32.0
LLVM version: 8.0

$ uname -a
Linux EMANE 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

You can add rlib (or lib) to the crate-type list, and it should work.  Tests can't link to the cdylib.
BTW, there's a typo in your example, tests/tester.rs should have extern crate cargo_issue_6659;.

Ah, sorry, since there is a chicken & egg problem between creating a repo that has the same name as the issue it's for, I sometimes forget to change the names.  Now fixed.
As for setting to an rlib or lib, the problem is that I'm using pyo3, which says that you must set the library type to cdylib, and not having my integration tests work was surprising to me.  If it is known that tests can't link to cdylib type libraries, it may be worth updating cargo's (or maybe rustc's) documentation to reflect this fact.

Yea, the documentation for crate-types could definitely be improved in general.
Feel free to leave more comments here if you run into any other issues. Otherwise I'll just leave this open as a documentation issue.

There are some potential issues with just adding `lib' to get it to work. See: https://github.com/rust-lang/cargo/issues/4881.

You can add rlib (or lib) to the crate-type list, and it should work. Tests can't link to the cdylib.

I would like to add that it doesn't work with no_std because cdylib target needs panic_handler, but lib doesn't and it results in duplicate symbol when building tests.

You can add rlib (or lib) to the crate-type list, and it should work. Tests can't link to the cdylib.
BTW, there's a typo in your example, tests/tester.rs should have extern crate cargo_issue_6659;.

@ehuss, is adding a second crate-type (such as rlib) still the preferred way to solve this?
It works, but it makes cargo build last longer since it has to generate two libraries...

I don't think there is any other way to do it right now.

authors: Shatur ckaran ehuss gzurl vjpr


text:
cargo fmt has --all option but not --workspace like other commands

Problem
The --all option for cargo commands was soft-deprecated in favor of the --workspace option, which does the same thing. It seems like this same thing was not done for cargo fmt, which still only has --all as an option to run it on all workspace packages.
Steps

run cargo fmt --workspace
observe error: Found argument '--workspace' which wasn't expected, or isn't valid in this context

Possible Solution(s)
Introduce --workspace flag for cargo fmt.
Notes
Latest version I currently have installed is cargo 1.52.0-nightly (90691f2bf 2021-03-16), I can't update right now; sorry if this already got fixed.

cargo-fmt is bundled with rustfmt as a thin cargo subcommand. Maybe we can move this issue there.
https://github.com/rust-lang/rustfmt/blob/a9876e8/src/cargo-fmt/main.rs#L58-L60

Moving the issue requires somebody with high enough privileges on both repos, right? Or do you just mean close this issue and open a new one on rustfmt?

I have no privileges neither 🙂. The latter is much more easier for us.

Turns out there were already several issues about it, and they got closed because cargo fmt already affects the entire workspace without any options. --all is for path-based deps outside the workspace, which seems like a weird feature but whatever.
For more info, see https://github.com/rust-lang/rustfmt/issues/3911.

authors: jplatte weihanglo


text:
Unable to fetch dependencies with stable-x86_64-pc-windows-gnu

cargo update and everything else works fine if I'm using the stable-x86_64-pc-windows-msvc toolchain. However, if I'm using stable-x86_64-pc-windows-gnu, Rust suddenly can't fetch dependencies. (Because this issue depends on the toolchain, I assume it's not a problem with cargo).
Output of cargo update
    Updating crates.io index
warning: spurious network error (2 tries remaining): failed to open request: Das Handle ist ungültig.
; class=Os (2)
warning: spurious network error (1 tries remaining): failed to open request: Das Handle ist ungültig.
; class=Os (2)
error: failed to get `gtk4` as a dependency of package `relm4-components v0.1.0 (C:\Users\ERHAAAR\git\relm4\relm4-components)`

Caused by:
  failed to load source for dependency `gtk4`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to open request: Das Handle ist ungültig.
  ; class=Os (2)

"Das Handle ist ungültig" is German for "the handle is invalid".

Meta

rustc --version --verbose:
rustc 1.55.0 (c8dfcfe04 2021-09-06)
binary: rustc
commit-hash: c8dfcfe046a7680554bf4eb612bad840e7631c4b
commit-date: 2021-09-06
host: x86_64-pc-windows-msvc
release: 1.55.0
LLVM version: 12.0.1

and
rustc 1.55.0 (c8dfcfe04 2021-09-06)
binary: rustc
commit-hash: c8dfcfe046a7680554bf4eb612bad840e7631c4b
commit-date: 2021-09-06
host: x86_64-pc-windows-gnu
release: 1.55.0
LLVM version: 12.0.1

Shell log

path\to\project(main)> rustup default stable-x86_64-pc-windows-msvc
info: using existing install for 'stable-x86_64-pc-windows-msvc'
info: default toolchain set to 'stable-x86_64-pc-windows-msvc'

  stable-x86_64-pc-windows-msvc unchanged - rustc 1.55.0 (c8dfcfe04 2021-09-06)

path\to\project(main)> cargo update
    Updating crates.io index
    Updating serde_json v1.0.67 -> v1.0.68

path\to\project(main)> rustup default stable-x86_64-pc-windows-gnu
info: using existing install for 'stable-x86_64-pc-windows-gnu'
info: default toolchain set to 'stable-x86_64-pc-windows-gnu'

  stable-x86_64-pc-windows-gnu unchanged - rustc 1.55.0 (c8dfcfe04 2021-09-06)

path\to\project(main)> cargo update
    Updating crates.io index
warning: spurious network error (2 tries remaining): failed to open request: Das Handle ist ungültig.
; class=Os (2)
warning: spurious network error (1 tries remaining): failed to open request: Das Handle ist ungültig.
; class=Os (2)
error: failed to get `gtk4` as a dependency of package `relm4-components v0.1.0 (C:\Users\ERHAAAR\git\relm4\relm4-components)`

Caused by:
  failed to load source for dependency `gtk4`

Caused by:
  Unable to update registry `crates-io`

Caused by:
  failed to fetch `https://github.com/rust-lang/crates.io-index`

Caused by:
  failed to open request: Das Handle ist ungültig.
  ; class=Os (2)
path\to\project(main)>

Thanks for the report!  I have transferred this to the cargo repository since it is almost certainly an issue with libgit2 in cargo.
Can you provide a little more information, such as the exact version of Windows you are using?  Do you have a proxy configured? Is there anything else possibly unusual about your setup? Which shell are you using?  (Does this happen under cmd or Powershell?)

OS
Edition: Windows 10 Enterprise
Version: 20H2
Build: 19042.1165
Shell
I've tried cmd, PowerShell and Nu Shell. All behave indentical.
Possible unusual configurations
Most settings are managed by my company and it's likely that they use rather strict network configurations. Yet I don't have a problem with fetching https://github.com/rust-lang/crates.io-index using curl. Even git clone https://github.com/rust-lang/crates.io-index works fine.

Hm, yea, this is likely some strange interaction of the gnu build and your system.  I'm at a loss on how that could happen, though, since this is C code, and looks pretty straightforward.
One thing I forgot to ask, can you also try with the latest nightly release?
As a workaround, you can try the net.git-fetch-with-cli config option, which will use the git command-line client.

Nightly didn't help, but with net.git-fetch-with-cli set to true cargo is able to download the index. Now I've got this error when using cargo run:
warning: spurious network error (2 tries remaining): [6] Couldn't resolve host name (getaddrinfo() thread failed to start)
warning: spurious network error (1 tries remaining): [6] Couldn't resolve host name (getaddrinfo() thread failed to start)
error: failed to download from `https://crates.io/api/v1/crates/winapi-x86_64-pc-windows-gnu/0.4.0/download`

Caused by:
  [6] Couldn't resolve host name (getaddrinfo() thread failed to start)

It works now for some reason. Basically, I've just rebooted my PC. I don't know what's the difference though as I rebooted several times before without a solving the issue.
The only difference I can think was that I installed wget and a certificate from Zscaler to fix an issue with MSYS2. That together with net.git-fetch-with-cli seems to have solved the issue... but to be honest I'm still puzzled why this happened.

Update: It's broken again. Again, there's nothing notable I did change on my system. I think it could be connected to another issue with curl 7.79.0 (which is the version I have installed with MSYS2): https://github.com/curl/curl/issues/7730#issuecomment-920687382
At least I hope the new curl version fixes this issue as well...

The issue seems to be fixed for some reason. I think part of the problem was a ZScaler proxy in the network of my company as other package managers such as pip and npm had problems as well.

@AaronErhardt Hey, Im facing the same issue now, can u help me to fix this issue? Im struggling from 2 days like a hell.!

authors: AaronErhardt Rock0007 ehuss


text:
WIP: try making cargo tree's Graph from a UnitGraph

What does this PR try to resolve?
This is an attempt at implementing step 1 from https://github.com/rust-lang/cargo/issues/9599#issuecomment-1312587071 - a function which converts from a UnitGraph to a cargo::ops::tree::graph::Graph
This would make it easier to find edge cases where cargo tree disagrees with cargo build.
How should we test and review this PR?
TODO (this PR is currently WIP)
Demonstrate how you test this change and guide reviewers through your PR.
With a smooth review process, a pull request usually gets reviewed quicker.
If you don't know how to write and run your tests, please read the guide:
https://doc.crates.io/contrib/tests
Additional information

[x] minimal test

[ ] think a bit harder about how/whether to expose this code (currently hidden behind a CARGO_TREE_FROM_UNIT_GRAPH environment variable for simplicity)

[x] actually implement Graph::from_bcx() (to create a Graph from a UnitGraph)
[ ] run everything in the current test suite using Graph::from_bcx() rather than graph::build() and fix any discrepancies
[ ] get feedback on whether the team likes this approach (if not then that's fine - I need to build something like this for cargo quickbuild anyway, so it won't be wasted effort).

Progress report for today:
my simple_from_unit_graph test now passes (so top-level build-deps and dev-deps are now supported)
If I apply this patch:
diff --git a/crates/cargo-test-support/src/lib.rs b/crates/cargo-test-support/src/lib.rs
index 4ce0162bf..513d4f4f8 100644
--- a/crates/cargo-test-support/src/lib.rs
+++ b/crates/cargo-test-support/src/lib.rs
@@ -414,6 +414,7 @@ impl Project {
         let mut execs = self.process(&cargo);
         if let Some(ref mut p) = execs.process_builder {
             p.env("CARGO", cargo);
+            p.env("CARGO_TREE_FROM_UNIT_GRAPH", "1");
             p.arg_line(cmd);
         }
         execs

then it causes failures from the following 25 tests:
    features2::minimal_download
    features2::tree_all
    features::same_name
    features_namespaced::tree
    features_namespaced::tree_no_implicit
    tree::cyclic_features
    tree::dep_kinds
    tree::depth_limit
    tree::dev_dep_cycle_with_feature
    tree::dev_dep_cycle_with_feature_nested
    tree::dev_dep_feature
    tree::duplicates
    tree::features
    tree::format
    tree::host_dep_feature
    tree::invert_with_build_dep
    tree::prune
    tree::virtual_workspace
    tree::workspace_features_are_local
    tree_graph_features::dep_feature_various
    tree_graph_features::features_enables_inactive_target
    tree_graph_features::graph_features_ws_interdependent
    tree_graph_features::slash_feature_name
    weak_dep_features::tree
    weak_dep_features::weak_namespaced

Something to work on tomorrow.

Progress report for the weekend:
Apart from the tests that pass --target=all, I only have about 3 failing tests. I can probably chip away at these, but I'm not sure what to do about --target=all.
Questions:
a) Do you think that it's worth trying to teach cargo::core::compiler::unit_dependencies about --target=all or is it possible to deprecate it?
b) cargo tree -p $package seems to mean something slightly different from cargo build -p $package (cargo tree seems to use the whole workspace for calculating the dep tree, and then print a filtered tree by using $package as the root). Do I have this right, or do I just have bugs in my code/understanding? I'm tempted to make a cargo build --stop-after-package $package that does the same thing as cargo tree -p $package. Does this seem like a reasonable idea?
c) at the moment, I'm only adding complexity (because the existing code is useful as an oracle), but in theory this approach would let us remove a bunch of complexity by removing the existing Graph-building machinery. Is this a thing we want to do? Should I have a stab at it, and see what my diffstat looks like with the old code removed?
d) is this PR fleshed-out enough to determine whether we even want to go down this route? Is there anything else that would make it easier to make that decision?
I doubt that this PR will be in a reasonable state to merge before I get swallowed up by my new job, but it will hopefully serve as a reference of what is possible and what is easier/harder if you go down this route. I will therefore close this PR on Tuesday, whatever state it's in. I will leave the branch around in case someone wants to use it as inspiration.

Haven't really looked deeply into your change, but I do appreciate what you've done. The amount of code added so far are less than I expected. It is indeed a great exploration. Thank you!

a) Do you think that it's worth trying to teach cargo::core::compiler::unit_dependencies about --target=all or is it possible to deprecate it?

I don't think so, at least for the latter. They have different meanings. We already have ForceAllTargets to disable target platform filters. Maybe we can look into that without too many churns on the other parts of code?

b) cargo tree -p $package seems to mean something slightly different from cargo build -p $package (cargo tree seems to use the whole workspace for calculating the dep tree, and then print a filtered tree by using $package as the root). Do I have this right, or do I just have bugs in my code/understanding? I'm tempted to make a cargo build --stop-after-package $package that does the same thing as cargo tree -p $package. Does this seem like a reasonable idea?

Package filtering process happens here, so ws_resolve should resolve what is passed incargo tree -p. Did you find any abnormal behaviour? For --stop-after-package, I am not sure what it is used for, though usually Cargo team takes it serious when adding a new flag.

c) at the moment, I'm only adding complexity (because the existing code is useful as an oracle), but in theory this approach would let us remove a bunch of complexity by removing the existing Graph-building machinery. Is this a thing we want to do? Should I have a stab at it, and see what my diffstat looks like with the old code removed?

Go ahead, or put it into another module, so we can have a clear view of the diff :)

d) is this PR fleshed-out enough to determine whether we even want to go down this route? Is there anything else that would make it easier to make that decision?

Even the final result reduces the complexity, I'll still ask about the extensibility, such as handling an issue like https://github.com/rust-lang/cargo/issues/10593#issuecomment-1317759526. I think ehuss has some concerns on sharing code, so having ehuss taking a look is better once it is in a relatively good shape.

Haven't really looked deeply into your change, but I do appreciate what you've done. The amount of code added so far are less than I expected. It is indeed a great exploration. Thank you!

a) Do you think that it's worth trying to teach cargo::core::compiler::unit_dependencies about --target=all or is it possible to deprecate it?

I don't think so, at least for the latter. They have different meanings. We already have ForceAllTargets to disable target platform filters. Maybe we can look into that without too many churns on the other parts of code?

Ah. I think I might have misunderstood that part of the code. For some reason, I thought ForceAllTargets was about the --all-targets flag (equivalent to specifying --lib --bins --tests --benches --examples). Thanks. I'll have a go at using that machinery.

b) cargo tree -p $package seems to mean something slightly different from cargo build -p $package (cargo tree seems to use the whole workspace for calculating the dep tree, and then print a filtered tree by using $package as the root). Do I have this right, or do I just have bugs in my code/understanding? I'm tempted to make a cargo build --stop-after-package $package that does the same thing as cargo tree -p $package. Does this seem like a reasonable idea?

Package filtering process happens here, so ws_resolve should resolve what is passed incargo tree -p. Did you find any abnormal behaviour? For --stop-after-package, I am not sure what it is used for, though usually Cargo team takes it serious when adding a new flag.

I think this may be due to bugs in my understanding again. I was under the impression that it was possible to ask cargo tree to "show me how cargo would build this workspace, but only show me things below $package" in the tree.

[ ] dig into the the tests that I chalked up to this discrepancy and see if I can resolve them.

c) at the moment, I'm only adding complexity (because the existing code is useful as an oracle), but in theory this approach would let us remove a bunch of complexity by removing the existing Graph-building machinery. Is this a thing we want to do? Should I have a stab at it, and see what my diffstat looks like with the old code removed?

Go ahead, or put it into another module, so we can have a clear view of the diff :)

I will do the "another module" thing first, and then do "deleting the old code" as a separate PR against my own fork if I get time.

d) is this PR fleshed-out enough to determine whether we even want to go down this route? Is there anything else that would make it easier to make that decision?

Even the final result reduces the complexity, I'll still ask about the extensibility, such as handling an issue like #10593 (comment). I think ehuss has some concerns on sharing code, so having ehuss taking a look is better once it is in a relatively good shape.

I suppose this is a philosophical thing: is cargo tree a teaching/exploring tool (in which case, clarity and expressiveness might be more important) or is it a debugging tool (in which case correctness might be more important).
Fundamentally, cargo tree does not work on the Unit level, and there will always be discrepancies between it and cargo build. This is something that I didn't appreciate when I started this project. It will certainly help when I next have time to work on cargo quickbuild.

I've reached the end of my timebox for this.
I briefly tried propagating ForceAllTargets, but I ran out of time before I got any --target=all tests passing. I also didn't get time to do any cleaning up, so it's still a mess. Sorry.
I still think that this is a promising idea.
Advantages:

The Graph building code in graph::from_bcx() does not need to be recursive anymore. This means that it is easier to follow, and doesn't have to worry about infinite loops.

It does a pass to add all of the Package nodes, then a pass to add all of the links (which may add Feature nodes if feature edges are enabled)
The pass to add cli features at the end is currently still the old recursive add_internal_features() code, but it might be possible to flatten that out too (not sure).

We now match the behaviour of UnitGraph - build-dependencies are ignored if there is no build.rs unit.

As an aside, I wonder if we could use a similar approach to support displaying artifact dependencies and build-scripts. You would want a -e units or something, and a Node::Unit variant, a bit like how Node::Feature works (I have not thought about how it would interact with -e features). Going via UnitGraph for that feature would make things a lot easier, so if you are already going via UnitGraph for everything else, you might have an advantage.
Risks:

I didn't have time to look into the --target=all tests, and a few other things, so there are 6 failing tests. Any one of them might be difficult enough to solve that it kills this idea dead.
we still rely on calling out to the resolver to work out why each of the UnitDeps are there, because they don't contain enough information on their own. This could be considered to be a bad thing, but also may be considered to be a good thing, if we need extension points.
I'm still using a few of the old builder functions, like add_internal_features(), and they might be correcting for sloppiness in how I'm building the tree. It might be valuable to rewrite them in terms of UnitGraph to make sure we're not missing anything.
Please don't let my prototype-quality code convince you that it's a bad idea: it is my first attempt at hacking on cargo internals, so it's a bit of a mess.

Thanks for all of your support in this exploration. Hopefully it contains some useful ideas. Even if it doesn't, I have learned a lot.
Thanks again.
David.

authors: alsuren weihanglo


text:
Update semver checks for 1.67

The diagnostic message for one of the SemVer checks needs to be updated for 1.67.

⚠ CAUTION ⚠ This should not be merged until after the stable release tomorrow.

Oops, I think I got confused. This isn't needed until 6 weeks from now. I suppose I'll leave it here until then.

Close in favor of #11817.

authors: ehuss weihanglo


text:
Include path to manifest in workspace warnings.

It can be confusing because almost all of the warnings give no indication which package issued the warning.
Closes #6168

@bors: r+

:pushpin: Commit 6ad77940272bfd34074411f064a8aab0ff94e300 has been approved by alexcrichton

:hourglass: Testing commit 6ad77940272bfd34074411f064a8aab0ff94e300 with merge 1f730be122aef94ef15284975c6fd56e6ba41d3f...

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

authors: alexcrichton bors ehuss


text:
[Question] How do I get information back from CMake after configuring a library?

I have a CMake library that conditionally adds link time dependencies based on the output of a check_cxx_source_compiles command.  That's all fine when building a CMake project, but when building a Cargo library I need to add a line like this into build.rs:
println!("cargo:rustc-link-lib=framework=XXX");

To mimic the behaviour of the CMake library, I will need to somehow retrieve the value of the variable that is set by the check_cxx_source_compiles command.  That might not be possible directly, but it should be possible determine the value by reading (in build.rs) the output of the CMake configure command.
Is there a way to go about doing that?  Or more generally, does cmake-rs have a good way to get information back from CMake after the CMake library is configured?

Looks like this is the same problem I ran into here:
https://stackoverflow.com/questions/74851275/rust-cargo-cmake-integration-with-c-library-dependencies
As far as I can tell, this crate is currently only driving the configuration/building process, so it does not have access to any information like that.
I guess in the future, one can imagine parsing the cmake install-config (e.g., https://gitlab.kitware.com/cmake/community/-/wikis/doc/tutorials/How-to-create-a-ProjectConfig.cmake-file) but that is probably a massive undertaking

authors: Xaldew btzy

repo: rust-lang/cmake-rs


text:
Crate succeeds to build, but some modules are unreachable

Crate name
rmatrix_ks
Build failure link
https://docs.rs/crate/rmatrix_ks/0.3.7/builds/1313071
Additional details
I used cargo doc --all-features to compile the document locally, and everything was displayed normally.

However, when I uploaded it to docs.rs, I found that some module pages were not displayed, specifically the serde module.

I don't know why. My configuration is as follows:
[package.metadata.doc.rs]
features = ["rand_mat", "rayon_mat", "serde_mat"]
all-features = true
no-default-features = true

serde module has config #![cfg(serde_mat)]

I initially thought it was caused by doc_cfg, but when I removed doc_cfg and tried to solve this, nothing changed.

I'm not sure how I didn't see this in the beginning.
I think this is just a typo.
The section has the wrong name, you used [package.metadata.doc.rs], correct is [package.metadata.docs.rs].

See also https://docs.rs/about/builds for more details

I'll close this issue because I'm quite sure this is the problem.
Feel free to comment / reopen if not, then I'll dig into it again.

I'm not sure how I didn't see this in the beginning.
I think this is just a typo.
The section has the wrong name, you used [package.metadata.doc.rs], correct is [package.metadata.docs.rs].

Thank you so much, I didn't even realize this typo myself.

authors: kands-code syphar


text:
Incorrect "no builds" badge shown for complex version string

We have a crate that has a version string 0.1.0+4.1, when linking to the docs.rs badge for it it shows up as "no build" when using this string: https://docs.rs/physx-sys/badge.svg.

Although the actual link works and goes to the correct built documentation for that specific crate https://docs.rs/physx-sys/0.1.0+4.1/physx_sys/.
Looks like there may be some specific badge picture generation error for complex version strings, maybe it tries to find version just 0.1.0, which doesn't exist, in the picture selection instead of the full 0.1.0+4.1. While the page link itself uses the correct one.
Cargo itself when one references a crate with such a more complex version string does only use the first semver portion (MAJOR.MINOR.PATCH) and gives a warning if one specifies the rest (which it ignores).

Just poking around a bit on this one - could it be related to the + symbol being incorrectly encoded around here?

Reproducible crate: https://docs.rs/zstd/0.5.1+zstd.1.4.4/zstd/
BTW @repi  the build failure for your 2.0 versions is because cmake is trying to write to the source directory, we added more sandboxing in #407. If you write to the target directory instead (cargo sets OUT_DIR), it should work.

A secondary problem: if any version is not a valid semver range, all versions are marked as being invalid: https://github.com/rust-lang/docs.rs/blob/master/src/web/mod.rs#L267

@arirawr it turns out this isn't a problem in match_version, surprisingly. Somehow, when you go to /zstd/badge.svg?version=0.5.1+zstd.1.4.4 the version that gets passed to match_version is 0.5.1 zstd.1.4.4 (with a space).

I think it might be a bug in params? I'm giving up for now.

Relevant code: https://github.com/rust-lang/docs.rs/blob/master/src/web/rustdoc.rs#L331

authors: arirawr jyn514 repi


text:
Fix handling of URLs with port in credential.helper

Credentials stored by Git for the URL https://example.com:3000/foo/bar use
host=example.com:3000. A CredentialHelper object for the same URL currently
queries the credential helper with host=example.com and thus can't access the
stored credentials.

Thanks!

authors: alexcrichton sckfranke


text:
uclibc: fix O_TMPFILE value, hide some unused fields to fix libc-test

This was a bit of a yak-shave.
First, O_TMPFILE was wrong because 020000000 is decimal, not octal.  :facepalm:   This was, of course, causing all sorts of things to be horrible.
That led me to switch to a newer toolchain which actually defined O_TMPFILE, so that the libc tests pass on armv7-unknown-linux-uclibceabihf.
That revealed that certain field names had changed since the last time I ran the libc tests on this architecture, which revealed that some struct fields (e.g. __unused) were being marked as pub where all other architectures left them as private.
So, this patch might seem somewhat sprawling, but without all of these changes it's not possible to run libc-test!
To test:

get https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2
unpack somewhere, and call that $TOOLCHAIN

cd libc-test

PATH=$TOOLCHAIN/bin:$PATH \
  CC_armv7_unknown_linux_uclibc=armv7-buildroot-linux-uclibc-gcc \
  CARGO_TARGET_ARMV7_UNKNOWN_LINUX_UCLIBCEABIHF_LINKER=armv7-buildroot-linux-uclibc-gcc \
  CARGO_TARGET_ARMV7_UNKNOWN_LINUX_UCLIBCEABIHF_RUNNER="qemu-arm -L $TOOLCHAIN/arm-buildroot-linux-uclibcgnueabihf/sysroot/" \
  cargo +nightly test --target armv7-unknown-linux-uclibceabihf -Zbuild-std=core,std

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

(ref https://github.com/nix-rust/nix/pull/1603)

@Amanieu I would like to get CI 'libc-test` working for this target, but seeing as it's Tier-3 at the moment, I'm not sure if that's a change which would be accepted.  Do you have any opinions or advice there?

I'm OK with adding uclibc to CI even though it is tier 3. It seems sorely needed consider the issues found in this PR :)
Could you add it in this PR?

Actually I'm going to merge this as it is so that it makes the next libc release. You can add uclibc to CI in a separate PR.
@bors r+

:pushpin: Commit 0fcf5b32c5abe9d69bcb8166457e2ae24addfc8c has been approved by Amanieu

:hourglass: Testing commit 0fcf5b32c5abe9d69bcb8166457e2ae24addfc8c with merge cf597c2d6f60ea85178fd5851c9d7ba223bf1e17...

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

authors: Amanieu bors rust-highfive skrap

repo: rust-lang/libc


text:
Add support for panics on Windows

Several tests are currently disabled on Windows, due to Miri's lack of support for a number of Windows API functions:

GetProcAddress
GetModuleHandleW
AcquireSRWLockShared

Implementing GetProcAddress and GetModuleHandleW will require us to extend our current handling of dlsym to support Windows. This is currently blocked on https://github.com/rust-lang/miri/pull/1225 ~~https://github.com/rust-lang/rust/pull/66470~~ ~~https://github.com/rust-lang/rust/pull/69326~~, since we need the ability to read wide strings.

The alternative (which avoids having to implement read-write locks for Windows) is to patch libstd so that RwLock, like Mutex, falls back to EnterCriticalSection when SRWLock is not available.
That would also have the added benefit of making panicking work again on Windows XP.

At the very least, it'd be great to have a better, more appropriate error message than "thread panicked while processing panic. aborting.". I thought I had a very different problem when I saw that message under miri, when actually everything was working properly, it's just that on Windows miri does not implement panics yet.
I was trying to use miri to implement leak check tests in the face of panics, but because of this I had to fall back to the (probably better, because it works for cargo test) approach of tracking new/drop calls manually.

If you have any suggestions for how we could get a better error, I'm all ears. The error is emitted by libstd, not by Miri.
Once https://github.com/rust-lang/rust/pull/69729 lands, you should be able to use --target x86_64-unknown-linux-gnu on Windows, and then panics should work fine.

@CAD97 but in your repo, doesn't it run Miri on ubuntu-latest? How is this Windows-only issue a problem?

Yeah, CI is running on Ubuntu, but I also am running tests locally, which is a lot lower latency 😝
I'm not exactly certain how best to get a better error message for Windows targets. Didn't miri used to say something along the lines of "panicking not supported"? I'd expect that message still on the Windows target, rather than for the panic to start but than starting the panic but then failing to handle it.

Ah, good idea... see https://github.com/rust-lang/miri/pull/1241. Testing would be welcome, as I don't have a Windows machine to try this on. :)

With https://github.com/rust-lang/miri/pull/1249, another alternative for Windows users is to pass --target x86_64-unknown-linux-gnu -- cross-interpretation like that should work fine now, and unwinding is supported for Linux targets.

Solving this by implemented the "shared RW lock" Windows methods would likely also solve https://github.com/rust-lang/miri/issues/1302.

@CAD97

I was trying to use miri to implement leak check tests in the face of panics

Note that Miri currently does not check for leaks on Windows, see https://github.com/rust-lang/miri/issues/1302.

repo: rust-lang/miri


text:
avoid strerror_r failure on unknown errnum

This is an informative function anyway, so as fallback just return a string with the raw errnum. Avoids panics / interpreter aborts in std on unknown errnum in from_raw_os_error.

@bors r+

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

:hourglass: Testing commit fa8164c1d1f4f5abd31237ab29d76fa7d37e1364 with merge 47f1eea327d1b2a8097bf7d4b91f1d4c6dd076a0...

:broken_heart: Test failed - checks-actions

@bors r+

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

:hourglass: Testing commit 6d14a5e2a7c17f1fec43c319cc9317ded44701ea with merge 74c5f1b468f000a9a94c6f72d08006f71d5d661e...

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

authors: RalfJung bors


text:
Underlying slice access to avoid intermediate buffers

Hi,
I've noticed the aligned slice copy methods essentially internally cast the structure to a slice. I'd find it very useful for processing file data in a Simd structure to have read/write access to this slice, to avoid an intermediate copy.
I currently have to do this:
let mut buffer = [0u8; 64];
...
file.read(&mut buffer)?;
let data = u8x64::from_slice_aligned(&buffer);
...

I'd like to do this:
let mut data = u8x64::splat(0);
...
file.read(data.as_slice_mut())?;
...

Is there any reason you couldn't do something like this (although maybe without the unsafe code by using knowledge of the underlying data structures):
impl Simd<S> {
    fn as_slice(&self) -> &S {
        unsafe { &*(self as *const Self as *const S) }
    }
    fn as_slice_mut(&mut self) -> &mut S {
        unsafe { &mut *(self as *mut Self as *mut S) }
    }
}

If you use bytemuck with the nightly_portable_simd feature then you can do this fairly easily.
In general, special transmutation related things are not as likely with the portable simd api so that there's not duplication with the eventual APIs from the safe-transmute project.

Thanks @Lokathor, I can also use code similar to what I posted. I was thinking this might be something very useful to integrate into the main package as it seems fairly core.

main package as it seems fairly core

https://github.com/rust-lang/portable-simd/issues/170

@burrbull thanks, I’ll look into that and raise there if needed.
Sorry, I vaguely remembered plans for something more official, but couldn’t find it when googling and searching crates.io.

Oh, sorry, I didn't even realize that this is the packed_simd repo I just assumed it was the portable-simd repo XD

authors: Lokathor burrbull therealbnut


text:
Aarch64 macOS trap on vld1q

When building a more complex app with NEON intrinsics, I get a runtime trap on vld1q_s32. I did some searching and could not find a tracking issue upstream for this in Cranelift. I additionally tried RUSTFLAGS= "target-feature=-neon" to no avail.
trap at Instance { def: Item(DefId(2:41824 ~ core[8ff7]::core_arch::arm_shared::neon::generated::vld1q_s32_x2)), args: [] } (_ZN4core9core_arch10arm_shared4neon9generated12vld1q_s32_x217hbeca48d3375ec01eE): llvm.aarch64.neon.ld1x2.v4i32.p0i32

While I understand it is not a priority, if I could be pointed to where this set of instructions is being tracked in cranelift I would much appreciate it.

The general tracking issue for this is https://github.com/rust-lang/rustc_codegen_cranelift/issues/171, but I keep issues for individual intrinsics open too. By the way do you know which crate uses this intrinsic? You should be able to get a backtrace with a debugger.

    frame #0: 0x00000001071f2808 game`_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write..write_fmt..SpecWriteFmt$GT$::spec_write_fmt::h6a3c139bdf9273a6 at mod.rs:444:32
   thread #12, name = 'Compute Task Pool (4)', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
     frame #0: 0x00000001071f2808 game`_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write..write_fmt..SpecWriteFmt$GT$::spec_write_fmt::h6a3c139bdf9273a6 at mod.rs:444:32
 Target 0: stopped.

With opt-level=0 on LLVM, I do not see that intrinsic used. It seems to get emitted regardless of optimization settings on Cranelift.
I was able to trace this trap back to the crate, zune-jpeg. It has a default feature for neon that I can disable until neon support is more mature.
Thanks again for all your help!