text:
Fails to install gem on Windows 11

Operating System
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22621 N/A Build 22621

Ruby +DevKit
ruby:
  path: C:/tools/ruby30
  version: 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x64-mingw32]
  platform: x64-mingw32
  cc: gcc.exe (Rev2, Built by MSYS2 project) 11.2.0
ruby_installer:
  package_version: 3.0.3-1
  git_commit: 981867a
msys2:
  path: c:\msys64
sh: GNU bash, version 5.2.9(1)-release (x86_64-pc-msys)
os: Microsoft Windows [Version 10.0.22621.2861]

Prism fails to install when building native extentions:
> gem install prism
Temporarily enhancing PATH for MSYS/MINGW...
Building native extensions. This could take a while...
ERROR:  Error installing prism:
        ERROR: Failed to build gem native extension.

    current directory: C:/tools/ruby30/lib/ruby/gems/3.0.0/gems/prism-0.19.0/ext/prism
C:/tools/ruby30/bin/ruby.exe -I C:/tools/ruby30/lib/ruby/3.0.0 -r ./siteconf20231221-29380-17fq2o.rb extconf.rb
checking for prism.h in C:/tools/ruby30/lib/ruby/gems/3.0.0/gems/prism-0.19.0/include... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=C:/tools/ruby30/bin/$(RUBY_BASE_NAME)
C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:471:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:613:in `try_cpp'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:1177:in `block in find_header'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:971:in `block in checking_for'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:361:in `block (2 levels) in postpone'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:331:in `open'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:361:in `block in postpone'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:331:in `open'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:357:in `postpone'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:970:in `checking_for'
        from C:/tools/ruby30/lib/ruby/3.0.0/mkmf.rb:1176:in `find_header'
        from extconf.rb:62:in `<main>'

To see why this extension failed to compile, please check the mkmf.log which can be found here:

  C:/tools/ruby30/lib/ruby/gems/3.0.0/extensions/x64-mingw32/3.0.0/prism-0.19.0/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in C:/tools/ruby30/lib/ruby/gems/3.0.0/gems/prism-0.19.0 for inspection.
Results logged to C:/tools/ruby30/lib/ruby/gems/3.0.0/extensions/x64-mingw32/3.0.0/prism-0.19.0/gem_make.out

Content of C:/tools/ruby30/lib/ruby/gems/3.0.0/extensions/x64-mingw32/3.0.0/prism-0.19.0/mkmf.log:
"gcc -o conftest.exe -IC:/tools/ruby30/include/ruby-3.0.0/x64-mingw32 -IC:/tools/ruby30/include/ruby-3.0.0/ruby/backward -IC:/tools/ruby30/include/ruby-3.0.0 -I. -D__USE_MINGW_ANSI_STDIO=1 -DFD_SETSIZE=2048 -D_WIN32_WINNT=0x0600 -D__MINGW_USE_VC2005_COMPAT -D_FILE_OFFSET_BITS=64  -O3 -fno-fast-math -fstack-protector-strong conftest.c  -L. -LC:/tools/ruby30/lib -L. -pipe -s -fstack-protector-strong
-m64   -lx64-msvcrt-ruby300  -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi  "
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: #include <winsock2.h>
4: #include <windows.h>
5: int main(int argc, char **argv)
6: {
7:   return !!argv[argc];
8: }
/* end */

Note that upon switching to ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x64-mingw-ucrt] , gem was successfully installed.

It's saying You have to install development tools first. on the first one, can you try installing other C extension gems on that version of Ruby to see if it is able to install? I'm trying to narrow down if this is just prism or if it's the installation of that version of Ruby on your machine.

I could install prism with latest version of RubyInstaller2 and Windows 11 Pro.
PS C:\Users\hsbt> ruby -v
ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x64-mingw-ucrt]
PS C:\Users\hsbt> gem -v
3.5.3
PS C:\Users\hsbt> gem i prism
Fetching prism-0.19.0.gem
Temporarily enhancing PATH for MSYS/MINGW...
Building native extensions. This could take a while...
Successfully installed prism-0.19.0
Parsing documentation for prism-0.19.0
Installing ri documentation for prism-0.19.0
Done installing documentation for prism after 31 seconds
1 gem installed

Thanks @hsbt - @iuliu-burtoiu we've not been able to reproduce this, so I'm going to close this for now. If you can reproduce it reliably let me know!

We have the same error on ruby 3.1.4.

@dillonbarker-te have you tried the suggested steps of installing other native gems?

Hey, I'm unable to install prism either, but on Windows 10 instead. Tried installing another native C gem, openssl and that worked. Tried using older versions of prism yesterday, and it wouldn't work passed version 0.17.1. The error message is different though, as it doesn't instruct me to do anything, unlike OP where they were told to install the development tools. Should I open a new issue for this?

authors: Tofpu dillonbarker-te hsbt iuliu-burtoiu kddnewton


text:
responsiveness: optimize for smartphone sizes

the header and the navigation should be optimized for smartphone sizes. Especially the menu item should change into a "hamburger"

done

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Compatibility with Lab3

Hi guys,
Lab 3 was released early this year and brings some changes on how extensions are built and deployed. The current extension is thus incompatible. How can we proceed to update this extension?
The Jupyter team has provided a guide and even some tools to ease the transition: https://jupyterlab.readthedocs.io/en/latest/extension/extension_migration.html
Diogo

I don't think the migration would be difficult, I could make a PR to update the extension. But, updating means that we lose compatibility to Lab2. Is that okay for now? Or maybe, we could create a different branch to support Lab3?

Hi, the proper approach would be to git tag the current master as "latest stable for lab2" and move it to a "lab2" branch, and continue development for lab3 on the master.

I would just tag the current head as lab2-latest and then continue on top of master. If we ever need to update the lab2 plugin code, we can make a branch.
The lab2-latest just needs to be mentioned in the readme.
Thanks a lot @didithilmy for still looking into this :-)

Thanks @didithilmy ! Good to see a GSoC project that becomes a long lasting collaboration.
Ping us if you need any help.

No problem, glad to help! I won't let three months of hard work goes to waste :)
I have pushed tag lab2-latest and created lab2 branch.
Also, I've made PR #2, please check if there's any problem with that. I have run it in development mode on my laptop, but I didn't connect it to a Rucio instance. It seems to be working fine.

authors: bari12 didithilmy diocas mlassnig

repo: rucio/jupyterlab-extension


text:
chore: add requests to requirements.txt

Description
Add requests to requirements.txt
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added unit tests for the code
[ ] I have made corresponding changes to the documentation

@RanjeetMishra Added requests package

source: gharchive/pull-request

repo: rudderlabs/rudder-airflow-provider


text:
c8d/builder: store untagged images

Requires:

#99

Set the dangling-name-prefix attribute to dangling to store images that are built without a tag.
Image list was also adjusted to account for the dangling images and they are shown like in the current Docker.

@vvoland the other PR is merged now

Rebased&undrafted

authors: rumpl vvoland

repo: rumpl/moby


text:
AttributeError on colab notebook?

Hi all,
the colab notebook fails. Does anybody know why?
!pip install -U numpy -q
!pip install -U llama-index --upgrade -q
!pip install -U llama-parse --upgrade -q

import nest_asyncio
nest_asyncio.apply()

from llama_parse import LlamaParse

parser = LlamaParse(
    api_key="llx-XXXXXXXXXXXXXXXXXXXXXXXXX",  # can also be set in your env as LLAMA_CLOUD_API_KEY
    result_type="markdown",  # "markdown" and "text" are available
    num_workers=4, # if multiple files passed, split in `num_workers` API calls
    verbose=True
)

# sync
documents = parser.load_data("/content/EN_TXT.pdf")

Result:
--------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
[<ipython-input-2-0ded22901b98>](https://localhost:8080/#) in <cell line: 4>()
      2 nest_asyncio.apply()
      3
----> 4 from llama_parse import LlamaParse
      5
      6 parser = LlamaParse(

14 frames
[/usr/local/lib/python3.10/dist-packages/numpy/testing/_private/utils.py](https://localhost:8080/#) in <module>
     55 IS_PYSTON = hasattr(sys, "pyston_version_info")
     56 HAS_REFCOUNT = getattr(sys, 'getrefcount', None) is not None and not IS_PYSTON
---> 57 HAS_LAPACK64 = numpy.linalg._umath_linalg._ilp64
     58
     59 _OLD_PROMOTION = lambda: np._get_promotion_state() == 'legacy'

I think this just an issue with your numpy install?
Try this
pip uninstall llama-parse numpy
pip install -U llama-parse

authors: Terranic logan-markewich


text:
Branch not deleting Automatically after apply is success and PR is merged.

Hi team,
I have deployed the atlantis to test tf automation. Below is my config.
Server Side Repo config:

repoConfig:

repos:

id: /.*/
delete_source_branch_on_merge: true
apply_requirements: []
workflow: default
allowed_overrides: [apply_requirements, delete_source_branch_on_merge]
allow_custom_workflows: false

Repo Level atlantis.yaml Config
version: 3
autodiscover:
mode: auto
delete_source_branch_on_merge: true
automerge: true
parallel_plan: true
parallel_apply: true
projects:

dir: .
terraform_version: v1.6.6
autoplan:
when_modified: [".tf"]
enabled: true

In both the config, i have given delete_source_branch_on_merge: true to delete the branch after everything is executed. However, same is not happening. Screenshot below.

I have also enabled the debug logs, and below are the same for above event.
{"level":"debug","ts":"2024-08-26T13:57:03.777Z","caller":"vcs/github_client.go:180","msg":"Creating comment on GitHub pull request 5","json":{"gh-request-id":"X-Github-Delivery=125b3dc0-9925-d1e5816912c7"}}
{"level":"debug","ts":"2024-08-26T13:57:03.935Z","caller":"server/middleware.go:45","msg":"POST /events – from 10.0.4.38:47060","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:03.935Z","caller":"events/events_controller.go:119","msg":"handling GitHub post","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:03.935Z","caller":"events/events_controller.go:185","msg":"request valid","json":{"gh-request-id":"X-Github-Delivery=12aa3b28-9b85-497723f9c70a"}}
{"level":"debug","ts":"2024-08-26T13:57:03.936Z","caller":"server/middleware.go:72","msg":"POST /events – respond HTTP 200","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:04.250Z","caller":"vcs/github_client.go:198","msg":"POST /repos/atlantis-poc/issues/5/comments returned: 201","json":{"gh-request-id":"X-Github-Delivery=125b3dc0-9925-d1e5816912c7"}}
{"level":"debug","ts":"2024-08-26T13:57:04.250Z","caller":"metrics/debug.go:52","msg":"timer","json":{"name":"atlantis.github.create_comment.execution_time","value":0.472759649,"tags":{"base_repo":"atlantis-poc","pr_number":"5"},"type":"timer"}}
{"level":"debug","ts":"2024-08-26T13:57:04.250Z","caller":"metrics/debug.go:52","msg":"timer","json":{"name":"atlantis.pullclosed_cleanup.execution_time","value":0.47882662,"tags":{},"type":"timer"}}
{"level":"info","ts":"2024-08-26T13:57:04.250Z","caller":"events/events_controller.go:579","msg":"deleted locks and workspace for repo atlantis-poc, pull 5","json":{"gh-request-id":"X-Github-Delivery=125b3dc0-9925-d1e5816912c7"}}
{"level":"debug","ts":"2024-08-26T13:57:04.250Z","caller":"server/middleware.go:72","msg":"POST /events – respond HTTP 200","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:04.487Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.pullclosed_cleanup.execution_success","value":1,"tags":{},"type":"counter"}}
{"level":"debug","ts":"2024-08-26T13:57:04.487Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.github_event.pr_closed.success_200","value":1,"tags":{"base_repo":"atlantis-poc","pr_number":"5"},"type":"counter"}}
{"level":"debug","ts":"2024-08-26T13:57:04.487Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.github_event.success_200","value":1,"tags":{},"type":"counter"}}
{"level":"debug","ts":"2024-08-26T13:57:04.487Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.github.create_comment.execution_success","value":1,"tags":{"base_repo":"atlantis-poc","pr_number":"5"},"type":"counter"}}
{"level":"debug","ts":"2024-08-26T13:57:05.714Z","caller":"server/middleware.go:45","msg":"POST /events – from 10.0.4.38:47060","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:05.715Z","caller":"events/events_controller.go:119","msg":"handling GitHub post","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:05.718Z","caller":"events/events_controller.go:185","msg":"request valid","json":{"gh-request-id":"X-Github-Delivery=13884c10-9614-b9178d616468"}}
{"level":"debug","ts":"2024-08-26T13:57:05.719Z","caller":"server/middleware.go:72","msg":"POST /events – respond HTTP 200","json":{}}
{"level":"debug","ts":"2024-08-26T13:57:06.487Z","caller":"metrics/debug.go:42","msg":"counter","json":{"name":"atlantis.github_event.comment_created.success_200","value":1,"tags":{"base_repo":"atlantis-poc","pr_number":"5"},"type":"counter"}}
Deployed with helm chart version as
appVersion: v0.28.5
version: 5.4.5
Could you please check and help here in fixing this issue?

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Hi, this is a GitHub configuration: please check https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches.

Hi,
That we already know. I am specificly asking for this config "delete_source_branch_on_merge: true". If we need to handle that by git config, then what is the use of this in server and repo config?

This configuration exists for all VCS type: Github, Azure, Gitlab, etc. Looks like it's just being ignored in your configuration.
Are you using a GitHub user or a GitHub app (docs)?

I am using GitHub user. Created a PAT token for access and provided that in secrets.

My best guess is that Atlantis is not getting the webhook for the merge event. Can you confirm the events you have configured (docs)?

In the configured the webhook as per the documentation and select 4 checkboxes as mentioned.

Below are the webhooks that are getting triggerred

I don't see any event for merge

The most strange part is that Atlantis log doesn't show any event or failure for that event. We might have a bug or something is missing.
@jamengual can you move this issue into https://github.com/runatlantis/atlantis pls?

Thanks @GMartinez-Sisti for considering. @jamengual pls take this up and release the fix

pls take this up and release the fix

@ankitmahajan-appfire not quite like this 😅 first we need to see if it's actually a bug or if someone is able to use it correctly. Then since this an open source project someone will need to volunteer to pick it up. But at least it's a start 😃

Sure @GMartinez-Sisti . Thanks

repo: runatlantis/helm-charts


text:
Navbar examples reference state.basicState, but state is undefined

I presume it's supposed to be model.navbarState.basicState, not state.basicState for the basic example, and the custom one has a similar variable issue.

Also accordion base example need to update for Elm Platform 0.18.0.
Attached a corrected example
module AccordionExample exposing (..)

import Bootstrap.Accordion as Accordion
import Bootstrap.Card as Card
import Bootstrap.Grid as Grid
import Bootstrap.Text as Text
import Html exposing (..)
import Html.Attributes exposing (..)

main : Program Never Model Msg
main =
    Html.program
        { init = init
        , view = view
        , update = update
        , subscriptions = subscriptions
        }

type Msg
    = AccordionMsg Accordion.State

type alias Model =
    { accordionState : Accordion.State }  -- replaced = with :

init : ( Model, Cmd Msg )
init =         -- in example missed this line
    ( { accordionState = Accordion.initialState }, Cmd.none )

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        AccordionMsg state ->
            ( { model | accordionState = state }
            , Cmd.none
            )

view : Model -> Html Msg
view model =
    Accordion.config AccordionMsg -- AccordionMsg was skipped too
        |> Accordion.withAnimation
        |> Accordion.cards
            [ Accordion.card
                { id = "card1"
                , options = []
                , header =
                    Accordion.header [] <| Accordion.toggle [] [ text "Card 1" ]
                , blocks =
                    [ Accordion.block []
                        [ Card.text [] [ text "Lorem ipsum etc" ] ]
                    ]
                }
            , Accordion.card
                { id = "card2"
                , options = []
                , header =
                    Accordion.header [] <| Accordion.toggle [] [ text "Card 2" ]
                , blocks =
                    [ Accordion.block []
                        [ Card.text [] [ text "Lorem ipsum etc" ] ]
                    ]
                }
            ]
        |> Accordion.view model.accordionState

-- You need to do this wiring when you use animations !

subscriptions : Model -> Sub Msg
subscriptions model =
    Accordion.subscriptions model.accordionState AccordionMsg

@slavaromanov You'll probably want to create a new issue so it's easier for rundis to track.

Actually I think that the themes of issues are similar, but but if you insist..

authors: mrozbarry slavaromanov

license_source: bigquery


text:
Bank tag layouts v1.2

Updates Bank Tag Layouts to v1.2. New features:

Automatically lay out a tag tab based on your current gear and inventory.
Layout placeholders are now draggable.
Minor improvements and bugfixes.

Did you make those icons or did they come from somewhere?

The red x and green checkmark come from screen markers, the shuffle icon is from material.io.

authors: geheur raiyni

repo: runelite/plugin-hub


text:
Add fossil island underwater swimming and agility timer

The location of the correct chest/clam changes exactly every 1 minute. Underwater swimming is the most efficient method for training thieving to 200m, so it would be great if a simple timer could be added to make the method more manageable ^_^

Duplicate of #5334

repo: runelite/runelite


text:
Swap Shift Click option drop down list appears invisible

Type
Incorrect behavior
Operating System
Windows
OS Version
Windows 11
Bug description
When attempting to swap shift click options on any item, the drop down list to select what options you want to have shift-click abilities on does not appear.
Screenshots or videos

RuneLite version
RuneLite version: 1.10.42
Launcher version: 2.6.10
Logs
No response

Did you try safe mode mentioned at the top of the bug report template? You didn't include your logs so I can't check if you have.

Did you try safe mode mentioned at the top of the bug report template? You didn't include your logs so I can't check if you have.

I did not originally put RuneLite into safe mode. I just retried in safe mode, and the issue still stands. I did not think to post any logs because a crash did not occur, here is the log for safe-mode enabled below:
launcher.log

We need your client.log as well

We need your client.log as well

client.log
launcher.log

Had the same issue, looked into code, turns out my item swaps -> customizable shift-click option was disabled in the menu entry swapper settings. Enabling that fixed the issue.
Strange thing is I use the plugin-presets plugin, so I'm fairly sure that setting has been off for years, but shift-clicks always worked before. The config for shift clicks hasn't been touched for 4 years, so tried looking at recent changes to menu entry swapper plugin to understand why it worked before, but from the changes I saw it wouldn't have worked previously if the config was set to false (as intended) so no clue why it used to work. Only other explanation is I somehow manually set it to false then synced that to my plugin-preset, or the plugin-preset plugin disabled the setting somehow.
Either way might be worth hiding the menu entry for swap-shift click if customizable shift-click is set to false (and same for customizable left click) to avoid future confusion.

Had the same issue, looked into code, turns out my item swaps -> customizable shift-click option was disabled in the menu entry swapper settings. Enabling that fixed the issue.
Strange thing is I use the plugin-presets plugin, so I'm fairly sure that setting has been off for years, but shift-clicks always worked before. The config code for shift clicks hasn't been touched for 4 years, so tried looking at recent changes to menu entry swapper plugin to understand why it worked before, but from the changes I saw it wouldn't have worked previously if the config was set to false (as intended) so no clue why it used to work. Only other explanation is I somehow manually set it to false then synced that to my plugin-preset, or the plugin-preset plugin disabled the setting somehow.
Either way might be worth hiding the menu entry for swap-shift click if customizable shift-click is set to false (and same for customizable left click) to avoid future confusion.

I want to say that it was enabled, but then I disabled it then re-enabled it. After re-enabling "Customizable shift-click" it worked! Very strange. Thanks for pointing this out. I wonder if after further updates that maybe it bricks the customizable shift-click option? Either way, this was the solution for me as well. Thank you

authors: EpicDuckRS Felanbird buncieboy cdfisher


text:
Menu Entry Swapper for Larry's Boat

Some people such as ironman may prefer to use the boat over spending the time to make Icy basalts.

I think this is way too niche request, idk if we should really implement it.

authors: AverageHumanoid deathbeam


text:
Left side RL Plugin Panel

I was wondering if there can be an option to move the RL plugins panel to the left side of the client. This is a very small thing i know but i feel theres quite a few people that might like this feature and would like to see this added

Duplicate of #1641

authors: Jumpsoot deathbeam


text:
Ground markers behaving strangely in Meiyerditch

Screenshots

Environment

OS: Windows 10
RuneLite version: 1.5.23-SNAPSHOT

I don't see anything wrong here?

The markers aren't appearing where you click to place them

Its appearing above the (invisible) tile you clicked on, presumably where the top of the tile is

Ahh, I see. It makes it hard to remove markers if you place one by accident, since clicking where the marker appears just adds another marker

authors: ShaunDreclin abextm


text:
Adding config option to persist tags through restart

Closes #11961
Adding config option to have the "Tag" or "Untag" option to instead modify the "Npcs To Highlight" option which allows the tags to persist through restart.

I think I'd rather see a Tag-All option instead of a config option to change which menu is shown.

Removing config option for original idea and adding a new context option which will either add or remove the npc name from the "Highlighted Npcs" textbox in the config. This option is denoted as Tag-All or Un-tag-All

NPCs can also be highlighted with wildcards, eg *demon*, which will "tag all" of an npc type. This looks like you are making it so the menu option would be Tag-All when something is highlighted with a wildcard which when clicked wouldn't visibly do anything since they are already tagged - is this intentional? Oh the other hand it might be weird if "Untag-all" removed a wildcard entry which was also used to highlight other things.

After some more thinking I think it would be best to only add the tag-all/untag-all options if the entry doesn't wildcard match something in the list eg:
boolean matchesList = highlights.stream()
	.filter(highlight -> !highlight.equals(npc.getName().toLowerCase()))
	.anyMatch(highlight -> WildcardMatcher.matches(highlight, npc.getName().toLowerCase()));
if (!matchesList) ...

Otherwise it is either always 1) tagging something which is already tagged or 2) not actually untagging something when you click untag all - which I think would be confusing.

Adding a check to only display option based on wildcard matching as suggested.

Making attempt at implementing suggested changes.

Adding the most recent set of suggestions

authors: Adam- zeffirojoe


text:
Add Config Sections

Closes #11602
Certain configs have always been begging for some form of section system. When merging multiple plugins together, being able to separate their options would be very useful.
Sections can be toggled by clicking anywhere on them, and are persisted through the config. It is possible to nest configs inside one another. Each level of nesting adds a small but noticeable margin on the left side.
I have added sections to Chat Color (which desperately needed it) to show users that there are 2 sets of options, and to Ground Items to hide potentially gigantic item lists.
Feedback on the design of the sections is very much appreciated

(Above gif is outdated, as the text is now RL orange. See comments below)

Updated the visuals from feedback in the Discord

this will probably close #6707

Updated with @Nightfirecat's suggestions. The icon is now slightly smaller, but it looks better in my opinion.

Alright, I've added sections for all the plugins currently in the client, and also split up the hardwood grove swap since it fell into two headings.

04cbc88 and a3e3aed can be merged imo. Adding config sections support and adding a saving mechanism for it should be one change.

In some config sections, expanding a config section can cause the section header underline to narrow, and the arrow to move left with it. For example, in the MES config panel, collapse all sections then toggle the "Item Swaps" section to see the following behavior:

Fixed this weird issue, added a log message if the reflection fails, and updated to work with the new Ignored Events configitem

authors: Hydrox6 Nightfirecat adwitkow


text:
ci: Add a CI to check documentation changes

This fix introduces a new CI to check whether the command reference documentations need to be updated.
When new commands or options are added, the
finch gen-docs generate -p cmd/finch/ command should be run locally to update the documentation.
However, it's easy to forget this step.
An issue has also been created that proposes to detect these differences.

https://github.com/runfinch/finch/issues/942

Therefore, in this fix, the new CI step will generate the documentation and compare it with the existing files.
If there are differences, the CI will fail, prompting contributors to update the documentations.
Issue #, if available: #942
Description of changes: The details are described in the commit message.
Testing done: N/A

[x] I've reviewed the guidance in CONTRIBUTING.md

License Acceptance
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

The newly added CI is failing.

https://github.com/runfinch/finch/actions/runs/9071519919/job/24925389774?pr=943

Details

0s
Run git add -N docs/cmd
  git add -N docs/cmd
  git diff --exit-code docs/cmd
  shell: /bin/bash -e {0}
diff --git a/docs/cmd/finch_build.md b/docs/cmd/finch_build.md
index 022[1](https://github.com/runfinch/finch/actions/runs/9071519919/job/24925389774?pr=943#step:9:1)3df..e69de29 100644
--- a/docs/cmd/finch_build.md
+++ b/docs/cmd/finch_build.md
@@ -1,3[2](https://github.com/runfinch/finch/actions/runs/9071519919/job/24925389774?pr=943#step:9:2) +0,0 @@
-# finch build
-
-Build an image from a Dockerfile. Needs buildkitd to be running.
-If Dockerfile is not present and -f is not specified, it will look for Containerfile and build with it.
-
-```text
-finch build [flags] PATH
-```
-
-## Options
-
-```text
-      --build-arg stringArray    Set build-time variables
-      --buildkit-host string     BuildKit address [$BUILDKIT_HOST] (default "unix:///run/buildkit/buildkitd.sock")
-      --cache-from stringArray   External cache sources (eg. user/app:cache, type=local,src=path/to/dir)
-      --cache-to stringArray     Cache export destinations (eg. user/app:cache, type=local,dest=path/to/dir)
-  -f, --file string              Name of the Dockerfile
-  -h, --help                     help for build
-      --iidfile string           Write the image ID to the file
-      --label stringArray        Set metadata for an image
-      --network string           Set type of network for build (format:network=default|none|host) (default "default")
-      --no-cache                 Do not use cache when building the image
-  -o, --output string            Output destination (format: type=local,dest=path)
-      --platform strings         Set target platform for build (e.g., "amd6[4](https://github.com/runfinch/finch/actions/runs/9071519919/job/24925389774?pr=943#step:9:4)", "arm64")
-      --progress string          Set type of progress output (auto, plain, tty). Use plain to show container output (default "auto")
-  -q, --quiet                    Suppress the build output and print image ID on success
-      --rm                       Remove intermediate containers after a successful build (default true)
-      --secret stringArray       Secret file to expose to the build: id=mysecret,src=/local/secret
-      --ssh stringArray          SSH agent socket or keys to expose to the build (format: default|<id>[=<socket>|<key>[,<key>]])
-  -t, --tag stringArray          Name and optionally a tag in the 'name:tag' format
-      --target string            Set the target build stage to build
-```
Error: Process completed with exit code 1.

This is because there are some outdated documentation files when running make gen-docs locally, such as:
haytok ~/workspace/haytok/finch [add-ci-for-finch-gen-docs-generate-command]
> git status
On branch add-ci-for-finch-gen-docs-generate-command
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   docs/cmd/finch_build.md
	modified:   docs/cmd/finch_container.md
	modified:   docs/cmd/finch_create.md
	modified:   docs/cmd/finch_pull.md
	modified:   docs/cmd/finch_run.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	docs/cmd/finch_vm_settings.md

no changes added to commit (use "git add" and/or "git commit -a")

Therefore, the newly added CI is behaving as expected.
Note that the generation of docs/cmd/finch_vm_settings.md was introduced in the following PR.

https://github.com/runfinch/finch/pull/938

Question
As for other documentation files (e.g., docs/cmd/finch_build.md), I plan to add them in a separate PR.
Is this approach acceptable?

Do all changes requires a documentation change?
If not may be we should have some override

Do all changes requires a documentation change? If not may be we should have some override

Only changes to the cmd/finch/ directory, or updates to the lima bundle should trigger documentation updates

updates to the lima bundle

What are you referring to?
At the moment, we only check if there are any diffs by running finch gen-docs generate -p docs/cmd/.

repo: runfinch/finch


text:
CI failed due to the compiletest was not updated

Referring to the CI failure for PR #176: https://github.com/runtimeverification/mir-semantics/actions/runs/5532415489/jobs/10094488826?pr=176
The integration test is still using the old test suits with 3197 test cases where the latest update in compiletest, it should be 2550 test cases.
Docker on CI needs to be rebuild.

The submodule needs to be commited correctly when it has been updated. To tell if the submodule is pointing at the correct location, cat .git/modules/path-to-submodule/HEAD should output the current hash of the submodule project. If it is not, the documentation to update the submodule is located here, take note of --remote, --merge, --rebase as options.

repo: runtimeverification/mir-semantics


text:
Add multiple verbosity levels to incorporate kompile logs

With how the kompile args are generated(see here), there is no way to pass --verbose to kompile to see the logs.
I would plan to make the general --verbose arg in pyk countable and add a new log level named VERBOSE with a priority in between INFO and DEBUG. This way:

--verbose/-v/--debug would keep logging the same information
-vv will log additional information captured from kompile --verbose

The changes I propose are to:

set the --verbose argument type to count in https://github.com/runtimeverification/pyk/blob/master/src/pyk/cli/args.py#L20
define a new constant VERBOSE:Final = 15 for the verbosity priority.
update the loglevel() function to accomodate new level.
add the new level and update the _loglevel in kevm.
include the verbose = _LOGGER.getEffectiveLevel() == VERBOSE in https://github.com/runtimeverification/evm-semantics/blob/5cda4c794acc592943f2c6322f11e0744884acc5/kevm-pyk/src/kevm_pyk/kompile.py#L109-L118

Maybe --verbose can just include information from kompile --verbose. What do you think?

That would be easier to implement and would not require changes on the pyk library. I guess either --verbose or --debug should do then.

repo: runtimeverification/pyk


text:
[BUG] Not showing description of the subcategory

Description
When clicking on the i button right to subcategory name, its not showing any description in the popup, its showing the category name.
Screenshots

Any additional information?
No response
What browser are you seeing the problem on?
No response
Checklist

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

Hey @rupali-codes  I would love to work on this issue

@rupali-codes The thing has been working fine in local. The issue is in deployment

@rupali-codes The thing has been working fine in local. The issue is in deployment

The issue is in local development as well, You can see on screenshot.

@rupali-codes can i try?

@rupali-codes can i try?

Yeah sure!

if you tell i will do it

repo: rupali-codes/LinksHub


text:
[Add] Interactive Python Tutorial Website

Fixes Issue
Closes #606
Changes proposed
Added Python language tutorial in language section of database.
Screenshots

Note to reviewers
Please review my change and add it to your main branch

Great job @aashish-aanand! :) LGTM! :)

Thank you ma'am 😌


text:
Add libpq from PostgreSQL

Hi Ruslan, hope you are doing good :-)
I am trying to add libpq to hunter. I've created a repository on https://github.com/pretyman/libpq with the postgres 9.5.0 source tarball but without the bin dir and some minor changes to the makefiles to not compile the binaries utilities and other targets that libpq does not depend on.
My doubts are:

The library is libpq, but CMake comes with a Modules/FindPostgreSQL.cmake. Should I name the package PostgreSQL?
If we are to use FindPostgreSQL, it does not define a target libpq, nor any target, that we could conveniently add to target_link_libraries. Should I then I could leave the hunter package named libpq, create our own Findlibpq.cmake script, that possibly uses internally FindPostgreSQL.cmake, but defines a target libpq with the correct include directories and libraries?

For me creating a separate Findlibpq.cmake which defines its own target makes more sense, but let me know your thoughts.
Thanks, со Старым Новым годом!

I've created a repository on https://github.com/pretyman/libpq with the postgres 9.5.0 source tarball

I forked it to https://github.com/hunter-packages/libpq. I've sent you invitation to the team.

Should I name the package PostgreSQL?

I think yes

If we are to use FindPostgreSQL, it does not define a target libpq, nor any target, that we could conveniently add to target_link_libraries

You can patch standard FindPostgreSQL so it will define PostgreSQL::libpq imported target and save it to cmake/find directory. This directory has high priority. PostgreSQL_LIBRARIES can be set to PostgreSQL::libpq for backward compatibility, PostgreSQL_INCLUDE_DIRS can be set to empty string.

со Старым Новым годом!

Спасибо :)

If I name the package PostgreSQL, shouldn't you create a repository https://github.com/hunter-packages/PostgreSQL instead of libpq ? Or it is better that I create and you fork?

If I name the package PostgreSQL, shouldn't you create a repository https://github.com/hunter-packages/PostgreSQL instead of libpq ?

Both repository and team name renamed

Thanks, you can delete branch libpq-9.5.0 if you wish

authors: pretyman ruslo

repo: ruslo/hunter


text:
Requesting a new crates.io release

I'm particularly interested in the new SQLite 3.38 release that @gwenn merged and https://github.com/rusqlite/rusqlite/pull/1069.
Thanks <3

Version 0.27.0 released.

authors: gwenn trevyn

repo: rusqlite/rusqlite


text:
Extract module is broken on windows

I hesitate to put this issue out, but I'm sure it is not just me that caused this:
I'm on Windows 10, vscode (latest version), and also latest version of rust-analyzer.
I'm writing a module in a main.rs-file, and I wanted to Ctrl+. and then extract module to file.
However, I get this error message:
cannot open file:///c%3A/Users/tpb398/Documents/GitHub/todo-cli/src/todo.rs.
Detail: Unable to read file 'c:\Users\tpb398\Documents\GitHub\todo-cli\src\todo.rs'
(Error: Unable to resolve non-existing file 'c:\Users\tpb398\Documents\GitHub\todo-cli\src\todo.rs')

Note, this file todo.rs doesn't exist, but isn't it supposed to be created here?
Maybe it is a windows thing and the c%3A is the problem.

Can confirm this also happens on my Windows machine:
cannot open file:///c%3A/Users/yoshu/Code/prisma-engines/libs/user-facing-errors/src/user_facing_error.rs.
Detail: Unable to read file 'c:\Users\yoshu\Code\prisma-engines\libs\user-facing-errors\src\user_facing_error.rs'
(Error: Unable to resolve non-existing file 'c:\Users\yoshu\Code\prisma-engines\libs\user-facing-errors\src\user_facing_error.rs')

To me this seems like the filesystem fails to create the file, or perhaps opens the file with the wrong permissions, and then tries writing into it, which fails.

I have the same issue. It's not very serious, just very inconvenient for now.

https://github.com/rust-analyzer/rust-analyzer/pull/7576 fixes this, turns out we did indeed try to fill the new module with source before actually creating its file.

authors: CGMossa Kiiyya Veykril yoshuawuyts

repo: rust-analyzer/rust-analyzer


text:
Bump deps

insta, unicode-xid and others

bors r+

authors: lnicola matklad


text:
Init implementation of structural search replace

next steps:

ignore space and other minor difference
add support to ra_cli
call rust parser to check pattern
documentation

original issue #2267

Gave it a shoot, it seems to work perfectly for small cases. Spend at least couple of minutes mindlessly marveling at flipping $a <-> $b :)
However I've found at least one case where it doesn't quite work:

After SSR

Haven't looked into the code closely yet, so can't tell what's the issue

That's for this bit of code: https://github.com/rust-analyzer/rust-analyzer/blob/305d9219823f5c0a6ffe526351b225b410702dfd/xtask/src/cmd.rs#L21-L27

Left small nits, and nothing more. Looks great, big thanks for the implementation!

I think there's still a lot to do here, but this seems reasonable to merge now!
I'll open a follow-up issue
bors r+

authors: Veetaha matklad mikhail-m1


text:
Release tracking PR: v0.3.0

In preparation for release add a changelog entry and bump the version number to v0.3.0.
Note that since we are pre-1.0 and this release has no breaking changes we technically could do v0.2.1 - I get more dopamine by bumping the minor patch version and it is still, I believe, technically allowed.
Note: Now includes an initial patch to remove explicit version of hex from the fuzz crate.

Bump please @apoelstra

I really think we should do 0.2.1 rather than 0.3.0 since there are no breaking changes.

Tagged and published.

authors: apoelstra tcharding

repo: rust-bitcoin/hex-conservative


text:
Remove deprecated Error::description

The description method has been deprecated since 1.42.0
Moved the existing messages to impl Display.

Change looks good, a nice cleanup. Builds and runs on my machine. @stevenroose any suggestions on what else should be done to get this merged?

authors: erasmospunk notmandatory

repo: rust-bitcoin/murmel


text:
Implement fuzz testing

Fuzz testing in rust-bitcoin found an error in rust-bech32 (rust-bitcoin/rust-bitcoin#100 ). This crate should have its own fuzz testing.

I'm using the fuzz testing from rust-bitcoin as reference (newer did fuzz testing before). I've already written a binding for bitcoin-core's bech32.cpp implementation (c++ -> c -> unsafe rust -> rust). Now I'm trying to build Bech32 structs from the random byte-slice input.


text:
Make sure decode_pushnum is private (pub(crate))

In #2989 we made decode_pushnum public while moved stuff to primitives - make sure it is private before releasing primitives v0.100.0.

Turns out this wasn't possible. We still use decode_psuhnum in rust-bitcoin.

repo: rust-bitcoin/rust-bitcoin


text:
Implement Display trait instead of implementing ToString directly.

ExtendedPubKey and ExtendedPrivKey implemented ToString directly but
Rust documentation says to implement Display and get the ToString
implementation for free.

Build failed due to fuzzing taking too long.

Would be even better if the base58 module could take a fmt::Write object (or maybe io::Write is sufficient? I can never remember) and encode directly to that, and avoid the unnecessary allocation in check_encode_slice.
But this is fine for now.

authors: apoelstra jeandudey


text:
Canonical link format

What should the canonical link format be?
HTML or Markdown?
[foo]: ./relative/markdown.md
[foo]: ./relative/html.html

Relative or absolute?
[foo]: ./relative/markdown.md
[foo]: /absolute/markdown.md

Take a look at https://github.com/thejpster/book/blob/testing_links/src/intro/install/verify.md.
It contains:
The contents may not match exactly but you should get the last line about
breakpoints and watchpoints. If you got it terminate the OpenOCD process and
move to the a [test1] b [test2] c [test3] d [test4] e [test5] f [test6].

[test1]: /intro/hardware.html
[test2]: ./intro/hardware.html
[test3]: /intro/hardware.md
[test4]: ./intro/hardware.md
[test5]: intro/hardware.md
[test6]: ../hardware.md

Only test1, test3 and test6 work in mdbook serve. Only test6 works on Github. Therefore I propose all URLs are made relative, with a .md extension, and no leading ./ where the file is in the same directory.

LGTM :+1: thanks for the investigation!

authors: jamesmunns thejpster

repo: rust-embedded/book


text:
N50: sm64jsarchive

Part of #1473
Basically what sm64jsarchive is: (old sm64js is basically gone so sm64jsarchive is a reboot and even some developers of sm64js like Tarnadas assisted me with this!)

Let me change this real quick


text:
Both _WIN32 and _WIN64 are defined when targeting 32-bit windows from 64-bit windows

I tried to investigate https://github.com/rust-lang-nursery/rust-bindgen/issues/541 and found out that both _WIN32 and _WIN64 are defined. I could see how it makes many troubles, and perhaps related to that issue .
It won't happen if the command has the --target=i686-pc-windows-msvc flag, but it does happen if it has the --target=x86_64-pc-windows-msvc flag.
It also happens when I use bindgen through build.rs script (this way it happens on both cargo run --target=i686-pc-windows-msvc and cargo run --target=x86_64-pc-windows-msvc).
Input C/C++ Header
// example.h
#ifdef _WIN32
typedef int type1;
#endif
#ifdef _WIN64
typedef long long type2;
#endif

Bindgen Invocation
bindgen.exe example.h
Actual Results
pub type type1 = ::std::os::raw::c_int;
pub type type2 = ::std::os::raw::c_longlong;

Expected Results
// when --target=i686-pc-windows-msvc
pub type type1 = ::std::os::raw::c_int;

// when --target=x86_64-pc-windows-msvc
pub type type2 = ::std::os::raw::c_longlong;

Thanks for the bug report!
I'm not really familiar with windows development, but to be clear, only one of either _WIN32 or _WIN64 should ever be defined at once, right?

_WIN32 is always defined these days on both 32 and 64 bit targets, see https://msdn.microsoft.com/en-us/library/b0084kay.aspx

_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.
_WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined.

32 here is supposed to be the opposite to 16, not 64.

_WIN32 is always defined these days (on both 32 and 64 bit targets), see https://msdn.microsoft.com/en-us/library/b0084kay.aspx

Does that mean that this issue can be closed as exhibiting expected behavior?

Ah good to know.
Yet there is a problem, because through build.rs script _WIN64 is defined for 32bit.

Yes, looks like that.

To make sure I understand: the remaining issue is that when invoking bindgen as a library via build.rs on 32 bit host platforms, _WIN64 is still defined? But not when targeting 32-bit from 64 bit?

No.
It happens on my 64 bit machine when targeting to 32 bit.
I don't know what happens on 32 bit hosts.

Thanks for the clarification!

If I had to guess, I'd say it's related to https://github.com/rust-lang/rust/issues/42587
In other words, I guess that the bindgen library uses conditional compilation that misleads it because it's executed on a process that is 64 bit.

Update:
It happens on version 0.30, but it's working as expected on master.

Ok I used git bisect to find the commit that solved it and it's https://github.com/rust-lang-nursery/rust-bindgen/commit/26da3447a73d0364849f0325f222c4a8c9337550
Makes sense that it solved it because it implements find_effective_target.
Only need to publish a new version.

We'll publish a new version after merging https://github.com/rust-lang-nursery/rust-bindgen/pull/1042

authors: fitzgen liranringel petrochenkov

repo: rust-lang-nursery/rust-bindgen


text:
A large argument with comment exceeds max width

The comment exceeds max width because it gets indented. cc #2178.
Input
fn foo() {
    let string_map: HashMap<String, Vec<u8>> = if string_offsets_count > 0 {
        let string_offsets: Vec<u16> = t!((0..string_offsets_count)
                                                .map(|_| read_le_u16(file))
                                                .collect());

        let mut string_table = Vec::new();
        t!(file.take(string_table_bytes as u64).read_to_end(&mut string_table));

        t!(string_offsets.into_iter().enumerate().filter(|&(_, offset)| {
            // non-entry
            offset != 0xFFFF
        }).map(|(i, offset)| {
            let offset = offset as usize;

            let name = if snames[i] == "_" {
                stringfnames[i]
            } else {
                snames[i]
            };

            if offset == 0xFFFE {
                // undocumented: FFFE indicates cap@, which means the capability is not present
                // unsure if the handling for this is correct
                return Ok((name.to_string(), Vec::new()));
            }

            // Find the offset of the NUL we want to go to
            let nulpos = string_table[offset..string_table_bytes].iter().position(|&b| b == 0);
            match nulpos {
                Some(len) => Ok((name.to_string(), string_table[offset..offset + len].to_vec())),
                None => Err("invalid file: missing NUL in string_table".to_string()),
            }
        }).collect())
    } else {
        HashMap::new()
    };
}

Output
fn foo() {
    let string_map: HashMap<String, Vec<u8>> = if string_offsets_count > 0 {
        let string_offsets: Vec<u16> = t!(
            (0..string_offsets_count)
                .map(|_| read_le_u16(file))
                .collect()
        );

        let mut string_table = Vec::new();
        t!(
            file.take(string_table_bytes as u64)
                .read_to_end(&mut string_table)
        );

        t!(
            string_offsets
                .into_iter()
                .enumerate()
                .filter(|&(_, offset)| {
                    // non-entry
                    offset != 0xFFFF
                })
                .map(|(i, offset)| {
                    let offset = offset as usize;

                    let name = if snames[i] == "_" {
                        stringfnames[i]
                    } else {
                        snames[i]
                    };

                    if offset == 0xFFFE {
                        // undocumented: FFFE indicates cap@, which means the capability is not present
                        // unsure if the handling for this is correct
                        return Ok((name.to_string(), Vec::new()));
                    }

                    // Find the offset of the NUL we want to go to
                    let nulpos = string_table[offset..string_table_bytes]
                        .iter()
                        .position(|&b| b == 0);
                    match nulpos {
                        Some(len) => Ok((
                            name.to_string(),
                            string_table[offset..offset + len].to_vec(),
                        )),
                        None => Err("invalid file: missing NUL in string_table".to_string()),
                    }
                })
                .collect()
        )
    } else {
        HashMap::new()
    };
}

Meta
0.2.16-nightly (4e04e82 2017-11-28)
The above example is taken from https://github.com/rust-lang/rust/blob/master/src/libterm/terminfo/parser/compiled.rs#L280-L315.

Now that by default rustfmt ignores the width of comment, I think that we can close this.

repo: rust-lang-nursery/rustfmt


text:
Compiling Cargo from source - missing libssl

EDIT: Oops.. I see it's looking for the static library, which I don't have on my system. I don't even know which package should supply this library.

I'm trying to build Cargo from source, but I get an error about missing the native ssl library.
Not sure if this is a Cargo or openssl-sys issue, but I think the problem was there a week ago too, and I guess others are happily building Cargo from source.
The error:
$ make
# ... snip ...
   Compiling openssl-sys v0.6.4
error: could not find native static library `ssl`, perhaps an -L flag is missing?
Could not compile `openssl-sys`.

$ locate libssl.so | grep '/usr/lib'
/usr/lib/libssl.so
/usr/lib/libssl.so.1.0.0
/usr/lib32/libssl.so
/usr/lib32/libssl.so.1.0.0

rust-openssl's docs appear to provide some guidance https://github.com/sfackler/rust-openssl

@simendsjo do you have the OPENSSL_STATIC environment variable set? It looks like that's the reason rust-openssl may try to link statically vs dynamically.

@alexcrichton:
I don't have OPENSSL_STATIC defined, and I cannot see it being
defined in either cargo nor openssl. When compiling with verbose,
I get the following:
     Running `rustc /home/simendsjo/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.6.4/src/lib.rs --crate-name openssl_sys --crate-type lib -C opt-level=3 -C metadata=149f6ef08ad7404d -C extra-filename=-149f6ef08ad7404d --out-dir /mnt/win/simendsjo/code/rust/cargo/target/x86_64-unknown-linux-gnu/release/deps --emit=dep-info,link --target x86_64-unknown-linux-gnu -L dependency=/mnt/win/simendsjo/code/rust/cargo/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/mnt/win/simendsjo/code/rust/cargo/target/x86_64-unknown-linux-gnu/release/deps --extern libc=/mnt/win/simendsjo/code/rust/cargo/target/x86_64-unknown-linux-gnu/release/deps/liblibc-2eda841eb12a3090.rlib -Awarnings -L /home/rustbuild/root64/lib -l static=ssl -l static=crypto -l dl`

The last part shows that it's trying to use the static libraries.
Looking at ./configure, I see that using --enable-nightly
might be of importance:
if [ ! -z "$CFG_ENABLE_NIGHTLY" ]; then
    if [ ! -f .cargo/config ]; then
        mkdir -p .cargo
        cat > .cargo/config <<-EOF
[target.x86_64-unknown-linux-gnu.openssl]
rustc-flags = "-l static=ssl -l static=crypto -l dl -L /home/rustbuild/root64/lib"
root = "/home/rustbuild/root64"
include = "/home/rustbuild/root64/include"

[target.i686-unknown-linux-gnu.openssl]
rustc-flags = "-l static=ssl -l static=crypto -l dl -L /home/rustbuild/root32/lib"
root = "/home/rustbuild/root32"
include = "/home/rustbuild/root32/include"
EOF
    fi
fi

I tried without --enable-nightly, but then I get a lot of errors
due to #[deny(missing_docs)] in various libraries.
I tried deleting ~/.cargo and running again, but the same errors
apply.
I really have no idea how I should try to locate these issues.

Ah I see! You shouldn't need to configure Cargo with --enable-nightly  as that's just meant for the bots (like in the normal Rust distribution) and you also may want to follow the instructions for compiling from source in the README, as it'll show how to download the same version of Rust we're using to test on the bots.
Updating dependencies for missing_docs warnings is done in a separate PR, and I hope to set up automation soon for all three channels of Rust, so I'm going to close this for now as if you don't use --enable-nightly it should fix the problem as listed.

I tried updating my rust installation from source and then cargo (without nightly). It works now. I guess I was a bit unlucky with my combination of rustc/cargo.

authors: alexcrichton simendsjo tamird

repo: rust-lang/cargo


text:
Failed to select a version for winapi

Trying to compile commit 0c57e48c48f3b329392775af25f627022a1c5f73 of glutin (https://github.com/tomaka/glutin/tree/0c57e48c48f3b329392775af25f627022a1c5f73) produces the following error:
failed to select a version for `winapi` (required by `glutin`):
all possible versions conflict with previously selected versions of `winapi`
  version 0.2.1 in use by winapi v0.2.1
  possible versions to select: 0.2.0

I am explicitely stating in the Cargo.toml that I want winapi 0.2.0 and not 0.2.1, but cargo doesn't seem to like it.
In the case where I'd be doing something wrong, the error message is not very helping.

Removing the dependencies on the windows -sys crates fixes the problem. These crates all depend on winapi = "*".

This should have been fixed by https://github.com/rust-lang/cargo/pull/1804

Oh ok. I'll check with tomorrow's nightlies.

Yeah I believe this was fixed by #1804, and hopefully new nightlies will come out soon once we get our mac builders under control...

I confirm this is fixed with 5cf4a89 2015-07-21

authors: alexcrichton retep998 tomaka


text:
cargo test requires an order of magnitude more memory to link

I'm working on a private repository and hit some weird behavior.
cargo build uses about 2GB mem usage and finishes fine.
cargo test uses about 14GB before swap thrashing occurs so badly as to halt all progress.
I don't have time to minimize a test case today, maybe sometime next week, but I was curious how to proceed here attempting to diagnose the root cause.

Thanks for the report! I think the bug here may be with rust-lang/rust, though, and not Cargo? (Cargo just calls the compiler). It'd be useful though to learn what process is running out of memory here, if it's something like ld then there may not be much we can do about it :(

authors: JustAPerson alexcrichton


text:
Travis CI .com domain

Problem
I just published the component_group crate. The badge for Travis CI doesn't work though because it assumes travis-ci.org. The problem with this assumption is that Travis CI recently decided to group all projects under one travis-ci.com domain. New projects are added under this by default.

Possible Solution(s)
If the domain to use can't be detected automatically, could it be possible to configure which domain to use in Cargo.toml?
Notes
Output of cargo version:
cargo 1.31.0 (339d9f9c8 2018-11-16)

Thanks for the report! I believe this is better tracked on crates.io at https://github.com/rust-lang/crates.io/issues/1392.  It looks like Travis has a final deadline of the end of January to migrate all open source projects, so always using .com at that time would probably be sufficient.

Thanks! Sorry, I searched in this repo and should have thought to search that one too 😅

authors: ehuss sunjay


text:
cargo fetch always redownloads git repo if it fails to parse rev

Problem
[package]
name = "dep"
version = "0.1.0"

[dependencies]
cargo-cache = { git = "https://github.com/matthiaskrgr/cargo-cache",rev ="bla"}

Steps
If I run cargo fetch, it seems that the repo is always redownloaded even if it is already present in the cargo download cache ( ~/.cargo/git/db/cargo-cache-16826c8e13331adc).
Finding the rev will fail right after:
error: failed to load source for a dependency on `cargo-cache`

Caused by:
  Unable to update https://github.com/matthiaskrgr/cargo-cache?rev=bla

Caused by:
  revspec 'bla' not found; class=Reference (4); code=NotFound (-3)

Possible Solution(s)
Don't reclone the repo since it is already present.
Output of cargo version:
cargo 1.38.0-nightly (e853aa976 2019-08-09)

Attempted this in https://github.com/rust-lang/cargo/pull/7272 but turns out this directly conflicts with https://github.com/rust-lang/cargo/pull/5110. Since handling corrupt repos gracefully is generally the higher priority here, I'm going to close this because I think unfortunately there's not much we can do.

authors: alexcrichton matthiaskrgr


text:
Add check to not doc-scrape proc-macro units. Fixes #10571.

What does this PR try to resolve?
This PR fixes #10571, where the new doc-scrape feature panics when asked to scrape a proc-macro library. A missing check was added to create_bcx.
How should we test and review this PR?
A corresponding unit test has been added to demonstrate the fix.

r? @weihanglo

Closing this in favor of #11430.


text:
Improve diagnostics for multiple native links for the same package

r? @alexcrichton

addressed

@bors: r+ abedcdb6c94f60a20e11a194cdcc428610d65dad

:hourglass: Testing commit abedcdb with merge 38ea36b...

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

authors: Manishearth alexcrichton bors


text:
Add support for publish to optionally take the index that can be used

This form part of alternative-registries RFC-2141, it allows crates to optionally specify which registries the crate can be be published to.
@carols10cents, one thing that I am unsure about is if there is a plan for publish to still provide index, or for registry to be provided instead. I thought that your general view was that we should move away from the index file. If we do need to map allowed registries to the index then there will be a small amount of extra work required once #4506 is merged.
@withoutboats, happy for this to be merged into your branch if you want, the main reason I did not base it on your branch was due to tests not working on there yet.

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

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

Looks great! I think I'd like to try to throw this in with https://github.com/rust-lang/cargo/pull/4506 though as we'll want to be sure to feature gate the acceptance of a list of strings here I believe (and the feature gate bits were added in that PR)

It looks like #4506 is getting close to merge, so maybe that should be merged, then I will add in feature gating to this PR when I merge the changes in.

Ok sure yeah, either way's fine by me

I think we should probably merge #4506 separately. I have some big picture concerns about how we're handling publishing in general, which we're talking about on #4574, but also these smaller concerns:
I think this list should take registry names (as will be introduced in #4506), not index URLs, as @cswindle mentioned doing in the first comment. In general we're moving away from users dealing with index URLs as much as possible.
There's also the issue with passing registry.token raised in #4574. Basically, I think we should never pass registry.token to any registry tracked through one of those registries objects. I don't have an opinion about how you could declare an alternative token for those registries, either just add another key to the object (alongside index) or something with cargo/credentials, etc.

In the case of providing a registry that we want to use in publish, I actually wonder if we should just make a minor tweak to registry_configuration to pass in the registry (if provided) and look up the "registry..token" in the config, otherwise just get "registry.token". That way we can cross off the issue to support multiple registry tokens.

@cswindle ah yeah it was my expectation that registry.token is basically synonymous with registry.crates-io.token (but not used for other registries)

@alexcrichton I presume that is not something that would need to be done in an rfc and could just be implemented as part of this pull request (assuming resolution of #4574 is that we want to be able to push to private registries).

@cswindle indeed yeah!

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

Looks great! For now as well, could this be gated on the same alternate registries feature in the manifest?

@alexcrichton, now that the alternate registries has landed I was planning on updating this to be gated on the feature in the manifest. I have been taking a look into adding support for --registry for publish and login and if that is available it actually makes the code to perform the registry lookup easier (assuming that it is ok to mandate that if you want to push to alternate registry you use --registry rather than --index), so I might try and get that in first.

@cswindle ok sounds great! I think with a --registry argument we can definitely deprecate --index (which only ever existed for Cargo's own test suite anyway)

See #4680 for the PR to add --registry support.

I have now merged in my changes to add support for this. I am aware of the following two issues from further testing of this:

[ ] unable to publish when there are dependencies in another registry
[ ] we do not currently set the registry field in the index

I am in the process of sorting these last couple of bits out, so think it would make sense to do so in this pull request, rather than having another to do the last couple of bits.

I believe that this should now allow publishing and can be reviewed.

@alexcrichton, I have updated the code for most of the review comments, there are a couple where I have not updated, but in those cases I have explained why in the comments.

r? @withoutboats
I think you'll want to take a final pass here

@bors: r+
Sorry to take a while to review. This all looks good to me, no further changes. needed :)

:pushpin: Commit cb37d33 has been approved by withoutboats

:hourglass: Testing commit cb37d335fc6046b4658746cf831a0cc66d45b66e with merge 6a1aee06680d8f074a25431c938c42d7e8d0ab4e...

:sunny: Test successful - status-appveyor, status-travis
Approved by: withoutboats
Pushing 6a1aee06680d8f074a25431c938c42d7e8d0ab4e to master...

authors: alexcrichton bors cswindle rust-highfive withoutboats


text:
Disable frozen_flag_preserves_old_lockfile test

r? @alexcrichton cc @matklad

Before we do this, I'd want some confirmation that we haven't actually somehow regressed behavior here. This test is critical to Rust today: we cannot run crater due to lockfile differences if it fails.
In general, this (IMO) is P-high to re-enable if we do disable it IMO.

Before we do this, I'd want some confirmation that we haven't actually somehow regressed behavior here

Whether we've regressed behaviour or not, this test is still buggy and having the buggy test present isn't preventing any behaviour regressing, it's just blocking other code landing (which would fix an important regression).

Yeah, that's true. I think we can actually mark the test as #[ignore] instead of commenting it out. Unfortunately, this can't land until https://github.com/rust-lang/rust/issues/46271 is fixed AFAICT.
I guess I'm okay with landing even without confirming, but I'd prefer that we confirmed. Either way, I guess, it's a high priority thing to fix this test.

I've found the failure, will submit a fix shortly.

Ok I've opened up https://github.com/rust-lang/cargo/pull/4762 with what I believe is the fix. I'm gonna close this for now but if that doesn't fix it we can reopen an temporarily disable!

authors: Mark-Simulacrum alexcrichton nrc


text:
Fix env/cfg set for cargo test and cargo run.

There are some situations where a build script may need to run multiple times for the same package during the same cargo session.  There was a bug in that some of the values in the Compilation struct didn't handle this case.  The solution here is to be more careful about how this extra data is associated with Units, instead of assuming a package's build script only runs once.
The things that were not being handled properly:

Compilation::extra_env, which is the output of cargo:rustc-env in build scripts.  The solution here is to use the Metadata hash which is used elsewhere for distinguishing build script outputs.
Compilation::cfgs, which is the output of cargo:rustc-cfg in build scripts and the features to be set, and this is only used for doctests.  The solution here is to just add those --cfg flags directly in the Doctest struct.

The situations that cause a build script to be run multiple times:

A package needed for both the host and target.  In the test here, this was accomplished with a proc-macro (which has to be host) and a cyclical dev dependency, but there are many other ways to trigger this.
Something built with different features (with the new feature resolver), usually due to host/target differences.
Something built with different profile settings, usually due to host/target differences.

Fixes #9100

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

I was also wondering if we should update the documentation for how environment variables are set for cargo test and cargo run.  Perhaps just a note that says certain environment variables (such as cargo:rustc-env) are also set for running executables for cargo test and cargo run, but that it is not recommended to rely on that since it ties the executable to Cargo's execution environment?  Or maybe just leave it undocumented?

Looks good to me, thanks!
I think it makes sense to go ahead and document this but discourage usage. We've already got users depending  on it (probably accidentally?) so I don't think that we can change it anyway. If you'd prefer to do doc updates in a future PR that's ok too, r=me on this regardless.

Ok, I added a small note.  Thanks Alex! 😄
@bors r=alexcrichton

:pushpin: Commit 1607a68e92659a687892a49a463d06e3576b057f has been approved by alexcrichton

:hourglass: Testing commit 1607a68e92659a687892a49a463d06e3576b057f with merge 3875bbbba4c2c47bb518171066c8d643c0edcbc8...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 3875bbbba4c2c47bb518171066c8d643c0edcbc8 to master...

authors: alexcrichton bors ehuss rust-highfive


text:
yew_styles 5.0 is still not publish in docs.rs and I released almost 2 days ago

I released the version 5.0 yew_styles almost 2 days ago and usually the create only get two or three hours to be published in docs.rs. i don't know if there was something wrong but when I published the new version I didn't get any error and now the new version docs doesn't exist, only show the previous versions.
crate: https://crates.io/crates/yew_styles
command to publish: cargo publish --target wasm32-unknown-unknown --all-features
github: https://github.com/spielrs/yew_styles/tree/master/crate/yew_styles

I built on my local docs.rs and it published fine (though the doc build itself failed because of missing features, I suggest you add metadata to your package to enable all-features, set the default target to wasm32-unknown-unknown, and disable other targets; but that should still result in getting a page saying that the build failed).
Looking at the metrics something happened a couple of minutes (2020-06-11T23:39Z) after this was published (2020-06-11T23:37Z), but comparing the index commits and the queue size it looks like it was added to the queue right on time, and I don't see anything that makes it look like there were issues around when it should have been built (~2020-06-12T00:50Z based on builds from either side in the index).
@pietroalbini or @jyn514 can requeue the doc build (and it'd be great to check if there's anything in the logs around those timestamps).

I can release 0.5.1 with all you suggestions but maybe I should wait until they can check if there is anything in the logs because could be there is someway which I don't need to release again however for the next releases I will follow your recommendations.

These are the logs:
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: running `Command { std: "/home/cratesfyi/workspace/cargo-home/bin/cargo" "+nightly" "fetch" "--locked" "--manifest-path" "Cargo.toml", kill_on_drop: false }`
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr] error: failed to download `yew v0.16.2`
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr]
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr] Caused by:
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr]   unable to get packages from source
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr]
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr] Caused by:
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr]   failed to parse manifest at `/home/cratesfyi/workspace/cargo-home/registry/src/github.com-1ecc6299db9ec823/yew-0.16.2/Cargo.toml`
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr]
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr] Caused by:
Jun 12 00:50:07 docsrs cratesfyi[16410]: 2020/06/12 00:50:07 [INFO] rustwide::cmd: [stderr]   readme file with name '../README.md' was not found

This looks like the same issue as https://github.com/rust-lang/docs.rs/issues/832, I'll queue a rebuild.

Oh, 🤦 I looked at the version on the builds from either side to see if it might be related to that, but forgot that the rustc version and the nightly date are off-by-one.

The build finished successfully and failed like nemo said: https://docs.rs/crate/yew_styles/0.5.0/
Going to close this since we fixed the bug on our end, let us know if you need help getting it to build.


text:
split libs review rotation in two

The libs team discussed how we could improve review bandwidth for libs vs libs-api PRs and came to the conclusion that the best first step would be to separate the review rotations.
The goal of this split is to allow team members to focus on subsets of library work that they're most interested in and to allow independent growth of the review rotation focused on non-API affecting changes (aka libs PRs vs libs-api PRs). The libs APIs are generally less common, easier to review, often more time sensitive, and a much better entry point for new contributors interested in participating in the libs team. These properties make this an ideal starting point for new libs reviewers and contributors. By splitting the review rotations and focusing on increasing review bandwidth for non-API changes we can make this contribution experience more pleasant which will encourage repeat contributors and increase how much important bug fix / perf improvement / doc improvement style work we get done as a team.

This would end up assigning all library PRs to libs due to this dirs mapping:

That was my intent, I figured as a starting point we could rely on the libs, team to reassign to libs-api when appropriate.

Maybe highfive could comment on library PRs instructing that if the PR contains a new library API or contains a stabilization of a library feature that has not already completed FCP in its tracking issue, then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api

That sounds like a great idea! I think there's a message field so I'll set that up.

I wonder if this will work...
r? @Mark-Simulacrum

Looks good with the conflict fixed.

authors: Mark-Simulacrum yaahc

repo: rust-lang/highfive


text:
unix: add strndup()

Add strndup(), as specified by POSIX.1-2008.

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

The failure is unrelated but some jobs were skipped. Could you rebase to make sure things?

authors: JohnTitor NeoRaider rust-highfive

repo: rust-lang/libc


text:
Update comment to clarify

redundant_semicolons reaches the latest stable but I noticed we run CI for old rustc e.g. 1.30.0.

@JohnTitor: no appropriate reviewer found, use r? to override

authors: JohnTitor rust-highfive


text:
Remove link directives for libutil on linux-gnu targets

These are all handled in src/unix/mod.rs now, which also addresses the
crt-static case; no linux-gnu target should have any link directives in
any other module.
This fixes static linking with glibc for various architectures.

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

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

r? JohnTitor

r? JohnTitor

r? @JohnTitor

r? @JohnTitor

@bors r+

@bors r+

:pushpin: Commit 6859d47e78c44eae0b9ffed1e2031ecdf8bf3152 has been approved by JohnTitor

:pushpin: Commit 6859d47e78c44eae0b9ffed1e2031ecdf8bf3152 has been approved by JohnTitor

:hourglass: Testing commit 6859d47e78c44eae0b9ffed1e2031ecdf8bf3152 with merge 80c9e12c6b50ac290a82975d3d63763d3c388c59...

:hourglass: Testing commit 6859d47e78c44eae0b9ffed1e2031ecdf8bf3152 with merge 80c9e12c6b50ac290a82975d3d63763d3c388c59...

:broken_heart: Test failed - checks-actions

:broken_heart: Test failed - checks-actions

Failure looks like a transient network issue. Retrying.
@bors retry

Failure looks like a transient network issue. Retrying.
@bors retry

:hourglass: Testing commit 6859d47e78c44eae0b9ffed1e2031ecdf8bf3152 with merge 0dce92d89b8d1451caf752639f55968c0221ea00...

:hourglass: Testing commit 6859d47e78c44eae0b9ffed1e2031ecdf8bf3152 with merge 0dce92d89b8d1451caf752639f55968c0221ea00...

Looks like we're now hitting https://github.com/rust-lang/cargo/issues/9101 , which was caused by a change in serde.

Looks like we're now hitting https://github.com/rust-lang/cargo/issues/9101 , which was caused by a change in serde.

https://github.com/rust-lang/libc/pull/2048 should fix the CI issue.

https://github.com/rust-lang/libc/pull/2048 should fix the CI issue.

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing 0dce92d89b8d1451caf752639f55968c0221ea00 to master...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing 0dce92d89b8d1451caf752639f55968c0221ea00 to master...

authors: JohnTitor bors joshtriplett rust-highfive


text:
Fix futex with large timeout ICE

Fixes #3647.
This PR changed the type of nanoseconds from u64 to u128. In duration_since, nanoseconds is manually converted to second by dividing it with 1e9. But overflow is still possible.

Initially there is a test, but it took way too long for ./miri test to finish, so I removed it. But surprisingly, it completed fairly fast in ./miri run --dep ./tests/pass-dep/concurrency/linux-futex.rs.
Test:
// Reproduce https://github.com/rust-lang/miri/issues/3647. This should not ICE.
fn large_timeout() {
    let futex: i32 = 123;

    unsafe {
        libc::syscall(
            libc::SYS_futex,
            addr_of!(futex),
            libc::FUTEX_WAIT,
            123,
            &libc::timespec { tv_sec: 184467440839020, tv_nsec: 117558982 },
        );
    }
}

The linux-futex test became very slow after this new commit?

@rustbot author

@rustbot ready

Looks good, thanks!
@bors r+

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

:hourglass: Testing commit f2c5071b09aef74906c202c7617b20111b563c0b with merge e09827881fb388b8012a6c3c021d357ead61507d...

Thanks, but no squashing? The commit messages are not very neat.

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

Ah yeah, I forgot about that oops

Hmm how the unmerge works? Should I open a new pr with the squashed commits?

No, it's too late. Once this landed it can never be un-done.

authors: RalfJung bors tiif

repo: rust-lang/miri


text:
serde derives

Unless this crate needs to remain exactly as-is to be added to std, I believe that serde derives for Serialize and Deserialize should be added behind a feature gate. This would be quite helpful in my case where I have a data structure that abstracts over both packed_simd primitives and some normal numbers, but only implements those traits if the type it contains also implements them. I could create wrapper types around packed_simd, but I want to see if this would be accepted upstream first.

Hello. I'm a member of the new Portable SIMD Project.
Going forward, the project group will be developing a stdsimd crate, which will be eventually be stabilized within the standard library under core::simd and std::simd. The design of stdsimd will likely be similar to the packed_simd crate in terms of practical usage, but there will inevitably be small changes in the transition.
Of course, this will take quite a bit of time to develop and stabilize. Accordingly, the project group will take over maintenance of the packed_simd crate, and we will at least ensure that it keeps building.
Broadly speaking, we are not planning to develop packed_simd any further. It should be considered to be in long-term maintenance mode, and when stdsimd is eventually stabilized then packed_simd will become completely deprecated.
At that time, serde will be able to add impls for the new SIMD types the same as it has impls for other core types like f32 and i64 and such. You won't even have to derive anything yourself.

We're trying to triage the issues a bit, so I'm going to close this. For more questions, you can post to the Portable SIMD Project Group Zulip. If you've never used the zulip before it'll ask you to log in, but you can sign in with your GitHub account, so you don't need to do any new account setup stuff.

authors: Lokathor vadixidav


text:
Support avx512 bitmasks with dynamic feature detection

The choice between full_masks.rs and bitmask.rs seems to be made at compile time (https://github.com/rust-lang/portable-simd/blob/9bd30e77b3a3c699af102ebb3df0f6110f8aa02e/crates/core_simd/src/masks.rs#L5) based on compile-time presence of the avx512f target feature.
When compiling for general x86-64 targets but doing runtime feature detection for avx512f, the current approach will generate suboptimal code for avx512, because it will use the full_masks.rs implementation instead of the bitmask.rs implementation.
I'd like to be able to use bitmasks in avx512 even when using runtime feature detection. It's probably out of scope (and, I think, undesirable) for std::simd to be responsible for runtime feature detection, so one option would be for std::simd to be refactored to expose both Mask and Bitmask as two separate types -- perhaps both implementing the same set of traits. This way, callers could choose between a full-mask implementation and a bitmask implementation based on whatever logic they choose, including e.g. runtime feature detection.

Actually looking through the implementation of bitmask.rs, I see that in avx512 mode, Mask<T, LANES> is just a wrapper for LANES::BitMask, which is already accessible to users. So I guess the answer to my request is already available: it is "use LANES::BitMask if you want a guarantee of single-bit-per-lane". Perhaps some additional documentation is all that is required.

It's worth noting that when compiling for instruction sets that use bitmasks, the compiler often optimizes these lane-width masks to bitmasks (as far as LLVM is concerned, all masks are truncated to bitmasks anyway).  The layout matters less than you might think--only when writing masks to memory or general purpose registers to use them outside of SIMD operations, which is relatively rare.

That's a really great point Caleb, and I think it pretty much entirely addresses my concern. Thanks!

authors: calebzulawski reinerp

repo: rust-lang/portable-simd


text:
Restrict Arm types to Arm v7+

This mostly mirrors the restrictions in std::arch.
It can be loosened slightly with later refactoring.

I guess this is an unfortunate limitation of rustc, since you should be able to write neon in older arm binaries and do runtime dispatch.  Looks fine to me, though. (Looks like fmt failed)

Unfortunately, making all of this valid for Arm architectures prior to Arm v7 seems likely to require edits to std::arch's definitions. We will want to add a check build for cross-compiling to various Arm targets, it seems like.

authors: calebzulawski workingjubilee


text:
Cargo install has no way of upgrading

It'd be nice if there were a cargo install --upgrade or similar flag that would cargo install --force a crate if its version has been bumped. This could be configured to only allow major, minor, or bugfix releases.

I just had to deal with this again yesterday...
It would also be kind of nice to have cargo update similar to rustup update

cc https://github.com/rust-lang/cargo/issues/2082

FWIW, there's a (non official) Cargo subcommand that does this.

@japaric that's nice (it doesn't always compile tho...), but this should really be part of cargo proper and not relegated to a subcommand.

Some related things I'd like from cargo:

list of installed things
versions of installed things and whether there are updates
ability to upgrade multiple things

I try to move toward repository versions of things once they land (e.g. ripgrep), but sometimes that's just not going to happen (e.g. cargo subcommands). I like to stay up-to-date (mostly for latest bugfixes), and it would be nice if there was a simple command I could run to update everything, or at least give me a list of stuff to update.
This probably belongs in a separate RFC, but I feel it's relevant to the discussion here and I'd like to see resolution on this before submitting a separate RFC.

@beatgammit https://crates.io/crates/cargo-update has all of that.

Sweet, thanks! In that case, I'm on board with not doing this in cargo to highlight that it's not meant for managing packages.
Honestly, cargo install --list already solves my first bullet point and half of the second, and I can always do cargo search to manually check for versions of things. The only think I may add is having cargo install --list check the registry cache for updated versions, but that's really it.

to highlight that it's not meant for managing packages

Is this still true? cargo is used by a number of programs as an installation tool. Why should it not be in the business of package management?

to highlight that it's not meant for managing packages

Is this still true? cargo is used by a number of programs as an installation tool. Why should it not be in the business of package management?

When cargo install is run on something that is already installed it now looks to update.

#9527 further expands on this to include updating all installed packages

authors: Centril Eh2406 beatgammit clarfonthey est31 japaric mark-i-m nashley steveklabnik

repo: rust-lang/rfcs


text:
Arrays should impl the bitwise operations

I have a couple [u8; 8]s that I'd like to xor with each other. Unfortunately this doesn't work:
let x = [0u8; 8];
let y = [1u8; 8];
let z = x ^ y;

I think it should, since this has pretty clear semantics. More generally I think it would make sense to have an impl:
impl<const N: usize, A, B> BitXor<[B; N]> for [A; N]
where
    A: BitXor<B>,
{
    type Output = [<A as BitXor<B>>::Output; N];

    fn bitxor(self, rhs: [B; N]) -> Self::Output {
        ...
    }
}

And similar for BitAnd and BitOr.

Eh.  One should then ask, "why bitwise ops but not + and *?"  And I really don't want to see * implemented on arrays, as arrays are a common choice for mathematical vectors (where elementwise multiplication is a rare and unusual operation).
Arrays seldom show up in public APIs in Rust.  I'd imagine that, most likely, if you are using arrays somewhere, you can easily substitute them out with wrapper types that implement the desired operations.

It's maybe reasonable because bitwise operations have clear semantics, while even primitive types make + confusing, and * gets even worse.

I think this is something a crate should offer, not the standard library, because as already said, mathematical operations are easy to misunderstand that they would really do.

Yeah, I wouldn't advocate for + or * to be implemented on arrays - would it work element-wise? Would the results overflow to the next element (treating the whole array as one giant int)? Would multiplication be a dot product? Would it return a matrix of results? There's no single, obvious semantics here.
For bitwise operations though there is a single obvious semantics. Bitwise operations already work element-wise (which is why they're implemented for types like HashSet and BTreeSet). I can't imagine anyone getting confused by the semantics of this or expecting a different semantics.

Or to put it another way: the bitwise operations aren't really mathematical operations. They're operations on collections of bools of the shape.

Are there any bugs likely to arise from this when refactoring from a primitive to an array of primitives?  I do not see any right now, but maybe someone else does?

If we were to have map and zip and such over arrays in the standard library, would that be sufficient for this?  Then you could let z = x.zip_with(y, BitXor::bitxor);, and similar.

I'd think so..
impl<X, const N: usize> [X; N] {
    pub fn map<Y,F>(self, f: F) -> [Y; N]
    where F: FnMut(X) -> Y;

    pub fn zip<Y,F>(self, ys: [Y;N]) -> [(X,Y); N];

    pub fn zip_with<Y,Z,F>(self, f: F) -> [Z; N]
    where F: FnMut(X,Y) -> Z;
}

We'd maybe only want new methods of the form -> [??, N] right?  I'm wondering if for works better than any in place methods, ala
impl<X, const N: usize> [X; N] {
    pub fn assign<F>(&mut self, ys: &[Y; N], f: F)
    where F: FnMut(&mut X, &Y);

    pub fn assign_mut<F>(&mut self, ys: &mut [Y; N], f: F)
    where F: FnMut(&mut X, &mut Y);
}

There should also be try_map

On modern systems, e.g. amd64 with SSE
let x = [0u8; 16];
let y = [1u8; 16];
let z = x ^ y;

could be optimised as a single instruction, while implementing it by hand produces some overhead. IMHO a default-implementation of operands like + - & | ^ is a good idea, even if a generic implementation is not that sophisticated. Allowing some syntactic sugar for saturating arithmetic might be good too.
On the other hand multiplications on vectors/matrices in mathematics is different to just multiplying each element of both input-slices together which might result in confusion, but I guess this is the wrong RFC for suggesting new mathematical operands like cross and dot products. (^.^ )
But there is a generic but unstable SIMD-module, perhaps this might be useful someday:
let x = u8x16::splat(23u8);
let y = u8x16::splat(42u8);
let z = [0u8; 16];
(x ^ y).store_aligned(&mut z);
// or, if you want to do more of this stuff with z anyway
let z = x ^ y;

Using this SIMD-instructions a dedicated lib could provide this feature in an elegant way.

Perhaps implement std::ops::BitXor for array of integers.

@canndrew

For bitwise operations though there is a single obvious semantics. Bitwise operations already work element-wise (which is why they're implemented for types like HashSet and BTreeSet). I can't imagine anyone getting confused by the semantics of this or expecting a different semantics.

The bitwise operations for HashSet and BTreeSet do not apply the operations element-wise, they're used for intersection, union and symmetric difference. So, ironically, you got confused by the semantics of this yourself...

@konsumlamm: Intersection, union and symmetric difference are &, | and ^ respectively on the bools representing whether an element of the type is included in the set.
A more formal way to think about this is that a HashSet<T> is a total map of the form T -> bool. By operating "element-wise" the bitwise operations operate on those bools. By analogy, a [T; N] is a total map of the form Fin(N) -> T (where Fin(N) is the type of numbers less than N). So by operating "element-wise" the bitwise operations would operate on those Ts.

authors: ExpHP burdges canndrew hellow554 konsumlamm lzutao scottmcm sivizius


text:
cfg meta variables

It's quite often that a cfg directive in an attribute becomes fairy complicated when support for more platforms are added. Even worse, a cfg block is then often duplicated among many locations to configure off different items.
The thread_local/mod.rs file is a good example of the amount of duplication.
It would be nice to have something like the following
#![cfg_shortcut(foo, any(super, long, clause))]

#[cfg(foo)] ...
#[cfg(not(foo))] ...

Here the clause any(super, long, clause) would be shortened to the identifier foo which could then be used elsewhere. In general it would just be nice to make these long cfg directives much shorter and less error prone to copy-paste.

Yeah this would be nice. This and bounds aliases from #804 should give us a more complete aliasing toolkit.

If we expand macros within attributes, then this feature would drop out as a special case.
For example:
macro_rules! foo {
    () => (any(super, long, clause))
}

#[cfg(foo!())] ...
#[cfg(not(foo!()))] ...

Users wouldn't need to learn special syntax either -- just apply their existing macro knowledge.

authors: alexcrichton blaenk lfairy