text:
Disabling required extension doesn't work from child config

Hi!
It looks like disabling an extension required in parent config doesn't work from the child config.
Assuming we have parent-child configs relationships as following:
Parent, which is shared among many other projects:
require:
  - rubocop-rspec
  - rubocop-rails
...

Child, in particular project which doesn't use rspec:
inherit_from: shared/.rubocop.yml

RSpec:
  Enabled: false
...

Runtime details:
ruby 2.5.1p57
rubocop (0.74.0)
rubocop-rails (2.2.1)
rubocop-rspec (1.35.0)

Expected behavior
Definition in the child config should take precedence over required directive.  So the expected behavior would be to suppress all violations related to disabled extension.
Actual behavior
Running Rubocop in debug mode produces the following info:
$ rubocop -E -S -d --format simple

For /: configuration from /.rubocop.yml
Inheriting configuration from /example/.rubocop.yml
configuration from /usr/local/bundle/gems/rubocop-rspec-1.35.0/config/default.yml
configuration from /usr/local/bundle/gems/rubocop-rspec-1.35.0/config/default.yml
Default configuration from /usr/local/bundle/gems/rubocop-0.74.0/config/default.yml
configuration from /usr/local/bundle/gems/rubocop-rails-2.2.1/config/default.yml
configuration from /usr/local/bundle/gems/rubocop-rails-2.2.1/config/default.yml
For /example configuration from /example/.rubocop.yml
AllCops/Exclude configuration from /.rubocop.yml
Inheriting configuration from /example/.rubocop.yml

and some violations detected for rspec extension (reduced for clarity):
== example/spec/runner_spec.rb ==
C: 32:  7: Example has too many lines [6/5]. (http://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/ExampleLength)

As a result it reduces the power of the configs inheritance as soon as you have an extension used by all but a few children.
Important note
It does work as expected if disabling happens in the same parent file. For example:
Parent:
require:
  - rubocop-rspec
  - rubocop-rails

RSpec:
  Enabled: false
...

Child:
inherit_from: shared/.rubocop.yml
...

Works as expected (rspec related violations are being suppressed).

@aliaksandrb Thanks for your report. Could you put together a complete example? I tried to reproduce your issue with the information given but failed. See here: https://github.com/buehmann/rubocop-issues/tree/7640
➜  rubocop-issues (7640) bundle exec rubocop
Inspecting 2 files
..

2 files inspected, no offenses detected

and when I enable the RSpec department in .rubocop.yml:
➜  rubocop-issues (7640) ✗ git diff
diff --git a/.rubocop.yml b/.rubocop.yml
index fd57358..4a111f4 100644
--- a/.rubocop.yml
+++ b/.rubocop.yml
@@ -1,4 +1,4 @@
 inherit_from: shared/.rubocop.yml

 RSpec:
-  Enabled: false
+  Enabled: true
➜  rubocop-issues (7640) ✗ bundle exec rubocop
Inspecting 2 files
.C

Offenses:

spec/runner_spec.rb:4:3: C: RSpec/ExampleLength: Example has too many lines [11/5].
  it 'foo' do ...
  ^^^^^^^^^^^

2 files inspected, 1 offense detected

Hi @buehmann, thanks for looking into it!
I've played around with your repository and found the difference with my setup, which had shown that the problem tends to be on my side.
In fact, my directory structure is more complicated and looks like rails one (meta gem with multiple gems within it). And between the root /.rubocop.yml and /xxx/yyy/spec/runner_spec.rb file there is /xxx/.rubocop.yml which has no
RSpec:
  Enabled: false

I was thinking that rubocop adopts config relative to the $pwd it being ran, but it looks like it checks the closest config relative to the every file being analyzed (wow, thats a lot of parsing if you have a mono-repo with many configs).
So my fault, works as expected 👌 I am closing this issue.

Good to hear that. Yes, it is the closest config that is relevant for every file, but RuboCop makes sure to parse every config only once. That config is then reused for all files checked in the subtree (unless there is another config in a subdirectory, of course).

authors: aliaksandrb buehmann


text:
Allow customizing --disable-uncorrectable to output rubocop:disable instead of rubocop:todo

Is your feature request related to a problem? Please describe.
At my company we use inline rubocop:disables relatively often and consider a lot of cops to be relatively noisy (for instance, using the method length cop as a nudge to double check something shouldn't be broken up but confidently disabling if we think a fat method is better in context) and also get a decent number of false positives. We do not mark them as a rubocop:todo because we generally have no intention of coming back to them. It is extremely rare for a disable to be an actual TODO but when it is, we can use rubocop:todo.
I've just learned about --disable-uncorrectable which is a great workflow win for some cases but unfortunately it outputs rubocop:todo since #7335. This is misleading since we generally do not consider these items a TODO and manually changing these to rubocop:disables negates the workflow win of the flag. I also value having uniformity in the syntax we use.
Describe the solution you'd like
It would be nice if there was a version of --disable-uncorrectable that output a rubocop:disable instead of a rubocop:todo. This could be changed by a config file, an argument passed to --disable-uncorrectable, an alias of the flag which outputs a rubocop:disable, or a reversion of the behavior change from #7335.
As an aside, I found it mildly surprising that a --disable-... command results in a todo.
Describe alternatives you've considered
I left multiple ideas above--all would be satisfactory. I have also considered doing some kind of sed awkwardness in an alias but I would prefer to have a first-class feature.
I have also considered just switching all our disables to todos but that negates the ability to annotate real todo.
Additional context
N/A

Should this issue be labeled as Good First Issue?
We are doing research about how to help newcomers onboarding in an open source project and how to accelerate the issue resolving process.
We have developed a tool to automatically label the Good First Issue (GFI), i.e., the issue which is good for newcomers.
We first extract 72 features from different dimensions of issue reports, such as readability, semantic meaning, associated code snippets, etc, and experimentally investigate to what extent these features correlate with GFI. Results turn out that a large portion of these features do have a medium to large correlation with GFI.
We then build a machine learning model based on these features to predict GFI. The experiments on a dataset of 12k issues from Github show that 0.90 AUC can be achieved.
Our tool shows that this issue has a very large possibility to be a GFI.
Could you please tell us whether it should be labeled as a GFI?
And if you have any comments or suggestions with this tool, could you please tell us?
Thank you so much.

source: gharchive/issue

authors: GG-Sheridan dgollahon

repo: rubocop-hq/rubocop

license: MIT

license_type: permissive

license_source: github-api


text:
[Fix #6393] Add AllowBracesOnProceduralOneLiners option to fine-tune behavior of Style/BlockDelimiters

This PR add the AllowBracesOnProceduralOneLiners option to the semantic style of Style/BlockDelimiters, in order to let the user specify that they want to allow braces on procedural one-line blocks but otherwise follow semantic block delimiters.

Thanks for working on this! I really appreciate it! 🙇And sorry for the (extremely) slow turnaround!

source: gharchive/pull-request

authors: bbatsov davearonson


text:
Invalid Lint/Syntax: unexpected token kEND

Aside: This is a conflict between trying to have 1 Test per file, a max of 5 lines per test, and using this modifier.
Expected behavior
No issue, when using (albeit very rare), rescue inside an it block for RSpec
Actual behavior
spec/site_prism/loadable_spec.rb:186:1: E: Lint/Syntax: unexpected token kEND
(Using Ruby 2.4 parser; configure using TargetRubyVersion parameter, under AllCops)
end

Steps to reproduce the problem
      it 'does not call other load validations after failing a load validation' do
        expect(instance).not_to receive(:valid2?)

        instance.when_loaded
      rescue SitePrism::FailedLoadValidationError
        :no_op
      end

RuboCop version
$ [bundle exec] rubocop -V
0.85.1 (using Parser 2.7.1.4, rubocop-ast 0.0.3, running on ruby 2.7.1 x86_64-linux)

spec/site_prism/loadable_spec.rb:186:1: E: Lint/Syntax: unexpected token kEND
(Using Ruby 2.4 parser; configure using TargetRubyVersion parameter, under AllCops)
end

$ [bundle exec] rubocop -V
0.85.1 (using Parser 2.7.1.4, rubocop-ast 0.0.3, running on ruby 2.7.1 x86_64-linux)

Can you specify TargetRubyVersion: 2.7 in .rubocop.yml?
https://docs.rubocop.org/rubocop/0.87/configuration.html#setting-the-target-ruby-version
And rescue in a block has been introduced in Ruby 2.5, so cannot be interpreted by Ruby 2.4.

I took a look at site_prism gem. For Ruby 2.4 support, please specify TargetRubyVersion: 2.4, and begin ... rescue  in block should be used.
https://github.com/site-prism/site_prism/blob/59a165467c19981d0697bb0493e87ef76b89f1e4/site_prism.gemspec#L8

Hmmmm, ok. I'm not quite sure how this issue is coming through then. Must be version conflicts then from somewhere? Give me a couple of days and I'll get back to you.

Ruby 2.4 is no longer supported by RuboCop so I am closing this.

authors: dvandersluis koic luke-hill

repo: rubocop/rubocop


text:
Fix Layout/ClosingParenthesisIndentation for keyword splat arguments

Fixes #11483.
We need to check all the hash children nodes (not only pairs).
$ ruby-parse -e 'foo(x: 1, **options, y: 2)'

(send nil :foo
  (kwargs
    (pair
      (sym :x)
      (int 1))
    (kwsplat
      (send nil :options))
    (pair
      (sym :y)
      (int 2))))

Thanks!

authors: fatkodima koic


text:
Fix a false positive for Lint/FormatParameterMismatch when format string is only interpolated string

This PR is Follow up: https://github.com/rubocop/rubocop/pull/11464#issuecomment-1400880819

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[-] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks for the quick fix!

authors: hmcguire-shopify ydah


text:
Drop Ruby 2.6 runtime support

This PR drops Ruby 2.6 runtime support. The next release will be the time to drop Ruby 2.6 support:

https://www.ruby-lang.org/en/downloads/branches/
https://docs.rubocop.org/rubocop/compatibility.html#support-matrix

CRuby 2.6 compatible JRuby 9.3 will be dropped and CRuby 2.7 compatible JRuby 9.4+ is required.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Looks good. Thanks!

Note that Ruby 2.6 is still the system ruby version on the latest macos: https://apple.stackexchange.com/questions/107853/which-versions-of-mac-os-x-have-ruby-installed-by-default/107974#107974
Thus, this introduces complications for projects like Homebrew that target system ruby on macos systems. In light of this, would the rubocop folks consider extending support a bit longer than might be typical of EoL Ruby versions?

Why would Homebrew need to run RuboCop on Ruby 2.6? Normally you run it for some just CI env and you specify the Ruby version that you target (e.g. 2.6).

authors: bbatsov dduugg koic


text:
Enable returning 204 No Content

Per the readme, a formatter must supply a content type. However, when sending an empty response body, no content type is wanted at all.
Related issue is #215. As far as I see even with my own formatter I cannot return empty response bodies/204 no content.

I realize this is closed, but I wanted to share an issue I just ran into the hard way.
Apparently, @body = nil will cause errors if you're using Rack::Lint.
ERROR -- : app error: Body yielded non-string value 204 (Rack::Lint::LintError)
Reason being that, it would seem, the Rack spec does not precisely follow HTTP spec.  There is some dissent on the matter, as seen in a related issue (no content-type for empty body) here:
https://github.com/rack/rack/issues/472
But the spec states:

The Body must respond to each and must only yield String values. The Body itself should not be an instance of String, as this will break in Ruby 1.9.

https://github.com/rack/rack/blob/master/SPEC#L244-L248
This just came up, I'll be solving it tomorrow, I suspect @body = [] or @body = {} should fix it, as appropriate.
I hope this helps someone else.

My question in rack#472 remained unanswered btw.

@dblock oh, haha, I hadn't even noticed that was you.  Now I'm not sure if I'm right about this, turns out I had a bigger issue going on - has this been your experience, do I need to return [] or is nil actually OK?

I guess the answer is "I am not sure"...

The issues mentioned above looks unrelated
first,

@body = nil
do I need to return [] or is nil

From the perspective of Grape user, you should use '' because Grape wraps body value in an array that is needed to Rack. Moreover, from the perspective of Rack user, nil value should be converted to '' implicitly by Grape as Rack has strict requirements mentioned above.

as for 405 Not Allowed

@dblock says Rack::Lint is not doing the right thing raising an error when there's no Content-Type with a 405

I agree, the spec says

The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the
message semantics.

and 405 Not Allowed

The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not
supported by the target resource.  The origin server MUST generate an
Allow header field in a 405 response containing a list of the target
resource's currently supported methods.

so it looks like the semantics of 405 response does not assume any resource representation

In (some of) my case(s), returning an empty array or hash is the more appropriate than a string - it's a case where I was returning a nil body and a 204 where I might otherwise be returning a collection.  An empty collection would make sense there.
Other cases, yeah, I guess an empty string.  It still bothers me a little, I don't like that Rack insists on this, it's weird.
As for grape converting a nil to '', are there cases where it's not feeding to rack, to something else instead?  If so, that should at least be a configurable option, because nil seems semantically more appropriate.

authors: dblock dm1try p-originate stephancom

repo: ruby-grape/grape


text:
[question] - Issue with language server

Hi Syntax Tree,
Heard about you on Remote Ruby, getting below after I installed the gem.
Ruby 2.5.0
Ruby Version: 2.5.0
VS Code: Version: 1.66.0 (Universal)
Starting language server...
No bundled syntax_tree, running global stree.
/Users/chriswade/.asdf/installs/ruby/2.5.0/lib/ruby/gems/2.5.0/gems/syntax_tree-2.0.1/lib/syntax_tree.rb:8:in `require_relative': /Users/chriswade/.asdf/installs/ruby/2.5.0/lib/ruby/gems/2.5.0/gems/syntax_tree-2.0.1/lib/syntax_tree/formatter.rb:12: syntax error, unexpected ... (SyntaxError)
    def initialize(source, ...)
                           ^~~

Ruby 2.7.4
Starting language server...
No bundled syntax_tree, running global stree.
/Users/chriswade/.asdf/installs/ruby/2.7.4/lib/ruby/gems/2.7.0/gems/syntax_tree-2.0.1/lib/syntax_tree/language_server.rb:28: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
/Users/chriswade/.asdf/installs/ruby/2.7.4/lib/ruby/gems/2.7.0/gems/syntax_tree-2.0.1/lib/syntax_tree/language_server/inlay_hints.rb:69: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
Requesting implicits
Requesting implicits
/Users/chriswade/.asdf/installs/ruby/2.7.4/lib/ruby/gems/2.7.0/gems/syntax_tree-2.0.1/lib/syntax_tree/language_server.rb:54:in `run': Unhandled: {:jsonrpc=>"2.0", :id=>1, :method=>"syntaxTree/implicits", :params=>{:textDocument=>{:uri=>"file:///Users/chriswade/Exercism/ruby/sieve/sieve.rb"}}} (RuntimeError)
	from /Users/chriswade/.asdf/installs/ruby/2.7.4/lib/ruby/gems/2.7.0/gems/syntax_tree-2.0.1/lib/syntax_tree/cli.rb:187:in `run'
	from /Users/chriswade/.asdf/installs/ruby/2.7.4/lib/ruby/gems/2.7.0/gems/syntax_tree-2.0.1/exe/stree:9:in `<top (required)>'
	from /Users/chriswade/.asdf/installs/ruby/2.7.4/bin/stree:25:in `load'
	from /Users/chriswade/.asdf/installs/ruby/2.7.4/bin/stree:25:in `<main>'
[Info  - 9:43:20 am] Connection to server got closed. Server will restart.

Ruby 3.0.0
Starting language server...
No bundled syntax_tree, running global stree.
Requesting implicits
/Users/chriswade/.asdf/installs/ruby/3.0.0/lib/ruby/gems/3.0.0/gems/syntax_tree-2.0.1/lib/syntax_tree/language_server.rb:54:in `run': Unhandled: {:jsonrpc=>"2.0", :id=>1, :method=>"syntaxTree/implicits", :params=>{:textDocument=>{:uri=>"file:///Users/chriswade/code/oe-qikpac-monitor/app/models/account_record.rb"}}} (RuntimeError)
	from /Users/chriswade/.asdf/installs/ruby/3.0.0/lib/ruby/gems/3.0.0/gems/syntax_tree-2.0.1/lib/syntax_tree/cli.rb:187:in `run'
	from /Users/chriswade/.asdf/installs/ruby/3.0.0/lib/ruby/gems/3.0.0/gems/syntax_tree-2.0.1/exe/stree:9:in `<top (required)>'
	from /Users/chriswade/.asdf/installs/ruby/3.0.0/bin/stree:23:in `load'
	from /Users/chriswade/.asdf/installs/ruby/3.0.0/bin/stree:23:in `<main>'
[Info  - 9:51:50 am] Connection to server got closed. Server will restart.

Thanks for putting this out :)
Regards,
Chris

Ahh sorry I updated the gem and forgot to update the vscode plugin. v0.2.1 of the plugin is out now and should have the fixes.

Thanks for that,
Still no go for repo's with Ruby 2.5.0 as version. ( image below ), other 2 are working
Also does it need any setup like below that I was using for rubocop ?
I don't seem to get any of the light blue squiggly lines suggesting things like I was with rubocop
Should I change ruby.format & ruby.intellisense to syntax.tree ( i'm guessing this )
{
  "editor.formatOnSave": true,
  "editor.formatOnType": true,
  //ruby start
  "[ruby]": {
    "editor.defaultFormatter": "misogi.ruby-rubocop"
  },
  "ruby.useLanguageServer": true, // use the internal language server (see below)
  "ruby.format": "rubocop", // use rubocop for formatting
  "ruby.intellisense": "rubyLocate",
  "ruby.useBundler": true,
  "ruby.lint": {
    "rubocop": {
      "useBundler": true
    }
  },
  "ruby.rubocop.suppressRubocopWarnings": false,
  "ruby.rubocop.onSave": true,
  "files.associations": {
    "*.erb": "erb"
  },
  "editor.codeActionsOnSave": {
    // For ESLint
    "source.fixAll.eslint": true,
    // For TSLint
    "source.fixAll.tslint": true,
    // For Stylelint
    "source.fixAll.stylelint": true
  },
  // RUBY END

}

Okay, a couple of things. Totally not your fault, the docs are definitely lacking.

First of all, this requires Ruby >= 2.7.3. So your EOL rubys aren't going to work. Sorry about that.
You don't need any setup, except you can set "ruby.format" to false. That configuration option is provided a different extension, so you should turn off its formatting so that syntax tree can take over.
There's no ruby.intellisense option for this plugin, since it's just for formatting.
So you don't get diagnostics with this extension. The function of this extension is just to format, not to lint.

repo: ruby-syntax-tree/vscode-syntax-tree


text:
Add types for config

Config helps you easily manage environment specific settings in an easy and usable manner.
refs: https://github.com/rubyconfig/config

/merge


text:
Bug: Prism::Translation::Parser breaks on numbered block params

Minimal example:
Prism::Translation::Parser.parse("find { _1 }")
fails with "undefined method `parameters' for @ NumberedParametersNode":
/home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/translation/parser/compiler.rb:1752:in `visit_block': undefined method `parameters' for @ NumberedParametersNode (location: (1,5)-(1,11)) (NoMethodError)
└── maximum: 1
:Prism::NumberedParametersNode

              block.body&.accept(copy_compiler(forwarding: find_forwarding(block.parameters&.parameters))),
                                                                                ^^^^^^^^^^^^
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/translation/parser/compiler.rb:244:in `visit_call_node'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/node.rb:2302:in `accept'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/compiler.rb:34:in `block in visit_all'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/compiler.rb:34:in `map'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/compiler.rb:34:in `visit_all'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/translation/parser/compiler.rb:1465:in `visit_statements_node'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/node.rb:16059:in `accept'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/compiler.rb:29:in `visit'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/translation/parser/compiler.rb:1289:in `visit_program_node'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/node.rb:14140:in `accept'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/translation/parser.rb:132:in `build_ast'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/prism-0.20.0/lib/prism/translation/parser.rb:47:in `parse'
	from /home/philip/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/parser-3.2.2.0/lib/parser/base.rb:33:in `parse'

Detected when trying to swap Prism::Translation::Parser in for whitequark's Parser::CurrentRuby in packwerk.

cc @kddnewton

Thanks @exterm! Fix is up

authors: exterm kddnewton

repo: ruby/prism


text:
Allow failures for arm64/ppc64le/s390x due to infra errors.

Allow failures for ppc64le/s390x due to the following infra errors.
https://app.travis-ci.com/github/ruby/prism/builds/271968231

No output has been received in the last 10m0s, this potentially indicates
a stalled build or something wrong with the build itself.

Allow failures for arm64 due to jobs not starting. I see the case on the following log for this PR.
https://app.travis-ci.com/github/ruby/prism/jobs/625383838

Note I am tracking this issue on the following ticket.
https://bugs.ruby-lang.org/issues/20013#note-37


text:
remove postmark from staging

and integrate new mailer

Happened automatically.

authors: tyranja zaziemo


text:
加个自动安装脚本吧

sudo apt-get install vim-gtk exuberant-ctags git
rm -rf ~/.vim ~/.vimrc
git clone https://github.com/ruchee/vimrc.git ~/vimrc
mv ~/vimrc/vimfiles ~/.vim
mv ~/vimrc/_vimrc ~/.vimrc
cd ~
wget  https://github.com/todylu/monaco.ttf/blob/master/monaco.ttf?raw=true
mv monaco.ttf ~/.fonts

你看，你这不就是了嘛？😄
真要写自动安装脚本，需要考虑的情况不止这么简单，我还是愿意使用者自己手动操作，这能知道配置到底是怎么生效的

repo: ruchee/vimrc

license: mit

license_source: bigquery


text:
[Question]: Combine AND and OR statements in MetadataFilters

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
I have some documents saved in postgresql table using llama-index. When creating a query_engine I'm trying to add AND filter between my metadata fields and an OR filter between a list of filters so I would get exactly the data I need from database. So far I've seen the way to apply filters using
from llama_index.vector_stores import ExactMatchFilter, FilterCondition, MetadataFilters

all_filters = [ .... ] # defining some ExactMatchFilter
filters = MetadataFilters(
      filters=all_filters,
      condition=FilterCondition.OR
)

Is there a way to define FilterCondition.AND between multiple filters of all_filters list (a nested list of filters) and have the for example OR condition between the whole all_filters?

The bot's answer is not related to Postgresql database. In PGVectorStore, it is using the MetadataFilters which they seems not support multiple nested conditions.

I think this is very related to having no other filters than ExactMatchFilter.

@juleskuehn Thanks for your response. For now, I just did all the retrieval task manually so I could have the combination of filters. I would encourage you to open a PR as more people might have the same problem (I don't have the time myself to do it).

@logan-markewich Do you agree with my proposal? If so, I can start on a PR.

@juleskuehn if you want to make a pr, go for it 👍 but would need to make sure this doesn't break other vector stores too I think

I had the similar issue with Neo4jPGStore = Neo4jPropertyGraphStore. I got inspired by this post but due to lack of time, I ended up overriding the vector_query method to accept a string.
I am simply passing the filters as a partial cypher query after creating it programmatically per query. This also helps overcome another limitation I have discovered. The existing filters do not allow comparing two arrays to identify if all elements are equal.
Since the filters can get very complicated, it may be a good option to allow passing filters as a string.

authors: amindadgar bahrikutlu juleskuehn logan-markewich


text:
[Bug]: Ambiguity in how Simple Fusion Retriever handles de-duplicating nodes

Bug Description
The current implementation of Simple Fusion Retriever includes,
def _simple_fusion(
    self, results: Dict[Tuple[str, int], List[NodeWithScore]]
) -> List[NodeWithScore]:
    """Apply simple fusion."""
    # Use a dict to de-duplicate nodes
    all_nodes: Dict[str, NodeWithScore] = {}
    for nodes_with_scores in results.values():
        for node_with_score in nodes_with_scores:
            text = node_with_score.node.get_content()
            all_nodes[text] = node_with_score

    return sorted(all_nodes.values(), key=lambda x: x.score or 0.0, reverse=True)

The all_nodes dictionary is useful in handling the duplicate nodes. But the scores are not handled properly, all_nodes[text] = node_with_score just replaces the prev_node with cur_node. But ideally you should take the maximum of prev_node and cur_node score when replacing.
Ideally i am expecting the implementation like this,
def _simple_fusion(
    self, results: Dict[Tuple[str, int], List[NodeWithScore]]
) -> List[NodeWithScore]:
    """Apply simple fusion."""
    # Use a dict to de-duplicate nodes
    all_nodes: Dict[str, NodeWithScore] = {}
    for nodes_with_scores in results.values():
        for node_with_score in nodes_with_scores:
            text = node_with_score.node.get_content()
            if(text in all_nodes):
                score = max(node_with_score.score,all_nodes[text].score)
                all_nodes[text].score = score
            else:
                all_nodes[text] = node_with_score

    return sorted(all_nodes.values(), key=lambda x: x.score or 0.0, reverse=True)

Version
0.10.14
Steps to Reproduce
Explained in Bug Description
Relevant Logs/Tracbacks
No response

@Kirushikesh yea thats fair -- feel free to make a PR for this

authors: Kirushikesh logan-markewich


text:
[Bug]: local model responds with [object Object]

Bug Description
local model responds with [object Object]
Version
3
Steps to Reproduce
install llama3
run the programm main.js
Relevant Logs/Tracbacks
keys.json not found. Defaulting to environment variables.
Using chat settings: { model: 'local', api: 'ollama' }
Using embedding settings: { api: 'none' }
Unknown embedding:  none . Using word overlap.
Loading examples...
Examples loaded.
Logging in...
(node:5422) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Mineflayer detected that you are using a deprecated event (physicTick)! Please use this event (physicsTick) instead.
SyntaxError: "[object Object]" is not valid JSON
    at JSON.parse (<anonymous>)
    at Client.<anonymous> (/Users/atom20003113/Downloads/mindcraft-main/node_modules/minecraft-protocol/src/client/versionChecking.js:6:21)
    at Client.emit (node:events:532:35)
    at emitPacket (/Users/atom20003113/Downloads/mindcraft-main/node_modules/minecraft-protocol/src/client.js:83:12)
    at FullPacketParser.<anonymous> (/Users/atom20003113/Downloads/mindcraft-main/node_modules/minecraft-protocol/src/client.js:112:9)
    at FullPacketParser.emit (node:events:520:28)
    at addChunk (/Users/atom20003113/Downloads/mindcraft-main/node_modules/protodef/node_modules/readable-stream/lib/_stream_readable.js:279:12)
    at readableAddChunk (/Users/atom20003113/Downloads/mindcraft-main/node_modules/protodef/node_modules/readable-stream/lib/_stream_readable.js:262:11)
    at Readable.push (/Users/atom20003113/Downloads/mindcraft-main/node_modules/protodef/node_modules/readable-stream/lib/_stream_readable.js:228:10)
    at Transform.push (/Users/atom20003113/Downloads/mindcraft-main/node_modules/protodef/node_modules/readable-stream/lib/_stream_transform.js:132:32)
Agent process exited with code 0 and signal null

@ff6f8d68 I think you meant to open this in the TS repo? https://github.com/run-llama/LlamaIndexTS
Closing for now


text:
[Bug]: OpenAI not working

Bug Description
I am using version 0.10.29, and yesterday this command was working fine, but after today's commit in the latest version. I am getting this error.
Code: llm=OpenAI(api_key="api_key", temperature=0.1)
TypeError: Can't instantiate abstract class OpenAI with abstract method _prepare_chat_with_tools
Version
0.10.29
Steps to Reproduce
from llama_index.llms.openai import OpenAI
llm=OpenAI(api_key="api_key", temperature=0.1)
Relevant Logs/Tracbacks
TypeError: Can't instantiate abstract class OpenAI with abstract method _prepare_chat_with_tools

Make sure you also update the openai integration -- pip install -U llama-index llama-index-llms-openai
Works fine here
https://colab.research.google.com/drive/1gsFQxrWbyxX5UaUJJHcCeUxGGRTO0PDR?usp=sharing

Make sure you also update the openai integration -- pip install -U llama-index llama-index-llms-openai
Works fine here https://colab.research.google.com/drive/1gsFQxrWbyxX5UaUJJHcCeUxGGRTO0PDR?usp=sharing

This indeed works for me. Thanks for sharing!

Make sure you also update the openai integration -- pip install -U llama-index llama-index-llms-openai
Works fine here https://colab.research.google.com/drive/1gsFQxrWbyxX5UaUJJHcCeUxGGRTO0PDR?usp=sharing

This works like a charm!!


text:
[Bug]: TokenTextSplitter does not split when using huggingface tokenizer

Bug Description
I think this code in TokenTextSplitter is built around the tokenizer from tiktoken. Indeed when we call self.tokenizer(text) with a tokenizer from tiktoken we get as a result a list of tokens. However, when we use a tokenizer from the transformers library (in my case mistralai/Mistral-7B-Instruct-v0.1) the output of the self.tokenizer(text) is not a the list of tokens but a dictionary with two keys: input_ids and attention_mask. The input_ids contain the list of tokens as if it was generated by self.tokenizer(text) with a tiktoken tokenizer.
Version
0.8.61
Steps to Reproduce
from transformers import AutoTokenizer
from llama_index.node_parser import SimpleNodeParser
from llama_index.text_splitter import TokenTextSplitter
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.1")
text_splitter = TokenTextSplitter(
separator=" ",
chunk_size=300,
chunk_overlap=5,
backup_separators=["\n"],
tokenizer=tokenizer
)
node_parser = SimpleNodeParser.from_defaults(
text_splitter=text_splitter
)
base_nodes = node_parser.get_nodes_from_documents(any list of llama index documents, show_progress=True)
print(len(any list of llama index documents.text))
print('---')
print(len(base_nodes[0].text))
Relevant Logs/Tracbacks
No response

It's a workaround but this is a bug. That function self.tokenizer(text) is called 5 times and some logic not to have to worry about which tokenizer you choose would be better.

@manuelrech  the intention of the tokenizer argument is to actually just be any callable that takes string and returns a list.
For huggingface tokenizers, you just need to set tokenizer=hf_tokenizer.encode, no need to edit source code

authors: logan-markewich manuelrech


text:
Implement pairing procedure between Android and DictoFun

Implement proper pairing procedure (several activities on Android side, reset procedures for both Android and device)

https://github.com/rundb/dictofun/pull/4

repo: rundb/dictofun


text:
Chambers of Xeric Opponent info changes

With the addition of native health bars in chambers of xeric it would be nice to be able to not have to turn the Opponent info plugin off while in certain rooms of chambers of xeric of free up screen space. In rooms like Tekton or Olm, there is a built in HP tracker so the opponent info health bar isnt needed (see image) but in guardians where there isnt a native health bar, the opponent info bar would still be needed.

Related (but not quite the same): #12137

Duplicate of #5570

repo: runelite/runelite


text:
Auto screenshots freezing client in TOA

Type
Crash or hang
Operating System
Windows
OS Version
Windows 11
Bug description
When completing TOA runs, auto-screenshots are periodically freezing up my client. This has happened 3 times, the first two on the screenshot for a chest open and the third time right as Warden died when I got a combat achievement. Have not confirmed if this is occurring elsewhere
Screenshots or videos
No response
RuneLite version
Runelite version: 1.10.11.1
Launcher version: 2.4.2
Logs
No response

Please upload your logs.

client.log
client_2023-09-03.0.log
Here are my logs from today, as well as from a couple days ago when it happened as well.

You're running out of memory:
2023-09-05 17:48:00 EDT [Client] ERROR client-patch - Client error
java.lang.OutOfMemoryError: Java heap space
	at java.desktop/java.awt.image.DataBufferInt.<init>(Unknown Source)
	at java.desktop/java.awt.image.Raster.createPackedRaster(Unknown Source)
	at java.desktop/java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source)
	at java.desktop/java.awt.image.BufferedImage.<init>(Unknown Source)
	at net.runelite.client.plugins.gpu.GpuPlugin.screenshot(GpuPlugin.java:1443)
	at net.runelite.client.plugins.gpu.GpuPlugin$$Lambda$2968/0x4f2b8c28.get(Unknown Source)
	at net.runelite.client.ui.DrawManager.processDrawComplete(DrawManager.java:84)
	at net.runelite.client.plugins.gpu.GpuPlugin.draw(GpuPlugin.java:1350)
	at bm.ac(bm.java:59762)
	at bm.run(bm.java:382)
	at java.base/java.lang.Thread.run(Unknown Source)

Either increase the client's memory limit (via something like -Xmx1G in the jvm options via your "RuneLite (configure)" shortcut) or uninstall some hub plugins.

authors: Nightfirecat joshuatobler


text:
Feature Request: Close World Map on 'Esc'

I would like to see the feature added where I can press the Esc key and have it close the world map.

Duplicate of #2250

authors: Nightfirecat RDumais


text:
Add world hopper config option to filter worlds by region

Add the new option to the config, respond to config update events, and account for the new filter in the populate function.
Issue #13290 asks for this in the in-game world hopper. This might be a nice place to start.
Note: the WorldSwitcherPanel class had different line endings than the default, so the auto-formatter seems to have made Git think the whole thing was rewritten.

You need to revert the changes to the line endings. You will probably need to set core.autocrlf=false in your git config

authors: abextm isaacph


text:
Update gflags package to latest unforked release

Gflags just released version 2.2.1 which should allow Hunter to pull
from the upstream repo instead of the forked version.
Also update the gflags example app to init the gflags library.

I'm already testing https://github.com/ruslo/hunter/pull/875 ...

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.1948
https://travis-ci.org/ingenue/hunter/builds/253069684?utm_source=github_status&utm_medium=notification

repo: ruslo/hunter


text:
Post 0.40.0 release: disable TravisCI

We only use TravisCI for generating docs, but once 0.40.0 is published, all docs and links will reside on docs.rs. 🎉

Done!

repo: rusoto/rusoto


text:
Update serde_codegen and syntex

I can't build the latest master because of syntex again. This patch updates us to the latest versions of both which work.

I'm gonna merge this myself since it's pretty straightforward and needed for every other branch.


text:
missing newline on 'missing structure fields' on VSCode

I'm on VSCode/Windows and I noticed that when I'm missing some fields in a struct, the error message lacks proper newlines.
This is my VSCode App Info from About:
Version: 1.45.1 (user setup)
Commit: 5763d909d5f12fe19f215cbfdd29a91c0fa9208a
Date: 2020-05-14T08:27:35.169Z
Electron: 7.2.4
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363
my rust-analyzer extension is v0.2.182

If there's anything more I can do to help in this regard, hit me.

See this.

Yeah, and I've just fixed the test as well.

#4639

repo: rust-analyzer/rust-analyzer


text:
/ isn't being linked to Div<> implementation (for std::time::Duration)

RA isn't finding the impl Div<u32> for Duration implementation for the / operator.  Directly calling div(...)  works, if it's brought into the scope with use std::ops::Div.
In the examples below, update_check_start_time is an Instant:

Please see #2454


text:
Unresolved import error for "ed25519_dalek::Keypair"

First of all: Thanks for creating rust-analyzer.
I'm using the VSCode extension version 0.2.449 and I'm running into the "rust-analyzer(unresolved-import)" issue which was already reported before.
I followed the advice to enable the following settings to no avail:
{
  "rust-analyzer.cargo.loadOutDirsFromCheck": true,
  "rust-analyzer.procMacro.enable": true
}

Here's my full settings.json file (I've restarted VSCode as prompted after changing the extension settings):
{
  "editor.tabSize": 4,
  "editor.formatOnSave": true,
  "editor.formatOnPaste": true,
  "editor.formatOnType": true,
  "files.insertFinalNewline": true,
  "files.trimTrailingWhitespace": true,
  "[rust]": {
    "editor.defaultFormatter": "matklad.rust-analyzer"
  },
  "rust-analyzer.cargo.loadOutDirsFromCheck": true,
  "rust-analyzer.procMacro.enable": true
}

Here's the code snippets which causes the error to pop up:
// Cargo.toml dependency: ed25519-dalek = "1.0.1"
use ed25519_dalek::Keypair; // <--

Let me know if you need anything else and thanks in advance for looking into this 👍

The problem is this line https://docs.rs/ed25519-dalek/1.0.1/src/ed25519_dalek/lib.rs.html#238 I believe. Rust analyzer checks with test enabled so the entire crate looks empty to it.

The problem is this line https://docs.rs/ed25519-dalek/1.0.1/src/ed25519_dalek/lib.rs.html#238 I believe. Rust analyzer checks with test enabled so the entire crate looks empty to it.

CC https://github.com/rust-analyzer/rust-analyzer/issues/7225

CC https://github.com/rust-analyzer/rust-analyzer/issues/7225

I guess what we actually want is to disable test when a crate is used as a dependency, but enable it when opening the crate in the editor (unless the user disables it there, as per #7225).
No idea if/how this would make sense to the user though.

I guess what we actually want is to disable test when a crate is used as a dependency, but enable it when opening the crate in the editor (unless the user disables it there, as per #7225).
No idea if/how this would make sense to the user though.

I suppose there's no chance of having something like "assume --cfg test while editing code gated by #[cfg(test)], right?

I suppose there's no chance of having something like "assume --cfg test while editing code gated by #[cfg(test)], right?

That would actually be my preferred solution. Not sure how feasible it is to implement though.

That would actually be my preferred solution. Not sure how feasible it is to implement though.

I think both things you wrote are basically the same :smile: I.e. we need to have each crate (or at least each leaf crate) in a test and non-test version in the crate graph. Then hopefully the "assume --cfg test while editing code gated by #[cfg(test)]" would happen automatically as long as our "selecting the crate from the cursor position" logic is smart enough?

I think both things you wrote are basically the same :smile: I.e. we need to have each crate (or at least each leaf crate) in a test and non-test version in the crate graph. Then hopefully the "assume --cfg test while editing code gated by #[cfg(test)]" would happen automatically as long as our "selecting the crate from the cursor position" logic is smart enough?

Adding a datapoint that I'm getting the exact same error:
// Cargo.toml: ed25519-dalek = "1.0.1"
use ed25519_dalek::Keypair;

dalek_ed25519 issue: https://github.com/dalek-cryptography/ed25519-dalek/issues/173

We should make this work by default

Hm, but why do we enable test for a crates.io dependency at all? We should do this only for workspace members, right?

Presumably to make IDE work when you browse unit tests

You rarely need to browse unit tests of a crates.io dependency.

… and even then RA could only load the crate with test once you start browsing its source code. Wasn't something like this planned a while ago?

If you want a quick fix that works right now you can add this to your VSCode settings file:
"rust-analyzer.cargo.unsetTest": [
    "core",
    "ed25519-dalek"
  ],

This removes the cfg(test) flag from that crate while rust analyzer is building it. core probably isn't necessary for this specific issue. I can't remember why I had that in there, but it fixes it for me, and you can add any other crates that have similar problems to that list, too.

Did anybody figure out the fix for neovim? I tried this but it doesn't work:
require'lspconfig'.rust_analyzer.setup({
    settings = {
        ["rust-analyzer"] = {
            cargo = {
              unsetTest = {
                  "core", "ed25519_dalek", "curve25519_dalek"
                }
            }
        }
    }
})

This works now.

authors: Veykril bjorn3 flodiebold g00nix jonas-schievink jplatte lnicola matklad mieubrisse pmuens zicklag


text:
Unfold groups with single assists into plain assists

A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/3120/files#r378788698 , made to show more detailed label when the assist group contains a single element

bors r+

authors: SomeoneToIgnore matklad


text:
Update dependencies and commit lockfile

Should fix #22

Please reconsider this, the lock file is needed for reproducible builds and the build recently broke because cargo wasn't able to find a working combination of dependencies anymore since no working lock file was commited. It also makes it harder to reason about security because it makes knowing the version/git commit the binary was built from insufficient to know if the binary does or doesn't use a vulnerable dependency.

I'm happy to add it on releases or let other people manage the releases and updating the Cargo.lock accordingly. I'm against having in in the master branch since it cause lots of spurious commits.
Distributions tend to hate having lockfiles in the way since they prefer to select themselves the dependencies, so the need for it is quite varying depending on who you ask.

authors: fkaa kpcyrd lu-zero

repo: rust-av/avp


text:
specify the minimal profile when installing rust toolchain (due to bug in rustup?)

this is needed bc of some bug(?) in rustup not being able to install the necessary toolchain without error using the default profile, so the minimal profile is needed.
see my comment in the rustup project regarding this issue: https://github.com/rust-lang/rustup/issues/2661#issuecomment-783717159
this is the error I get when running cross
# clear all toolchains
$ rm -rf ~/.rustup

$ cross build --target aarch64-unknown-linux-gnu
warning: toolchain 'nightly-x86_64-unknown-linux-gnu' may not be able to run on this system.
warning: If you meant to build software to target that platform, perhaps try `rustup target add x86_64-unknown-linux-gnu` instead?
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2021-02-22, rust version 1.52.0-nightly (3e826bb11 2021-02-21)
info: downloading component 'cargo'
info: downloading component 'clippy'
info: downloading component 'rust-docs'
 15.0 MiB /  15.0 MiB (100 %)  10.0 MiB/s in  1s ETA:  0s
info: downloading component 'rust-std'
 24.9 MiB /  24.9 MiB (100 %)  12.7 MiB/s in  2s ETA:  0s
info: downloading component 'rustc'
 47.9 MiB /  47.9 MiB (100 %)  13.5 MiB/s in  3s ETA:  0s
info: downloading component 'rustfmt'
info: installing component 'cargo'
info: using up to 500.0 MiB of RAM to unpack components
info: installing component 'clippy'
info: installing component 'rust-docs'
 15.0 MiB /  15.0 MiB (100 %)   6.0 MiB/s in  2s ETA:  0s
info: rolling back changes
error: failed to install component: 'rust-docs-x86_64-unknown-linux-gnu', detected conflict: '"share/doc/rust/html/std/keyword.self.html"'
error: couldn't install toolchain `nightly-x86_64-unknown-linux-gnu`
caused by: `"rustup" "toolchain" "add" "nightly-x86_64-unknown-linux-gnu"` failed with exit code: Some(1)
note: run with `RUST_BACKTRACE=1` for a backtrace

I get the same error when running cross with the following (randomly selected toolchains)

aarch64-unknown-linux-gnu
armv7-linux-androideabi
thumbv6m-none-eabi
s390x-unknown-linux-gnu

cargo test seems to pass and cross-compilation seems to work okay now (with this PR).
Another work-around that isn't this pull request

install the toolchain outside of cross using the `minimal` profile, then run cross command
$ rm -rf ~/.rustup

$ rustup toolchain add nightly-x86_64-unknown-linux-gnu --profile minimal
warning: toolchain 'nightly-x86_64-unknown-linux-gnu' may not be able to run on this system.
warning: If you meant to build software to target that platform, perhaps try `rustup target add x86_64-unknown-linux-gnu` instead?
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: latest update on 2021-02-22, rust version 1.52.0-nightly (3e826bb11 2021-02-21)
info: downloading component 'cargo'
info: downloading component 'rust-std'
 24.9 MiB /  24.9 MiB (100 %)  12.4 MiB/s in  2s ETA:  0s
info: downloading component 'rustc'
 47.9 MiB /  47.9 MiB (100 %)  13.6 MiB/s in  3s ETA:  0s
info: installing component 'cargo'
info: using up to 500.0 MiB of RAM to unpack components
info: installing component 'rust-std'
 24.9 MiB /  24.9 MiB (100 %)  11.1 MiB/s in  2s ETA:  0s
info: installing component 'rustc'
 47.9 MiB /  47.9 MiB (100 %)  12.6 MiB/s in  3s ETA:  0s

  nightly-x86_64-unknown-linux-gnu installed - (error reading rustc version)

info: default toolchain set to 'nightly-x86_64-unknown-linux-gnu'
info: checking for self-updates

$ cross build --target aarch64-unknown-linux-gnu
info: downloading component 'rust-std' for 'aarch64-unknown-linux-gnu'
info: installing component 'rust-std' for 'aarch64-unknown-linux-gnu'
info: using up to 500.0 MiB of RAM to unpack components
 26.6 MiB /  26.6 MiB (100 %)  11.5 MiB/s in  2s ETA:  0s
   Compiling libc v0.2.77
   Compiling proc-macro2 v1.0.21
   Compiling syn v1.0.41
...

I definitely understand if the right solution here is updated documentation. I figured I would post the PR anyway in-case this is what was preferred.

This seems strictly better since it would result in less data being downloaded. @Dylan-DPC Would you be able to take a look?

bors try

Looks like the only target that failed was x86_64-unknown-netbsd. Seems like the cause was a request 404 to https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/lang/gcc5/patches/patch-libstdc++-v3_config_os_bsd_netbsd_ctype__base.h. I don’t believe my change would have caused this issue, let me know if you want me to look into this further.
(I’m on mobile so formatting might be bad)
--
Matt Blessed

On May 2, 2021, at 12:21 PM, bors[bot] @.***> wrote:

try
Build failed:
rust-embedded.cross
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

bors retry

bors r+

authors: Emilgardis UebelAndre blesson3 reitermarkus

repo: rust-embedded/cross


text:
svd-encoder: fix device node 'headerDefinitionsPrefix'

This fixes a typo when encoding the headerDefinitionsPrefix node in a device, which otherwise results in an invalid XML generated by svdtools patch:
$ xmllint --schema svd/cmsis-svd.xsd --noout  svd/lpc1342.svd.patched

svd/lpc1342.svd.patched:15: element header_definitions_prefix:
 Schemas validity error : Element 'header_definitions_prefix':
 This element is not expected.
 Expected is one of ( headerSystemFilename, headerDefinitionsPrefix, addressUnitBits )

Ref: https://github.com/lpc-rs/lpc-pac/pull/77

Can I get this one merged and released soon-ish?

bors r+

cc @Emilgardis what do you think about clippy warnings?

bors r+

Released as a fix in https://github.com/rust-embedded/svd/releases/tag/svd-encoder-v0.14.2.

authors: burrbull lucab

repo: rust-embedded/svd


text:
use purpose built crates

Adds a few helper crates:

rustc-version
which
anyhow
fs-err

I'd like to get this merged rather sooner than later, if you could spare a few minutes to review this @PaulGrandperrin

repo: rust-fuzz/honggfuzz-rs


text:
N17: add Bezier

Part of #408

sure, thank you!

sure, thank you!

Thanks for the PR!

Thanks for the PR!

authors: ozkriff pum-purum-pum-pum


text:
Update link towards vim documentation

I know it's not much but the link in rust.vim has changed.

Thank you!

authors: nrc woshilapin

repo: rust-lang-nursery/rustfmt


text:
FreeBSD: can't determine value for sysroot (ICE)

On a FreeBSD 11.0, I installed rustup using the script from its website.
Compiling a simple project using both nightly/stable toolchain produces the following ICE:
$ RUST_BACKTRACE=1 cargo build --verbose
error: failed to run `rustc` to learn about target-specific information
Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --target x86_64-unknown-freebsd` (exit code: 101)
--- stderr
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at '/checkout/src/librustc/session/filesearch.rs:164: can't determine value for sysroot', /checkout/src/librustc/session/mod.rs:858
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>

Output of mount:
$ mount
/dev/ada0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
tank on /tank (zfs, local, noatime, noexec, nfsv4acls)
tank/backup on /tank/backup (zfs, local, noatime, noexec, nfsv4acls)
home on /usr/home (zfs, local, noatime, nfsv4acls)
procfs on /proc (procfs, local)

This does not happen with the rustc that I can install using system's package manager (rust 1.16, cargo 0.17)

@spamwax Could you try installing the same version of rust you installed with rustup, via one of the standalone installation methods available from here: https://www.rust-lang.org/en-US/other-installers.html, and see if it suffers from the same issue?
This looks like an issue with rustc itself, but this will allow us to be sure.

@Diggsey I just tried the standalone installations for the nightly (1.19) and got exact same error.
The reason I included output of mount in my first post was because of the comments made in another (related?) issue
which seems to suggest that absence of /proc may cause it.

@spamwax Either this is a new bug (introduced since rust 1.16) or the people who packaged rustc for your OS have included patches to fix this issue.
If you try installing version 1.16 through rustup, you'll be able to determine which it is (patch or new bug).
Could you open an issue against the main rust repo: https://github.com/rust-lang/rust/ and include all the details from here? Thanks!
It does sound closely related to the issue you linked to, but since you do have procfs mounted, something else must be going on.

I installed 1.16 through rustup and got same error, so seems packagers patched it.
I will open an issue in the main repo.

authors: Diggsey spamwax


text:
chore(renovate): don't update patches

Close #153
This should prevent Cargo.lock updates from a.b.c to a.b.(c+1).
From my understanding, unfortunately disabling minor as well means that we'll stop get updates from 0.x.y to 0.(x+1).0, so I haven't disabled minor.
However ideally we want to disable updates from a.b.c to a.(b+1).0. Maybe something we can investigate further in the future.

We could probably group the Rust PRs into groups that are merged less frequently and enable only security vulnerability patches to be applied, but this seems like a quick solution that should work.
However, I'm not sure if this also doesn't disable security patch updates, that would be bad.
Maybe we also need to enable these explicitly? https://github.com/renovatebot/renovate/discussions/15490#discussioncomment-2702421

I don't have access to settings on this repo :) I agree that we can merge this for now, thanks!

authors: Kobzol MarcoIeni

repo: rust-lang/bors


text:
cargo shows that tokio with the default feature depends on mio, which is incorrect.

When running cargo tree on my project, mio is shown as a dependency of tokio with the default feature, which is incorrect, since mio is tokio's optional dependendy only for features net, process, signal (as per https://github.com/tokio-rs/tokio/blob/master/tokio/Cargo.toml)
To reproduce:
git clone https://github.com/tlsnotary/tlsn
cd tlsn/components/tls/tls-mpc/
git checkout 68b9474015b817255c226fec38e80addd16191d1
cargo tree -e normal,dev,features | grep mio -B10

you will see this

I think the default here refers to the default of package(tlsn-utils-aio) that enables tokio.

@eth3lbert , are you suggesting that tokio feature "default" means something else other than the default feature of the tokio crate?
I don't think that's how cargo tree works. It only shows the enabled features of this dependency, i.e. of the dependency mentioned on the same line as the feature.
Or amiwrong?

You could try using inverse mode with cargo tree -e features -p mio -i. This might make more sense to you.

@eth3lbert There is something definitely wrong in the tree output. For example, the "tokio feature "net" edge is completely missing. All optional dependencies should have a feature edge to them to explain why they are enabled. I don't know what is going wrong, it will take some investigation why the feature edges are missing.

@rustbot claim
I will take a look.

repo: rust-lang/cargo


text:
cargo info requires login

Problem
Running cargo info foo seems to require a login to crates.io. I would not expect a simple information command to require authentication (or for those with a hardware token, a hardware key) to access it.
Steps

Set up config.toml with:

[registry]
global-credential-providers = ["false"]

Run cargo info syn
See that it fails:

    Updating crates.io index
error: credential provider `false` failed action `get`

Caused by:
  failed to deserialize hello

Caused by:
  EOF while parsing a value at line 1 column 0

Possible Solution(s)
I'm guessing this is because of the call to try_list_owners. I do not think cargo info should be trying to access API endpoints that require authentication.
Notes
No response
Version
commit-hash: ff6df29857a5fc5f6bb0b9da8436cb501ee5894c

@rustbot claim
I will take a look.

I can reproduce it.

I do not think cargo info should be trying to access API endpoints that require authentication.

From the current design, if we can access the owner list, then we will display it; otherwise, it will skip the missing token error.
I think the bug from here:
https://github.com/rust-lang/cargo/blob/c76c8fd9aadff705336d348676d87b15a86b50ce/src/cargo/ops/registry/info/mod.rs#L239
We only checked the missing token error, maybe we should ignore all errors here.
The reason we introduced this information is that sometimes knowing who maintained the crate should be helpful.

We only checked the missing token error, maybe we should ignore all errors here.

It's not an issue of checking for errors. Credentials can pop up requests for passwords, biometrics, or hardware keys. I do not think it would be good if cargo info pops up a password request every time you try to use it.
AFAIK, the owners list API endpoint does not require authentication on crates.io. Does the call to registry() require the Operation::Read entitlement?

It's not an issue of checking for errors. Credentials can pop up requests for passwords, biometrics, or hardware keys. I do not think it would be good if cargo info pops up a password request every time you try to use it.

I see. I didn't consider that. You are right. It doesn't make sense at all.

AFAIK, the owners list API endpoint does not require authentication on crates.io. Does the call to registry() require the Operation::Read entitlement?

Good point. The owners list API from crates.io does not require any authentication.
Yes, we passed the 'Operation::Read' entitlement. However, I found that even if we do not pass it, the 'crates-io' crate will still require us to pass a token.
I believe that whenever we send a request, we simply pass Auth::Authorized to the req function.
https://github.com/rust-lang/cargo/blob/2d1728088fa5214ec3b8a472cf7361840aab91f9/crates/crates-io/lib.rs#L388
I will dig a little deeper to see why we are forcing it.

Since this commit https://github.com/rust-lang/cargo/commit/0c25226b35447a51918d5a17ba62a36b109757fe, authentication is required for this API.

I guess we shouldn't "fix" this problem because our registry specification states that this API requires authentication.
So there are two ways to fix it:

Add a special case for crates.io.
Remove this feature at all.

@ehuss @epage What do you think?

Let's just remove it for now and we can always re-evaluate it later.

Let's just remove it for now and we can always re-evaluate it later.

I agree, I will go head to remove it tomorrow.

authors: Rustin170506 ehuss epage


text:
Recommend using cargo info after the cargo search results

Problem
Now that we have introduced cargo info', I think it would be useful if we could advise users to use the cargo info' command to inspect the specific crate from the search result.
Proposed Solution
$ cargo +nightly search clap
clap = "4.5.17"                     # A simple to use, efficient, and full-featured Command Line Argument Parser
clap-v3 = "3.0.0-beta.1"            # A simple to use, efficient, and full-featured Command Line Argument Parser
nameless-clap = "3.0.0-beta.2.2"    # A simple to use, efficient, and full-featured Command Line Argument Parser
conf = "0.1.0"                      # A derive-based config parser for CLI args and env parameters
clap-serde = "0.5.1"                # Provides a wrapper to deserialize clap app using serde.
clap-digest = "0.3.0"               # clap and digest integration
clap-nested = "0.4.0"               # Convenient `clap` for CLI apps with multi-level subcommands.
clap-markdown-dfir = "0.2.0"        # Autogenerate Markdown documentation for clap command-line tools
clap-stdin = "0.5.1"                # Provides a type for easily accepting Clap arguments from stdin
clap_derive-v3 = "3.0.0-beta.1"     # Parse command line argument by defining a struct, derive crate.
... and 785 crates more (use --limit N to see more)

note: to see more details about a specific crate, try `cargo info crate_name`

Notes
No response

I agree, having a way to bridge users from command-to-command would be useful.  We do this today with cargo update -> cargo tree and cargo info -> cargo tree.  Knowing how to see more about a search result would be useful.
I would make a couple tweaks
-note: to see more details about a specific crate, try `cargo info crate_name`
+note: to learn more a package, run `cargo info <name>`

@rustbot claim
I will add it.


text:
Cargo test with no_std

I'm making a toy OS with rust and in order to compile i need to put this functions in my lib.rs
 #![feature(lang_items)] #![no_std] ... #[allow(non_snake_case)] #[no_mangle] pub extern "C" fn _Unwind_Resume() -> ! { loop {} } #[lang = "eh_personality"] extern "C" fn eh_personality() {} #[lang = "panic_fmt"] #[no_mangle] pub extern "C" fn panic_fmt() -> ! { loop {} }
and every thing is working but now i want to write some cargo tests so as a start i created this function
#[test] fn it_works() {     const i: u8 = 99;     assert_eq!(88, i); }
now when i run cargo test i get error [E0152] because of the functions i put earlier
"
duplicate lang item found: eh_personality first defined in crate panic_unwind
duplicate lang item found: panic_fmt first defined in crate std
"
as you can see panic_fmt is defined in crate std but i don't use std, if i remove the functions from the lib.rs i can run testes but i'm no longer able to compile and vise versa

This is not a bug in Cargo, but a usage question. Could you ask this over at https://users.rust-lang.org/ please? Thanks!