text:
Rails/UniqueValidationWithoutIndex errors on namespaced models

Expected behavior
Rubocop-rails should not output any errors
Actual behavior
Running rubocop outputs
An error occurred while Rails/UniqueValidationWithoutIndex cop was inspecting /Users/tim.landwerth/*/app/models/measuring_point_concept/sensor_import.rb:4:2.
undefined method `with_column?' for nil:NilClass

An error occurred while Rails/UniqueValidationWithoutIndex cop was inspecting /Users/tim.landwerth/*/app/models/measuring_point_concept/sensor_import.rb:4:2.
undefined method `with_column?' for nil:NilClass
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/mixin/active_record_helper.rb:55:in `resolve_relation_into_column'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:84:in `block in column_names'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:82:in `map!'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:82:in `column_names'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:50:in `find_schema_information'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:38:in `on_send'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:91:in `block (2 levels) in trigger_responding_cops'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:113:in `with_cop_error_handling'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:90:in `block in trigger_responding_cops'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:89:in `each'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:89:in `trigger_responding_cops'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:61:in `block (2 levels) in '
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `block in on_begin'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `each'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `on_begin'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:62:in `block (2 levels) in '
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:101:in `on_class'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:62:in `block (2 levels) in '
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:14:in `walk'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/commissioner.rb:74:in `investigate'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/team.rb:151:in `investigate_partial'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cop/team.rb:83:in `investigate'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:295:in `inspect_file'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:245:in `block in do_inspection_loop'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:277:in `block in iterate_until_no_changes'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:270:in `loop'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:270:in `iterate_until_no_changes'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:241:in `do_inspection_loop'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:121:in `block in file_offenses'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:146:in `file_offense_cache'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:120:in `file_offenses'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:111:in `process_file'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:90:in `block in each_inspected_file'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:89:in `each'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:89:in `reduce'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:89:in `each_inspected_file'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:78:in `inspect_files'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/runner.rb:39:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli/command/execute_runner.rb:21:in `execute_runner'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli/command/execute_runner.rb:13:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli/command.rb:10:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli/environment.rb:17:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli.rb:65:in `run_command'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli.rb:72:in `execute_runners'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/lib/rubocop/cli.rb:41:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/exe/rubocop:13:in `block in '
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/2.6.0/benchmark.rb:308:in `realtime'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/rubocop-0.88.0/exe/rubocop:12:in `'
/Users/tim.landwerth/.rbenv/versions/2.6.6/bin/rubocop:23:in `load'
/Users/tim.landwerth/.rbenv/versions/2.6.6/bin/rubocop:23:in `'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in '
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/Users/tim.landwerth/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `'
/Users/tim.landwerth/.rbenv/versions/2.6.6/bin/bundle:23:in `load'
/Users/tim.landwerth/.rbenv/versions/2.6.6/bin/bundle:23:in `'

Steps to reproduce the problem
Sorry, I do not have a reproducible example yet - but I would think that namespaced models cause the problem, since it errors on a few files, which all have a namespace - e.g.:
class MeasuringPointConcept::SensorImport < ApplicationRecord
  belongs_to :node_import, class_name: "MeasuringPointConcept::NodeImport", optional: true

  validates :channel_number, presence: true, numericality: true, uniqueness: { scope: :node_import_id }
  validates :sensor_name, presence: true

  ...
end

RuboCop version
0.88.0 (using Parser 2.7.1.4, rubocop-ast 0.3.0, running on ruby 2.6.6 x86_64-darwin18)

Thanks and keep up the great work 👍

I am also seeing this problem on Rubocop v0.90.0. Not sure what @Timmitry means by namespaced model, but the error happens on a model using single table inheritance in my project.

@Bialogs With namespaced I meant that the model is in a module, as can be seen by the MeasuringPointConcept::-prefix.
And if the schema might help, here it is:
  create_table "measuring_point_concept_sensor_imports", force: :cascade do |t|
    t.bigint "node_import_id"
    t.string "name"
    t.integer "channel_number"
    t.string "sensor_name"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["node_import_id"], name: "index_measuring_point_concept_sensor_imports"
  end

#349 fixes an error when the related table is not found.

I can confirm this behaviour. With my code it happens exactly after updating rubocop-rails from 2.7.1. (no error) to 2.8.0 (error mentioned above, undefined method 'with_column?' for nil:NilClass). It did not update any other gems or dependencies at the same time, so it seems to be related exactly to this minor update.
For me, it also seems to have to do with nested classes (models defined inside a module) and probably some mistake when resolving table names from that nested class name?
@Tietew: I can confirm your fix removes the error. But I am not sure if this implements the correct behaviour. See, the table does exist in our cases and is also declared in the schema.rb. Simply not running the cop against the concerned model/table seems like a hack. I believe, if I would add a validation without the unique index in such a nested class it would not be detected as an offense. If I have the time I will take a look into it myself and maybe comment your PR.

@Jay-Schneider Yes, you're right. But my PR just fixes the error -- in my case, the table really doesn't exist. This issue seems to be false negative problem.

Seeing this problem as well, in my case it is an extremely simple model:
class Achievement < FeedItem
  validates :text, presence: true, uniqueness: true
end

However, since it is using STI, the associated database table is called feed_items, not achievements.
  create_table "feed_items", id: :serial, force: :cascade do |t|
    t.integer "user_id"
    t.integer "team_id"
    t.integer "division_id"
    t.string "text"
    t.integer "challenge_id"
    t.integer "point_value"
    t.integer "flag_id"
    t.string "type"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
  end

This problem also occurs with Modules using ActiveRecord:
# rubocop:disable Rails/UniqueValidationWithoutIndex
module Sluggable
  extend ActiveSupport::Concern

  included do
    validates :slug, uniqueness: true, format: { with: /\A[\w-]*\z/ }, length: { maximum: 255 }

    # Generates not-yet-taken slug by appending numbers if necessary.
    def self.generate_unique_slug(slug)
      new_slug = slug.parameterize

      # XXX: LENGTH + 1 because PostgreSQL indexes characters in strings from 1
      max_duplicate = where("slug SIMILAR TO ?", "#{new_slug}-[0123456789]+")
                      .pick(
                        Arel.sql(format("MAX(CAST(SUBSTRING(slug FROM LENGTH(%<slug>s) + 1) AS numeric))",
                                        slug: ActiveRecord::Base.connection.quote("#{new_slug}-")))
                      )&.to_i
      # This loop should not be needed anymore, but let's keep it for the peace of mind.
      i = (max_duplicate || 0) + 1
      while find_by_slug(new_slug)
        new_slug = "#{slug} #{i}".parameterize
        i += 1
      end
      new_slug
    end

    def generate_slug
      if slug.blank? && name.present?
        self.slug = self.class.generate_unique_slug(name)
      end
    end
  end
end
# rubocop:enable Rails/UniqueValidationWithoutIndex

Error:
An error occurred while Rails/UniqueValidationWithoutIndex cop was inspecting /Users/olivar/RubymineProjects/customink-for-business/app/models/concerns/sluggable.rb:6:4.
undefined method `each_node' for nil:NilClass
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/mixin/active_record_helper.rb:14:in `find_set_table_name'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/mixin/active_record_helper.rb:35:in `each'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/mixin/active_record_helper.rb:35:in `to_a'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/mixin/active_record_helper.rb:35:in `table_name'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:49:in `find_schema_information'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-rails-2.8.0/lib/rubocop/cop/rails/unique_validation_without_index.rb:38:in `on_send'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:99:in `block (2 levels) in trigger_responding_cops'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:152:in `with_cop_error_handling'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:98:in `block in trigger_responding_cops'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:97:in `each'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:97:in `trigger_responding_cops'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:70:in `on_send'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `block in on_begin'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `each'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `on_begin'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:72:in `on_begin'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:173:in `on_block'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:72:in `on_block'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `block in on_begin'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `each'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:59:in `on_begin'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:72:in `on_begin'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:159:in `on_while'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:72:in `on_module'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-ast-0.3.0/lib/rubocop/ast/traversal.rb:14:in `walk'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/commissioner.rb:85:in `investigate'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/team.rb:152:in `investigate_partial'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cop/team.rb:83:in `investigate'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:296:in `inspect_file'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:246:in `block in do_inspection_loop'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:278:in `block in iterate_until_no_changes'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:271:in `loop'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:271:in `iterate_until_no_changes'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:242:in `do_inspection_loop'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:122:in `block in file_offenses'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:147:in `file_offense_cache'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:121:in `file_offenses'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:112:in `process_file'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:91:in `block in each_inspected_file'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:90:in `each'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:90:in `reduce'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:90:in `each_inspected_file'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:79:in `inspect_files'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/runner.rb:40:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli/command/execute_runner.rb:22:in `execute_runner'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli/command/execute_runner.rb:14:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli/command.rb:11:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli/environment.rb:18:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli.rb:65:in `run_command'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli.rb:72:in `execute_runners'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/lib/rubocop/cli.rb:41:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/exe/rubocop:13:in `block in <top (required)>'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/2.7.0/benchmark.rb:308:in `realtime'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/rubocop-0.90.0/exe/rubocop:12:in `<top (required)>'
/Users/olivar/.rbenv/versions/2.7.1/bin/rubocop:23:in `load'
/Users/olivar/.rbenv/versions/2.7.1/bin/rubocop:23:in `<top (required)>'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/Users/olivar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/Users/olivar/.rbenv/versions/2.7.1/bin/bundle:23:in `load'
/Users/olivar/.rbenv/versions/2.7.1/bin/bundle:23:in `<main>'

As you can see from the code-snippet, trying to disable the Cop has no effect

@coding-bunny That's strange... if you move the RuboCop directives to only around the validates lines, does it still occur? i.e.
# rubocop:disable Rails/UniqueValidationWithoutIndex
validates :slug, uniqueness: true, format: { with: /\A[\w-]*\z/ }, length: { maximum: 255 }
# rubocop:enable Rails/UniqueValidationWithoutIndex

@coding-bunny @andyw8 #349 has been merged. It also fixed an error when validates is not in class.

@coding-bunny That's strange... if you move the RuboCop directives to only around the validates lines, does it still occur? i.e.
# rubocop:disable Rails/UniqueValidationWithoutIndex
validates :slug, uniqueness: true, format: { with: /\A[\w-]*\z/ }, length: { maximum: 255 }
# rubocop:enable Rails/UniqueValidationWithoutIndex

Yes, it doesn't matter at all where those comments were placed.
Actually RuboCop threw me a warning saying that they are "useless" and should be removed even.

@coding-bunny @andyw8 #349 has been merged. It also fixed an error when validates is not in class.

Thank you!
Will wait on the next release then

@coding-bunny I had success disabling the check at the .rubocop.yml level.

Yeah but I don't want the check disabled or the file ignored.

I have a situation in which this is coming up in which I have the proper index, but I'm using a scoped unique constraint, AND the table is in a secondary database.

This issue has been resolved by https://github.com/rubocop-hq/rubocop-rails/pull/349 and RuboCop Rails 2.8.1 has been released. Can you upgrade to the latest RuboCop Rails?

@koic Do you have any thoughts on @Jay-Schneider critique of that PR in his message above?

@Tietew: I can confirm your fix removes the error. But I am not sure if this implements the correct behaviour. See, the table does exist in our cases and is also declared in the schema.rb. Simply not running the cop against the concerned model/table seems like a hack. I believe, if I would add a validation without the unique index in such a nested class it would not be detected as an offense. If I have the time I will take a look into it myself and maybe comment your PR.

I tend to agree with @Jay-Schneider. If the class that the validation is crashing on is actually a subclass of a model with a table in the database, shouldn't the real fix be to walk the inheritance up to the ActiveRecord Base class and check for a matching table?

I think the undefined method 'with_column?' for nil:NilClass error that is the subject of the issue has been resolved. Please open another issue or a PR to improve the message. This is a technical note. Since RuboCop is a static analysis tool, it cannot use run-time analysis like Module#ancestors. Thank you.

authors: Bialogs Jay-Schneider MrJoy Tietew Timmitry andyw8 coding-bunny koic rbclark

repo: rubocop/rubocop-rails


text:
Error in Metrics/MethodLength in 1.54.0

Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /Users/jcoyne85/workspace/sul-dlss/sul-embed/lib/embed/media_tag.rb
An error occurred while Metrics/MethodLength cop was inspecting /Users/jcoyne85/workspace/sul-dlss/sul-embed/lib/embed/media_tag.rb:41:4.
undefined method `last_line' for nil:NilClass
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/parser-3.2.2.3/lib/parser/source/map.rb:118:in `last_line'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node.rb:266:in `last_line'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:199:in `block in source_from_node_with_heredoc'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:111:in `block in visit_descendants'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `each'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `visit_descendants'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:112:in `block in visit_descendants'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `each'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:108:in `visit_descendants'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/node/mixin/descendence.rb:63:in `each_descendant'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:192:in `source_from_node_with_heredoc'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:77:in `code_length'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/utils/code_length_calculator.rb:25:in `calculate'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/mixin/code_length.rb:36:in `check_code_length'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/metrics/method_length.rb:52:in `on_def'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:107:in `public_send'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:107:in `block (2 levels) in trigger_responding_cops'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:171:in `with_cop_error_handling'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:106:in `block in trigger_responding_cops'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:105:in `each'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:105:in `trigger_responding_cops'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:69:in `on_def'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `each'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:154:in `on_class'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_class'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:138:in `on_while'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:71:in `on_module'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.29.0/lib/rubocop/ast/traversal.rb:20:in `walk'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/commissioner.rb:87:in `investigate'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/team.rb:156:in `investigate_partial'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cop/team.rb:98:in `investigate'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:345:in `block in inspect_file'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:344:in `each'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:344:in `flat_map'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:344:in `inspect_file'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:287:in `block in do_inspection_loop'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:321:in `block in iterate_until_no_changes'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:314:in `loop'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:314:in `iterate_until_no_changes'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:283:in `do_inspection_loop'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:164:in `block in file_offenses'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:189:in `file_offense_cache'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:163:in `file_offenses'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:154:in `process_file'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:135:in `block in each_inspected_file'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:134:in `each'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:134:in `reduce'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:134:in `each_inspected_file'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:120:in `inspect_files'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/runner.rb:73:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/command.rb:11:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli/environment.rb:18:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:118:in `run_command'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:125:in `execute_runners'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:51:in `block in run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:77:in `profile_if_needed'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/lib/rubocop/cli.rb:43:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/exe/rubocop:19:in `block in <top (required)>'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/3.2.0/benchmark.rb:311:in `realtime'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/rubocop-1.54.0/exe/rubocop:19:in `<top (required)>'
/Users/jcoyne85/.rbenv/versions/3.2.2/bin/rubocop:25:in `load'
/Users/jcoyne85/.rbenv/versions/3.2.2/bin/rubocop:25:in `<top (required)>'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/cli/exec.rb:58:in `load'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/cli/exec.rb:58:in `kernel_load'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/cli/exec.rb:23:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/cli.rb:486:in `exec'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/cli.rb:31:in `dispatch'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/cli.rb:25:in `start'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/exe/bundle:48:in `block in <top (required)>'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/lib/bundler/friendly_errors.rb:120:in `with_friendly_errors'
/Users/jcoyne85/.rbenv/versions/3.2.2/lib/ruby/gems/3.2.0/gems/bundler-2.3.24/exe/bundle:36:in `<top (required)>'
/Users/jcoyne85/.rbenv/versions/3.2.2/bin/bundle:25:in `load'
/Users/jcoyne85/.rbenv/versions/3.2.2/bin/bundle:25:in `<main>'
.

1 file inspected, no offenses detected

1 error occurred:
An error occurred while Metrics/MethodLength cop was inspecting /Users/jcoyne85/workspace/sul-dlss/sul-embed/lib/embed/media_tag.rb:41:4.
Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
https://github.com/rubocop/rubocop/issues

Mention the following information in the issue report:
1.54.0 (using Parser 3.2.2.3, rubocop-ast 1.29.0, running on ruby 3.2.2) [x86_64-darwin22]
Finished in 0.7649310000706464 seconds

The offending method looks like this:
    def media_element(file, type)
      file_thumb = stacks_square_url(@purl_document.druid, file.thumbnail.title, size: '75') if file.thumbnail
      media_wrapper(thumbnail: file_thumb, file: file) do
        <<~HTML
          #{access_restricted_overlay(file.try(:stanford_only?), file.try(:location_restricted?))}
          <#{type}
            id="sul-embed-media-#{file_index}"
            data-src="#{streaming_url_for(file, :dash)}"
            data-auth-url="#{authentication_url(file)}"
            #{poster_attribute(file)}
            controls='controls'
            aria-labelledby="access-restricted-message-div-#{file_index}"
            class="sul-embed-media-file #{'sul-embed-many-media' if many_primary_files?}"
            height="100%">
            #{enabled_streaming_sources(file)}
            #{transcript(file)}
          </#{type}>
        HTML
      end
    end

It appears to me like this is triggered by Heredoc inside a block.
A method like this seems to be able to trigger it:
    def name
      map do
        <<~HTML
          X
          X
          X
          X
          X
          X
          X
          X
          X
          X
          X
          X
          X
        HTML
      end
    end

This issue is a dup with https://github.com/rubocop/rubocop/issues/12013 and fixed by https://github.com/rubocop/rubocop/pull/12011. Thank you.

Thanks for the response @koic.

source: gharchive/issue

authors: jcoyne koic

repo: rubocop/rubocop

license: MIT

license_type: permissive

license_source: github-api


text:
how to parse a csv file with a metadata file

I have a csv file and a metadata file on my file system. With csv2rdf I can write
csv2rdf -t data/pplEx.csv -u pplEx.csv-meta.json -m minimal

in order to transform data/pplEx.csv using the pplEx.csv-meta.json metadata file. This will return ntriples for the csv file.
I can't work out how to do the same with rdf-tabular. All the examples use http urls which gives me the impression that one first has to setup special headers in the csv http headers. IS that right, or have I missed the command line needed when debugging.
I wanted to see if rdf-tabular had more advanced features than csv2rdf. For example I was interested to see what I need to do to get foreign keys to work. This is the csv file
Id,Name,DoB,Sex,mother
1,Linus,02-07-2016,male,4
2,Oliver,02-07-2016,male,4
3,Anaïs,10-09-2014,female,4
4,Gordana,30-05-1982,female,

this is the metadata file
{
  "@context": [ "http://www.w3.org/ns/csvw", { "@language": "en"} ],
  "dc:title": "example people data",
  "tableSchema": {
   "@id" : "http://example.com/",
   "columns": [
     {
        "name": "Id"
      }, {
        "name": "Name",
        "datatype": "string"
     },  {
        "name": "DoB",
        "datatype": {
          "base": "date",
          "format": "dd-MM-yyyy"
        }
      }, {
        "name": "Sex",
        "datatype": "string"
     }, {
        "name": "mother"
      } ],
    "primaryKey":"Id",
    "foreignKeys": [{
        "columnReference": "mother",
        "reference": {
	  "schemaReference": "http://example.com/",
          "columnReference": "Id"
        }
      }]
   }
}

Typically, the metadata is looked for in the same place as the CSV (or visa-versa). For example, if you were to clone the repo and install rdf-tabular, rdf-turtle, and rdf gems, you can do the following:
rdf serialize --input-format tabular --output-format ttl etc/doap.csv

You should also be able to do essentially the same thing on the distiller, using the text forms for both the CSV and Metadata.

yes, I am trying to put together the simplest foreign key example: the one where the key is in the same table schema as the table itself. I could not find that described anywhere in the w3c docs. I did I think find an example in the github repo, but I did not seem to get any interesting result with csv2rdf. So I am not sure...
My use case is also to think of csvw as a schema language which could be reused on an open-ended number of matching CSV files. So for that it helps to be able to pass the metadata file from the command line, not just the http header.  In any case I think for command line exploration of the tool being able to pass it on the command line is really useful. It would have been too difficult to get going without that.

After placing the metadata file with the name pplex.csv-metadata.json in the same directory as the csv file i was able to produce the RDF with
rdf serialize --input-format tabular --output-format ttl  pplex.csv

What I was hoping to get using the foreignkeys construct was to see if it would align the blank nodes so without specifying any URL.
But I guess foreignkeys only really work with the valueUrl and aboutUrl fields set.
I am trying to put together a demonstration where I can show that just by setting <#Id> to be an owl:InverseFunctional property I can avoid having to specify URLs for subjects or values.   Ie I was trying to get the following output from the table above:
[]  <#Name> "Anaïs" ;
    <#DoB> "2014-09-10"^^<http://www.w3.org/2001/XMLSchema#date> ;
    <#Id> 3 ;
    <#Sex> "female" ;
    <#mother> [ <#Id>  4 ] .

But I don't think that is possible even with virtual columns.

I write something up here: https://github.com/w3c/csvw/issues/885

authors: bblfish gkellogg

repo: ruby-rdf/rdf-tabular

license: unlicense

license_source: bigquery


text:
Installation in devcontainer fails on Apple Silicon

I cannot install the gem in a VSCode devcontainer running on an Apple M1 machine; it complains that some vital component is missing.
The README says I need a C99 compiler and GNU make, but there's not really much of a clue on how to set this up in devcontainers. Adding the llvm and make features doesn't help (and Ruby is already installed and working).
Would it be possible for the README to list the features that need to be installed for devcontainer users? (Even better: would it be possible to have pre-compiled binaries available for Apple Silicon, thus saving a lot of time when rebuilding the container? :)
devcontainer.json
{
  "name": "Ruby on Rails & Postgres",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}",

  "features": {
    "ghcr.io/itsmechlark/features/redis-server:1": {},
    "ghcr.io/jungaretti/features/make:1": {},
    "ghcr.io/devcontainers-community/features/llvm:3": {}
  },

  "forwardPorts": [],

  "postCreateCommand": "bundle install && rake db:setup",

  "remoteUser": "vscode"
}

Output log
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /usr/local/rvm/gems/default/gems/prism-0.29.0/ext/prism
/usr/local/bin/ruby extconf.rb
checking for prism.h in /usr/local/rvm/gems/default/gems/prism-0.29.0/include...
yes
checking for prism/extension.h in
/usr/local/rvm/gems/default/gems/prism-0.29.0/ext... yes
checking for whether -fvisibility=hidden is accepted as CFLAGS... yes
Running make build/libprism.a with {"SOEXT"=>"so", "MAKEDIRS"=>"/bin/mkdir -p",
"RMALL"=>"rm -fr"}
compiling build/static/diagnostic.o
compiling build/static/encoding.o
compiling build/static/node.o
compiling build/static/options.o
compiling build/static/pack.o
compiling build/static/prettyprint.o
compiling build/static/prism.o
Assembler messages:
Fatal error: can't create build/static/prism.o: No such file or directory
make: *** [Makefile:58: build/static/prism.o] Error 1
*** 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=${opt-dir}/include
        --without-opt-include
        --with-opt-lib=${opt-dir}/lib
        --without-opt-lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/usr/local/bin/$(RUBY_BASE_NAME)
        --enable-build-debug
        --disable-build-debug
        --enable-build-minimal
        --disable-build-minimal
extconf.rb:51:in `system': Command failed with exit 2: make (RuntimeError)
        from extconf.rb:51:in `block in make'
        from extconf.rb:50:in `chdir'
        from extconf.rb:50:in `make'
        from extconf.rb:136:in `<main>'

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

/usr/local/rvm/gems/default/extensions/aarch64-linux/3.3.0/prism-0.29.0/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in /usr/local/rvm/gems/default/gems/prism-0.29.0
for inspection.
Results logged to
/usr/local/rvm/gems/default/extensions/aarch64-linux/3.3.0/prism-0.29.0/gem_make.out

  /usr/local/lib/ruby/3.3.0/rubygems/ext/builder.rb:125:in `run'
  /usr/local/lib/ruby/3.3.0/rubygems/ext/ext_conf_builder.rb:28:in `build'
  /usr/local/lib/ruby/3.3.0/rubygems/ext/builder.rb:193:in `build_extension'
/usr/local/lib/ruby/3.3.0/rubygems/ext/builder.rb:227:in `block in
build_extensions'
  /usr/local/lib/ruby/3.3.0/rubygems/ext/builder.rb:224:in `each'
  /usr/local/lib/ruby/3.3.0/rubygems/ext/builder.rb:224:in `build_extensions'
  /usr/local/lib/ruby/3.3.0/rubygems/installer.rb:852:in `build_extensions'
/usr/local/lib/ruby/3.3.0/bundler/rubygems_gem_installer.rb:76:in
`build_extensions'
  /usr/local/lib/ruby/3.3.0/bundler/rubygems_gem_installer.rb:28:in `install'
  /usr/local/lib/ruby/3.3.0/bundler/source/rubygems.rb:205:in `install'
  /usr/local/lib/ruby/3.3.0/bundler/installer/gem_installer.rb:54:in `install'
/usr/local/lib/ruby/3.3.0/bundler/installer/gem_installer.rb:16:in
`install_from_spec'
/usr/local/lib/ruby/3.3.0/bundler/installer/parallel_installer.rb:132:in
`do_install'
/usr/local/lib/ruby/3.3.0/bundler/installer/parallel_installer.rb:123:in
`block in worker_pool'
  /usr/local/lib/ruby/3.3.0/bundler/worker.rb:62:in `apply_func'
  /usr/local/lib/ruby/3.3.0/bundler/worker.rb:57:in `block in process_queue'
  <internal:kernel>:187:in `loop'
  /usr/local/lib/ruby/3.3.0/bundler/worker.rb:54:in `process_queue'
/usr/local/lib/ruby/3.3.0/bundler/worker.rb:90:in `block (2 levels) in
create_threads'

An error occurred while installing prism (0.29.0), and Bundler cannot
continue.

In Gemfile:
  ruby-lsp-rails was resolved to 0.3.7, which depends on
    ruby-lsp was resolved to 0.17.1, which depends on
      prism
[22385 ms] postCreateCommand failed with exit code 5. Skipping any further user-provided commands.

Hey @unikitty37 — I think this might be an issue where prism it being installed twice at the same time. It's being installed once with bundle and then another time while ruby-lsp is installing it. This is creating a conflict in the gem installation directory. We'll look into some solutions here.

I opened an issue for this upstream in rubygems (https://github.com/rubygems/rubygems/issues/7786). In the meantime I'll see if there's a way we can look at handling this in prism specifically.

@unikitty37 it looks like a lot of work is happening on rubygems to fix this, so I'm going to let them track this as a wholesale solution appears to be coming soon at https://github.com/rubygems/rubygems/issues/7786

repo: ruby/prism


text:
Speeding up with indexes

Should we use that to display and add missing indexes? The app still seems to be still slow.
https://github.com/plentz/lol_dba
http://rakeroutes.com/blog/increase-rails-performance-with-database-indexes/
http://weblog.rubyonrails.org/2011/12/6/what-s-new-in-edge-rails-explain/

I think it is already pretty fast :) But let's discuss that in the evening at the Monstas meeting.

done!

authors: tyranja zaziemo


text:
JavaScript

JavaScript
User Story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

Finished javascript

repo: rubyonline/prework-study-guide


text:
Revert "feat(connection): make possible to use external RabbitMQ connection"

Reverts rudijs/amqp.node-rpc-factory#8

Coverage increased (+0.8%) to 100.0% when pulling c8f4370a5fd93c461e78843f22d626ec0f37d38c on revert-8-feat/connection-option into 87ebdc49814f0792cd19f140763ed26e72d4acd9 on master.

source: gharchive/pull-request

authors: coveralls rudijs

license: mit


text:
Is this a bug or intended behavior?

I was having trouble with a form validating. I could not get it to validate to save my life ($ctrl.form.$invalid was returning true no matter what).
It turns out that the reason it was happening was because I was initializing an ngModel variable with an empty string then using it within the <color-picker ng-model="", which for some reason, caused the form to give me an error of "undefined" .. Maybe i'm not understanding the way ngForm works, maybe this could be a possible bug, i'm not sure, but I wanted to share my observations.
So...

initialize an ngModel with an empty string ""  (ex: this.formModel.color1 = "" )
then apply that model to the color-picker <color-picker ng-model="$ctrl.formModel.color1" ...
the form never validates..

I was getting this error :
{
  "$error": {
    "undefined": [
      {
        "$viewValue": "",
        "$modelValue": "",
        "$validators": {},
        "$asyncValidators": {},
        "$parsers": [],
        "$formatters": [],
        "$viewChangeListeners": [],
        "$untouched": true,
        "$touched": false,
        "$pristine": true,
        "$dirty": false,
        "$valid": false,
        "$invalid": true,
        "$error": {
          "undefined": true
        },
        "$name": "",
        "$options": {}
      }
    ]
  }

here is the code in question...inside of the array.push, changing the empty string to an rgba() value causes the form to validate no questions.
let colors = ['bg_color', 'color_1', 'color_2', 'color_3', 'color_4']; // list of color columns from the DB

  colors.forEach((element, index) => {
    // setup the _colors model and give them some random values
    this.formModel._colors.push({name: element, value: (element === 'bg_color') ? '' : 'rgba(0,' + 20 * index + ',' + 20 * index + ', 1.0)'});

    // color picker options
    this.colorPickerOptions[index] = {
      display_name: (element === 'bg_color') ? 'Background Overlay' : element.replace('_', ' ').capitalizeFirstLetter(),
      options: {
        placeholder: 'rgba(1,2,3,0.0)',
        id: element,
        name: element,
        pos: 'bottom right',
        format: 'rgb',
        restrictToFormat: true,
        close: {
          show: true
        },
        lightness: true
      }
    };
  });

I'm going to add a few more things here to maybe find a few fixes for some issues i'm having with the color picker..
I was setting the model value to an empty string because I wanted to display a transparent color picker (http://i.imgur.com/XJDKGWh.png)
Which works fine, even if I replace the empty string with say rgba(0,0,0,0.0) HOWEVER, it looks like this (http://i.imgur.com/taS9JEW.png) when you open the color picker, which is super confusing from a UI/UX perspective. It would be nice if when you open it, it looked sort've like this (http://i.imgur.com/GL2UgH7.png) but the far right slider was set to transparent. Is this at all possible to accomplish?

Your second issue has been fixed in commit 5d86d0e8422e362855f2d753f4b53724039b1db9

As for your first issue tinycolor doesn't like an empty string, empty object or null (as they are not valid colors).
This line calculates the validity - https://github.com/ruhley/angular-color-picker/blob/master/src/scripts/controller.js#L44
And then it is applied to angularjs a little lower - https://github.com/ruhley/angular-color-picker/blob/master/src/scripts/controller.js#L71
I think the best solution may be to add another configuration option to allow empty values to be valid.
What are your thoughts?

I'd say empty strings as not valid would be the expected behavior though a fail safe wouldn't hurt. I haven't had a chance to check out the commit yet but I appreciate you taking the time to point out the sections of code and implementing a fix.

I have made a new release of v3.2.0. I have also fixed the undefined problem you were having earlier.

repo: ruhley/angular-color-picker


text:
chore: add 'late_chunking' for Jina embedding

Modifications:

renamed parameter: task_type to task
extended parameter: late_chunking

@DresAaron cool idea to add late chunking, but we need to make a couple of changes to use it in an ingestion pipeline like this:
const pipeline = new IngestionPipeline({
    transformations: [
      new JinaAIEmbedding({ useLateChunking: true}),
      new SentenceSplitter({ useLateChunking: true, chunkSize: 1024 }),
    ],
  });

(Note that the embedding is called before the chunking)
The reason is that by using late chunking, we get not just one embedding per text but an array of embeddings (one embedding for each token in the text, see https://github.com/jina-ai/late-chunking).
Here are some changes I can think of to make it work:

We need to store the token embeddings produced by JinaAIEmbedding in BaseNode (as the pipelines TransformerComponents work on BaseNode instances)
The SentenceSplitter must consider token embeddings of the input BaseNode and copy them to the output BaseNodes according to the splitting (this applies for other splitters, too).
When an embedding for a node is used, we must apply mean pooling to convert the token embeddings to one embedding for the node (this could maybe be done lazily, or we have to trigger it explicitly, e.g. with a new MeanPoolEmbeddings transformer)

@DresAaron, would you like to look into this?

@DresAaron cool idea to add late chunking, but we need to make a couple of changes to use it in an ingestion pipeline like this:
const pipeline = new IngestionPipeline({
    transformations: [
      new LateChunking({ embedModel: new JinaAIEmbedding(...), splitter: new SentenceSplitter({ chunkSize: 1024 }) })
    ],
  });

The reason is that by using late chunking, we get not just one embedding per text but an array of embeddings (one embedding for each token in the text; see https://github.com/jina-ai/late-chunking).
The LateChunkingSplitter could be implemented like this:

Call JinaAIEmbedding for the input node and temporarily store the token embeddings of that input node.
Call the assigned splitter to split input nodes into a list of output nodes
Tokenize the text of each output node (the splitted text) and assign token embeddings for the output node (handle the case that splitter doesn't split at token boundaries)
Calculate the final embedding for each output node by using mean pooling of the output node's token embeddings

@DresAaron, would you like to look into this?

@marcusschiesser late_chunking by Jina Embedding model v3 does not change the return format, you can check the blogpost here: https://jina.ai/news/late-chunking-in-long-context-embedding-models/
Technically, we don't need to change anything for the pipeline.

@DresAaron Sorry, maybe there's a misunderstanding. I read https://jina.ai/news/late-chunking-in-long-context-embedding-models/
and here the change of the data pipeline is mentioned:

According to this, using late chunking, we call the embedding model on the whole document, and it returns embeddings for each token of the document.

@marcusschiesser since we are using the API in the implementation, just like jina-embeddings-v2-base-en, the response of jina-embeddings-v3 model in the end returns same format. jina-embeddings-v3 is already available, maybe you can try it out at: https://jina.ai/embeddings/ 😄

@DresAaron, I guess we've been talking about two different things, but now I am still wondering how to get the token embeddings of a longer text using Jina. Please let me know if you find out.

authors: DresAaron marcusschiesser

repo: run-llama/LlamaIndexTS


text:
[Bug]: LLMCompiler fails with Tool{tool_name} not found value error

Bug Description
Tool names cannot be found when agent.chat is called even though the plan is created.
Version
0.10.34
Steps to Reproduce

Use any tool (using duckduckgo search as an example)
tools = DuckDuckGoSearchToolSpec().to_tool_list()

Create LLM model and agent

llm = Ollama(model="phi3", request_timeout=30.0, temperature=0.9)
callback_manager = llm.callback_manager
agent_worker = LLMCompilerAgentWorker.from_tools(
    tools, llm=llm, verbose=True, memory=chat_memory, callback_manager=callback_manager
)
agent = AgentRunner(agent_worker, callback_manager=callback_manager)

Relevant Logs/Tracbacks
File "/Users/user/Library/Python/3.9/lib/python/site-packages/llama_index/agent/llm_compiler/utils.py", line 85, in instantiate_new_step
    tool = _find_tool(tool_name, tools)
  File "/Users/user/Library/Python/3.9/lib/python/site-packages/llama_index/agent/llm_compiler/utils.py", line 55, in _find_tool
    raise ValueError(f"Tool {tool_name} not found.")
ValueError: Tool search not found.

The LLM is predicting a tool name that doesn't exist is my guess? I'm not sure what your tool names/descriptions look like, but try to make them unique and descriptive

For the example I provided the tool names are ['duckduckgo_instant_search', 'duckduckgo_full_search'] (can be found using [tool.metadata.name for tool in tools]). Strangely though the error is ValueError: Tool search not found.. I came up with a small hotfix where I check equality of the name and also whether the tool_name is in the names of the tools in the _find_tools function. Ok if I send up a PR?

I'm using the version with the PR above merged (0.10.48.post1), and the same error still exists.
I set the tools following the official cookbook,
def multiply(a: int, b: int) -> int:
    """Multiple two integers and returns the result integer"""
    return a * b

multiply_tool = FunctionTool.from_defaults(fn=multiply)

def add(a: int, b: int) -> int:
    """Add two integers and returns the result integer"""
    return a + b

add_tool = FunctionTool.from_defaults(fn=add)

tools = [multiply_tool, add_tool]

But my agent stilled tried to "search" something,
> Plan: 1. search(3)
2. multiply(121, $1)
3. add($2, 42)
4. join()<END_OF_PLAN>
assistant: Plan accepted. Processing...

After executing the plan, the result is: 363

Your plan has been executed and the answer is 363.

And it failed unsurprisingly with same error ValueError: Tool search not found.

@HejiaZ2023 you need to update the agent integration probably? Assuming you are using an openai agent
pip install -U llama-index-agent-openai

There's even unit test for this

Hi @logan-markewich I think both OP and I are using local LLM inference, not openai (OP mentioning Ollama, I'm using vllm)
(And I did check my llama-index-agent-openai version is latest, 0.2.7)
My best guess would be the PR fixed an agent-shared get_function_by_name, but llm_compiler agent is using its own _find_tool in llama_index/agent/llm_compiler/utils.py? (which is where it raised an Exception for both OP and me)


text:
Try-catch in case the ._client attribute is not present

Description
In my unit tests (outside of this repo), I found that sometimes the ._client attribute is not present, leading to failed tests when it calls the del function. This is a bugfix on #13611.
New Package?
Did I fill in the tool.llamahub section in the pyproject.toml and provide a detailed README.md for my new integration or package?

[ ] Yes
[x] No

Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[ ] Yes
[x] No

Type of Change
Please delete options that are not relevant.

[X] 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

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
I ran my unit tests that uses llama_index outside of the repo.
Suggested Checklist:

[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[X] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I ran make format; make lint to appease the lint gods

Thanks @joshkyh!
Please kindly do the following:

run make lint and make format, commit changes and push (our lint checks are failing)
update the version number in llama-index-vector-stores-supabase/pyproject.toml

@joshkyh -- no worries.... I took care of this. Thanks for the fix.

Thanks @nerdai, I was running the commands on my Windows wsl and it took an hour and haven't completed. Appreciate the help!

authors: joshkyh nerdai


text:
DashScope llm support async call_with_messages

Description
DashScope llm support async call_with_messages
Fixes # (issue)
New Package?
Did I fill in the tool.llamahub section in the pyproject.toml and provide a detailed README.md for my new integration or package?

[ ] Yes
[x] No

Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[x] Yes
[ ] No

Type of Change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] 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

How Has This Been Tested?
Your pull-request will likely not be merged unless it is covered by some form of impactful unit testing.

[ ] I added new unit tests to cover this change
[x] I believe this change is already covered by existing unit tests

Suggested Checklist:

[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added Google Colab support for the newly added notebooks.
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I ran make format; make lint to appease the lint gods

I don't think your tests are written quite correctly, seeing fixture 'mocker' not found in the test failures

I don't think your tests are written quite correctly, seeing fixture 'mocker' not found in the test failures

I fixed it

authors: logan-markewich yimao


text:
Ground items on/off toggle-button

Like CTRL or something.
This would be really good for people like me who likes to pk and don't want to see a lot text on screen all the time.
Would be good everywhere else too.

OSBuddy has this feature, using the Alt key. +1

Duplicate of #1141

authors: Anthedon Nightfirecat deathbeam

repo: runelite/runelite


text:
Checkmark to skill calculator for dmm exp multiplier.

Simply: Marked=5x exp multiplier(thus makes everything have divided by 5 required amounts for the target lvl) and unmarked=regular osrs exp.
also 5x because its easier to code than 10x->5x at decreasing multiplier.

How does the decreasing in DMM work again?

10x on lvl 1 that decreases by 0.1 per lvl until at 50 its 5x.

i was wondering if this was on the way? would still love it, even when jagex has moved away from dmm tournaments.

For what it's worth, this could be solved in a more general way by adding an optional multiplier which can be adjusted by the user. This could be useful for users with variable exp multipliers in leagues and such.

I think if we were to add this, this ought to be an input field for a multiplier number (int probably, I don't think there's ever been a case where non-integer multiplication has happened), possibly paired with buttons or radio options to set it to the value for any active game mode. (DMM, league, etc.)

authors: Nightfirecat badgehunter forsco


text:
Obsidian Client redesign issues

Noticed since the update some stuff has dissapeared (dunno if some of it was intentional or not)
-Double click on highscores doesnt search your name
-No button for skill tracker site or reset all in skill tracker (i know you can currently right click to reset but having a left click option is good too)
-Left click on the individual skill icons doesnt reset the skill in skill tracker (by icon i mean saw for construction, sword for attack, tree for woodcutt etc)
Just some things ive noticed so far

You can double click on the search icon to autofill your own name
You can access the online tracker by right clicking
You can reset all by right clicking the header
You can reset an individual skill with a right click, the previous behavior of clicking on the icon was confusing for many people
Putting multiple issues in 1 bug report makes it difficult for us to track issues. In the future please separate multiple bugs into multiple issues

Why were the left click options removed then? Cause iirc we had both the left click buttons and right clicks

They were removed because they were confusing, and people often clicked on them accidentally because they didn't show what they were supposed to do. If you want a left click option, I would recommend that you open a new issue specifically for that.

authors: Abextm Stickaplex


text:
My GPU usage shoots up from 15% to 100% when the plugin is enabled.

Disabled - https://i.imgur.com/Hmjhyy4.png
Enabled - https://i.imgur.com/rPIfbdK.png
My graphics processor is an AMD A8 with AMD radeon R5 graphics. There should be no issue, but yet the game becomes incredibly laggy. Yes, the drivers are fully updated.

That's the kind of the point of the plugin. To use your GPU.
Which A8 do you have?

That's the kind of the point of the plugin. To use your GPU.
Which A8 do you have?

The processor in device manager just says "AMD A8-6410 APU with AMD Radeon R5 graphics" It's a laptop, as my gaming PC has a dead PSU. :(
I understand the point is to use the GPU but my entire computer seems to be chugging with the plugin enabled as well as a drop in FPS in game. Input lag even when typing this comment. Sure, 100% GPU might be normal elsewhere but this is runescape, right?

That chip doesn't really meet the processing requirements of the GPU plugin, sorry to inform you.
As you may know, APU chips aren't the most graphically powerful especially when compared to their Intel counterparts.

Ah, I actually didn't know that. Really wasn't expecting it to not meet the requirements because I used to play games like Smite on it pretty decently. If you say it's not enough then at least I know it's not some non-hardware problem, which is a good thing. Thanks.

Looks like this is expected behaviour

authors: Dephire deathbeam raiyni


text:
Disable left click for clearing bank fillers

I sometimes load into the bank too quickly and clicking on the item I want clears a single bank filler instead. This leads to me having to replace the filler if I notice it and if I close the bank I have to rearrange my items.

Bank fillers open a right-click menu by default on left click, don't they?

This might be something Jagex has to fix then. Normally left clicking pulls up the menu but in the situation I mentioned it'll clear the single filler with just a left click.


text:
Farming time tracker show when partially ready

Can the farming time trackers change to maybe show a yellow "Ready" when some of the patches in that section are finished? For example the tree tab, if you hardwood trees are ready but my normal trees aren't, instead of showing "Ready Sunday at 9:05", it tells you that some of the patches are ready

+1 to this idea. Would love to see it implemented

authors: Maaziasq Shady-Slim


text:
Add support for resizable overlays

Add mostly complete support for resizable overlays.
Closes #3916
Original PR: #4509
Signed-off-by: Tomas Slusny slusnucky@gmail.com
Preview:

Added javadoc, removed that shadowed stuff & added docs

If you resize an overlay in a hotspot it will be moved out of the hotspot, but still be in the same spot, under other overlays.

Fixed. Also fixed small issue with stuff jumping around while resizing (its not jumping around at all anymore)

If you try to resize a WidgetOverlay it will offset it

Hmmmmm. Maybe I should just add some isResizable flag to Overlay, set it to true in OverlayPanel and also in ScreenMarker overlay and just ignore rest. I think that would be safest approach?

Alright, updated with that

Updated, changed the tolerance to 5px

Updated. Good catch with the gap. Now infoboxes are wrapped at 4 by default, I updated the description of input consuming commit and reverted the change in NpcAggroOverlay and changed it to use setClearChildren(false) instead.

This still does not wrap at 4 infoboxes for me, but now 5, by default.

authors: Adam- abextm deathbeam


text:
BossTimerPlugin: Find bosses based on id instead of name

Add support for multi-phase bosses such as Kalphite Queen

How did decide which of the 7 ids for KQ to use, and why are there 7 to begin with?

Why not use the api NpcID?

I do not know

You'll need to use the VETION_REBORN id or else the death timer will start after first phase instead of when the boss actually dies.

I even had the correct id before 🤦♀

Needs rebase

Rebased and added a few goodies

authors: Alexsuperfly Infinitay MagicfTail deathbeam


text:
Debugging tool for simplification

We can run the prover itself incrementally, by running one rewrite step at a time.
We should architect the new simplifier to be able to do something similar. This will make it much easier for both developers and users to debug the backend/their semantics.

@goodlyrottenapple and @jberthold please add any ideas you have to this issue.

(Summarising points I remember from brainstorming during stand-up:)

The simplifier iterations are currently not observable , and it is hard to observe the simplifier alone at all.
As a debugging tool we could think about logging the term during simplifier iterations (where applicable) to a file, similar to the recent change #3284  to log rewrite rule applications to a yaml file.
A stand-alone tool could consume such a simplificaiton log to display a diff-like view of a pretty-printed term
Both logs (rewriting and simplification) should probably write a combined yaml log file, in order for the tool to identify the execution steps.

authors: ana-pantilie jberthold

repo: runtimeverification/haskell-backend


text:
Tab completion doesn not work with -c option

When restricting z to match only subdirectories of curent dir with -c, pressing tab appears to do nothing

It actually "works", you just don't have a directory with '-c' in history.
It would be nice to have tab completion work the way you expect tho, will be a bit of a refactor though.

lets leave it open so i don't forget it would be nice to do something about this

authors: ptzz rupa

repo: rupa/z

license: WTFPL


text:
batch delete unassigned/missing scripts

a button would be great to delete all unassigned/missing scripts of the selected avatar

Already a feature in the WIP build. Grab it from my discord or download the zip of the master branch.

authors: AlexViktorAV rurre

repo: rurre/PumkinsAvatarTools


text:
RSSelection menu Action Sheet

Unable to set the done or cancel button in the action sheet

I opened a pull request to resolve this issue https://github.com/rushisangani/RSSelectionMenu/pull/91

You can use my fork as a temp solution until the pull request is being merged.

pod 'RSSelectionMenu', :git => 'https://github.com/AmjadAlSawafta/RSSelectionMenu.git', :tag => '6.0.7'

I opened a pull request to resolve this issue #91

Thank you for your reply. the code in #91 is working only for the below versions of iOS 13. it's not working on iOS 13.

@saitejapanditi67 Welcome.
I opened another revision and tagged it '6.0.8'. I hope it will work probably on the  iOS 13.

You can not set UIAlertAction style to cancel for iPad,  popover will not display that type of action.
Change  in RSSelectionMenuController.swift -> getAlertViewController
let doneAction = UIAlertAction(title: actionTitle, style: .default) { [weak self] (doneButton) in
self?.menuWillDismiss()
}
style: should be  .default to show Done Button in ActionSheet.

Hello @all,
The issue is still existed but only for iPad below iOS 13.
The code is working fine in iOS 13 but not in iOS 12.
See, "Done" button is not visible in iOS 12.
See this:
Does anyone have a solution?
Help needed
#91

repo: rushisangani/RSSelectionMenu


text:
Add new constructor to SignedRequest and use that in services.

Please help keep the CHANGELOG up to date by providing a one sentence summary of your change:
Add new constructor to SignedRequest to reduce number of function calls made in generated code.
An attempt to reduce the amount of code each crate generates. While the total number of lines of code increased, that's due to rustfmt changes. Each affected crate has tens or hundreds of function calls in it replaced by a single function call in rusoto_core.
Not sure how to test if this improves compilation speed or crate size. Any thoughts?

Inconclusive results running git checkout master ; git clean -fdx ; time make check_integration_test and this branch. Times were within 10% or so of each other, well within compilation time jitter on my laptop.

Ideas for seeing if this helps or not:

count the lines of code emitted to LLVM: consider a drop in lines a win
check packaged crate size for services via cargo publish --dry-run. Smaller file size is a win

Closing until I can get some data around this change. 😄

repo: rusoto/rusoto


text:
Code: visibleRanges support

Split off #1294.
We should only highlight the visible range, not the whole file. See onDidChangeTextEditorVisibleRanges under https://code.visualstudio.com/api/references/vscode-api#window.

We shlould highlight a bit around the visible range to prevent issues when scrolling. Also what about the minimap?

(╯°□°)╯︵ ┻━┻

Minimap should probably just use fast highlighter based purely on lexer. This should also follow the relevant developments in VS Code/LSP. Note, in particular, that the existing proposed extension focuses on incremental update for the whole file, which I think is exactly wrong, and that from-scratch update for the visible region of file is more important (but I haven't implemented either, so take this with a grain of salt).

obsoleted by semancit tokens

authors: bjorn3 lnicola matklad

repo: rust-analyzer/rust-analyzer


text:
Add assist to transform an Into impl into a From impl

As of Rust 1.51, clippy is linting for Into implementations and suggesting converting them into From implementations:
struct Example {
    some_field: u32
}

impl Into<u32> for Example {
    fn into(self) -> u32 {
        self.some_field
    }
}

warning: an implementation of `From` is preferred since it gives you `Into<_>` for free where the reverse isn't true
 --> src/lib.rs:5:1
  |
5 | impl Into<u32> for Example {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(clippy::from_over_into)]` on by default
  = help: consider to implement `From` instead
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#from_over_into

The transformation here is a pretty boring, manual process:
impl From<Example> for u32 {
    fn from(val: Example) -> Self {
        val.some_field
    }
}

If RA could do this for me with an assist that would be sweet!

Slightly more complex example:
impl Into<FillTarget> for AutoFillItemDomain {
    fn into(self) -> FillTarget {
        match self {
            Self::App { app_id, .. } => FillTarget::AppId(app_id),
            Self::Url(url) => FillTarget::Url(url),
        }
    }
}

Should transform into:
impl From<AutoFillItemDomain> for FillTarget {
    fn from(val: AutoFillItemDomain) -> Self {
        match val {
            AutoFillItemDomain::App { app_id, .. } => FillTarget::AppId(app_id),
            AutoFillItemDomain::Url(url) => FillTarget::Url(url),
        }
    }
}

Note how the usage of Self has been adjusted appropriately.

I don't really know what I'm doing but I've managed to throw together an implementation of this - will try and submit a PR tomorrow.

authors: Cldfire obmarg


text:
RA 2021-23-05 can't bootstrap on Windows

It looks like some path stuff got messed up on accident.
Note in the ERROR report at the end how it's using a path that's D:\\C:\\, which is clearly always going to be incorrect on windows.
INFO [5/23/2021, 4:29:55 PM]: Extension version: 0.3.608
INFO [5/23/2021, 4:29:55 PM]: Using configuration {
  cargoRunner: null,
  runnableEnv: null,
  inlayHints: {
    enable: false,
    smallerHints: true,
    chainingHints: false,
    maxLength: 25,
    parameterHints: false,
    typeHints: false
  },
  updates: { channel: 'nightly', askBeforeDownload: false },
  server: { path: null, extraEnv: null },
  trace: { server: 'off', extension: false },
  debug: {
    engine: 'auto',
    sourceFileMap: {
      '/rustc/<id>': '${env:USERPROFILE}/.rustup/toolchains/<toolchain-id>/lib/rustlib/src/rust'
    },
    openDebugPane: false,
    engineSettings: {}
  },
  assist: {
    importGranularity: 'crate',
    importEnforceGranularity: false,
    importPrefix: 'plain',
    importGroup: true
  },
  callInfo: { full: true },
  cargo: {
    autoreload: true,
    allFeatures: false,
    features: [],
    runBuildScripts: true,
    useRustcWrapperForBuildScripts: true,
    noDefaultFeatures: false,
    target: null,
    noSysroot: false
  },
  checkOnSave: {
    enable: true,
    allFeatures: null,
    allTargets: false,
    command: 'build --examples',
    noDefaultFeatures: null,
    target: null,
    extraArgs: [],
    features: null,
    overrideCommand: null
  },
  completion: {
    addCallArgumentSnippets: true,
    addCallParenthesis: true,
    postfix: { enable: true },
    autoimport: { enable: true }
  },
  diagnostics: {
    enable: true,
    enableExperimental: true,
    disabled: [],
    remapPrefix: {},
    warningsAsHint: [],
    warningsAsInfo: []
  },
  files: { watcher: 'client', excludeDirs: [] },
  highlighting: { strings: true },
  hoverActions: {
    debug: true,
    enable: true,
    gotoTypeDef: true,
    implementations: true,
    run: true,
    linksInHover: true
  },
  lens: {
    debug: true,
    enable: true,
    implementations: true,
    run: true,
    methodReferences: false,
    references: false
  },
  linkedProjects: [],
  lruCapacity: null,
  notifications: { cargoTomlNotFound: true },
  procMacro: { enable: true, server: null },
  runnables: { overrideCargo: null, cargoExtraArgs: [] },
  rustcSource: null,
  rustfmt: { extraArgs: [ '+nightly' ], overrideCommand: null },
  workspace: { symbol: { search: { scope: 'workspace', kind: 'only_types' } } },
  displayInlayHints: false,
  'cargo-watch': { command: 'build' },
  featureFlags: { 'notifications.workspace-loaded': false }
}
INFO [5/23/2021, 4:29:55 PM]: PersistentState: {
  lastCheck: 1621808988372,
  nightlyReleaseId: 43427417,
  serverVersion: '0.3.582'
}
ERROR [5/23/2021, 4:29:55 PM]: Bootstrap error [Error: ENOENT: no such file or directory, mkdir 'D:\C:\Users\Daniel\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer'] {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'mkdir',
  path: 'D:\\C:\\Users\\Daniel\\AppData\\Roaming\\Code\\User\\globalStorage\\matklad.rust-analyzer'
}

Will be fixed by https://github.com/rust-analyzer/rust-analyzer/pull/8951

As a temporary workaround, downgrading the VSCode extension to version 0.2.599 worked for me:

Open the Extensions pannel (View > Extensions, or Ctrl+Shift+X) and select rust-analyzer.
Open the dropdown next to the "Uninstall" button and select "Install Another Version..." (see attatched screenshot).
Select version 0.2.599.
Reload VSCode window (or restart VSCode). There will be a blue button to do this under the rust-analyzer section you selected in setp 1.

A new version which should fix this issue has been published to the Code marketplace.

authors: CamWass Lokathor Veykril lnicola


text:
Weird token mapping behaviour

Given the following snippet:
macro_rules! f {
    ( struct $ident:ident ) => {
        struct $ident {
            map: ::std::collections::HashSet<()>,
        }
    };
}

f!(struct MyTraitMap2);

The struct token in the token tree input of the f! call gets highlighted white, it becomes a comma token wise according to our highlighting infra. If you remove the <()> part of the field path(or just replace it with some path that doesnt use generics like u32) the token properly becomes a keyword again(hover also starts to work on it again). Removing the trailing comma of the field also makes it map to a keyword correctly again.

I'm a but surprised this is being remapped in any way at all given this is a literal token that isn't really being remapped as its not being matched into a fragment and then being reused.


text:
infer: Add type inference support for Union types

This adds the type inference to Union types and add a small test case
for it, ensuring it keeps working in future.
Fixes: #5277
Signed-off-by: Otavio Salvador otavio@ossystems.com.br

Thanks!
bors r+

authors: flodiebold otavio


text:
Support 'go to definition' for self

Also reverts #6660, instead of showing the type it now works like it does for names by returning the declaration we are already on. This for example enables VSCode to show all references(#6665) when executing go to definition on the declaration.

bors r+

I wonder what's the super correct behavior here.

When "gotodef" on self reference, we should go to self parameter.
When "gotodef" on self parameter, we should find references
"goto type def" on both should, well, go to the struct / enum

But I often also want to go the impl header instead.... Perhaps "goto type" should be changed to that?

Isn't there also "go to implementation"? We could reinterpret that :sweat_smile:

Lol yes, we can totally re-use goto impl here. Although I am a bit less sure about not re-using "go to type", beacause it doesn't have a clear impl imo.
I am thinking about this case:
struct Container<T>(T);

impl Container<String> {
    fn foo(&self) {}
}

Here, going to Container<T> loses the info about the fact that T is a String. The type of self is Self, which is a type-alias for the type declared in the impl's header.
The example seems equivalent to
type SelfType = Container<String>;
fn foo(this: &SelfType) {
}

to me.
Hm.... Now that I've spelled this out, I kinda lean towards changing "goto type", the alias thinking seems convincing to me (not that it is hard to convince oneself...)

That's a somewhat convincing argument, buut...
let me = self;

I'd expect "go to type" to work the same on me and self since they have the same type. Now this could actually work that way once we implement "lazy normalization" of type aliases; then go to type for Self-typed values could go to the impl, and it could also go to type aliases.
So my suggestion would be to make "go to impl" do this now, and "go to type" later when we can handle type aliases consistently there :smile:

authors: Veykril flodiebold jonas-schievink matklad


text:
Add a comment to delineate test_macros re-export

The formatter removes an empty line that is clearly better to have. Add a rustdoc comment to at least delineate the line a bit.

Perhaps make it non-doc comment instead?

Done, no other changes.

authors: Kixunil tcharding

repo: rust-bitcoin/rust-bitcoin


text:
Apostrophe in contractions is turned into *(Aq, subsequently swallowed by pandoc

We produce manual pages using roff-rs, then render them as  HTML for our web site.  I have noticed that apostrophes in contractions and marking of possessive cases area not present in the produced HTML:
$ cat src/main.rs
fn main() {
    let mut r = roff::Roff::new();
    r.text(vec!["I've been a good boy.".into()]);
    println!("{}", r.render());
}
$ cargo run > astropof.1
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/foobr`
$ cat astropof.1
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
I\*(Aqve been a good boy.

$ man ./astropof.1|hd
00000000  49 27 76 65 20 62 65 65  6e 20 61 20 67 6f 6f 64  |I've been a good|
00000010  20 62 6f 79 2e 0a 0a                              | boy...|
00000017
$ pandoc -o astropof.txt astropof.1
$ cat astropof.txt
Ive been a good boy.

Now, I'm not an expert on roff, but one of the manual pages that I consult for advice on writing manual pages says not to use \(aq to escape ordinary apostrophes.  https://man7.org/linux/man-pages/man7/groff_man_style.7.html says:
You should not use \(aq for an ordinary apostrophe (as in “can't”)

Through experimentation I discovered that pandoc renders both ' and \(aq just fine.

To clarify: I think there are two issues here:

roff-rs unconditionally replaces apostrophes where it shouldn't (e.g. in contractions).
roff-rs uses the \*(Aq workaround which doesn't sit well with pandoc.

I have no idea what to do about either issue, but I wanted to report it.

I just noticed the documentation of Roff::to_roff says:

Without special handling, apostrophes get typeset as right single quotes, including in words like “don’t”. In most situations, such as in manual pages, that’s unwanted.

That comment gets it wrong.  In contractions, like "don't", you do want to allow renderers to use fancy glyphs, and in fact that is what rustdoc renders it to in the example:
$ echo -n don’t | hd
00000000  64 6f 6e e2 80 99 74                              |don...t|
00000007

Glyph e2 80 99 is RIGHT SINGLE QUOTATION MARK.  Where you don't want that kind of fancy glyphs is code samples, which you expect people to copy and paste and have them work right.

You probably want render or to_writer instead of this method.

In fact, I switched to using this method, and this yields perfect results for me: both Debian's man and pandoc render apostrophes as 27 i.e. APOSTROPHE both in text as well as code blocks.

repo: rust-cli/roff-rs


text:
Prepare for v0.7.3

We've had #337 merged for a while and it seems like it would be helpful for users to get it released, and now #344 to go with it. No other changes since then (except a small doc change) so it should be an easy release.

r? @rust-embedded/cortex-m

repo: rust-embedded/cortex-m


text:
Without critical-section feature, Rust gets confused about missing take()

Currently the Peripherals::take() method is gated behind the critical-section optional dependency (and thus feature). Without the feature enabled, the method isn't available, because it requires the critical-section crate and we wanted to make that dependency optional (#651).
However it turns out if you call take() on a struct that doesn't have that method, Rust thinks you wanted to call the method on the Iterator trait that's imported by default, and then you get a pretty confusing error message about Peripherals not implementing Iterator (example):
struct Foo;

fn main() {
    let f = Foo {};
    f.take();
}

error[[E0599]](https://doc.rust-lang.org/stable/error-index.html#E0599): `Foo` is not an iterator
 --> src/main.rs:5:7
  |
1 | struct Foo;
  | ----------
  | |
  | method `take` not found for this struct
  | doesn't satisfy `Foo: Iterator`
...
5 |     f.take();
  |       ^^^^ `Foo` is not an iterator
  |
  = note: the following trait bounds were not satisfied:
          `Foo: Iterator`
          which is required by `&mut Foo: Iterator`
note: the following trait must be implemented
  = help: items from traits can only be used if the trait is implemented and in scope
  = note: the following trait defines an item `take`, perhaps you need to implement it:
          candidate #1: `Iterator`

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

This seems to really throw people off because there's no indication that take() didn't exist or was feature-gated. I wonder if we should either...

Make critical-section a hard dependency and always provide take(); it should build fine and only error about a missing c-s implementation if take() is actually called, in which case at least the error message is better, or
Always implement a take(), but if the critical-section feature is not enabled, use compile_error!() to emit a custom compiler error instead of the very confusing one we currently get.

Yes I've been stung by this to after the change too 😅
I think using compile_error!() could be a good idea, but how would we make that work in a good way so that critical-section doesn't become a needed dependency? compile_error!() causes a compile error whenever it is present anywhere as a result of a macro or normal source generation, i.e simply having fn foo() {compile_error!()} causes a compile time error, even if it's never used in a binary
I think having it be a missing symbol is the better alternative, but perhaps there is another way to solve it.

I ran into this issue recently, and I noticed that our pac (without critical-section) is missing take() for Peripherals but take() is present for CorePeripherals. Should this be considered a bug? In my mind CorePeripherals and Peripherals should behave in the exact same way.

Nevermind, I looked through the code and the impl Peripherals for CorePeripherals comes from the cortex-m crate.
So, it might be somewhat inconsistent but it's not really connected to svd2rust specifically.

authors: Emilgardis adamgreig martinmortsell


text:
N30: Extreme Bevy

Part of #912

oops, I messed up the links, will fix


text:
Documentation not available for alpha.19

Currently in crates.io the link to the documentation: https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.19/futures is non existent.

Looks like the auth token used to publish them is expired/revoked/doesn't have access: https://travis-ci.com/rust-lang-nursery/futures-rs/jobs/239482255#L1679

Since #1895 stops using these published docs I think it's best to delete this automation and just manually publish the alpha.19 docs so that the current link works, I can do that shortly.

Should be fixed now.

repo: rust-lang-nursery/futures-rs


text:
Error on Windows during self update in cmd.exe

This morning I ran rustup in a new cmd.exe window. Everything succeeded until the very end where it attempted a self update. The main process exited, I got my shell prompt back, and then the following message was printed:
failure during windows uninstall: The handle is invalid (os error 6)

This was reproducible in cmd.exe each time (presumably because the self update never completed). I opened up a MSYS shell, ran rustup, and it succeeded. Back in cmd.exe it then was fine as well

Looks like the same issue as this: https://github.com/brson/multirust/issues/153

I get this same error when trying to self update.

I'm wondering if this was the scopeguard problem I already fixed (which you should have after the successful update). I'll be curious to see if you are still getting it tomorrow.

I have gotten it to error with "error: unable to run updater"

Maybe we should recommend installing from rustup.rs if the self-update fails for whatever reason?

I still get the same error when running self-update from the latest master - does that contain the scopeguard fix you mentioned?

@Diggsey yes it does.

Oh, nevermind it seems to be the downloaded binary which is erroring, so any changes to local don't affect it.

Hm, if it's the downloaded binary generating the error, then it's probably not the same scopeguard problem since I think that fix is already deployed.

OK, there are only a few places this error could be generated. It actually could be a PID race I was sure would never happen cause by the way rustup-gc.exe finds its parent process.

There is potential PID race but it's not the problem, (which I've fixed in #234)
The only way I can see to fix the race is to do a second snapshot after opening the process, and checking that the parent process ID is still the same, and not null.

authors: Diggsey alexcrichton brson

repo: rust-lang-nursery/multirust-rs


text:
Highlight default enum variant

Problem
Since Rust has introduced #[default], can we hightlight it in the doc?
Like this one:
#[derive(Default)]
enum Status {
    #[default]
    Active,
    Inactive,
}

For other type of default definition of enums, it can be hard! For example, the following code, can be hard:
#[derive(...)]
enum Status {
    Active,
    Inactive,
}

impl Default for Status {
    fn default() -> Self {
        serde::from_str("active").unwrap()
    }
}

or:
#[derive(...)]
enum Status {
    Active,
    Inactive,
}

impl Default for Status {
    fn default() -> Self {
        if env!("ENV") == "prod" {
            Self::Inactive
        } else {
            Self::Active
        }
    }
}

We can ignore these cases.
Proposed Solution
No response
Notes
No response

To double check, you are asking for changes in the documentation that cargo doc generates?  If so, that would actually be with the underlying rustdoc tool and we can move this issue to the appropriate repo.

Yes, thanks

authors: epage omid

repo: rust-lang/cargo


text:
test track_caller on trait objects

Adds a Miri-side test for https://github.com/rust-lang/rust/issues/74764.

@bors r+

:pushpin: Commit 729ccbc65e6d1e0004fba28aaa7a3c9c9408c15c has been approved by RalfJung

:hourglass: Testing commit 729ccbc65e6d1e0004fba28aaa7a3c9c9408c15c with merge 4a8008560c1615818115c5be30739dc891cdd4e2...

:broken_heart: Test failed - checks-travis

macOS being slower than usual for some reason.
@bors retry

:hourglass: Testing commit 729ccbc65e6d1e0004fba28aaa7a3c9c9408c15c with merge 7b970ef05eef62ca562b11e0d80d1e66dd09f8d0...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing 7b970ef05eef62ca562b11e0d80d1e66dd09f8d0 to master...

authors: RalfJung bors

repo: rust-lang/miri


text:
fix handling of spurious accesses during retag

The dereferenceable attribute we emit for LLVM is checked during retag in Stacked Borrows.
However, we currently don't properly do that for retagging of &mut !Unpin, which this PR fixes.
Also this adjusts retagging to inform the data race model of the accesses as well.
Fixes https://github.com/rust-lang/miri/issues/2648.
Also fixes https://github.com/rust-lang/miri/issues/2693 since the same issue arose for retagging as well.
r? @saethlin

While I was touching retagging anyway, I also added a fix for https://github.com/rust-lang/miri/issues/2648.

I skimmed over this but I'm a bit fried right now, I'll look over it for real tomorrow.

I think I understand this decently well now. r=me whenever you want to merge (we have a number of outstanding PRs which may be disruptive so I'm not going to just send this)

We'll have to land them in some order... :shrug:
@bors r=saethlin

:pushpin: Commit 776460fc8dd343c1bcc772529b84f37a684cbb52 has been approved by saethlin
It is now in the queue for this repository.

:hourglass: Testing commit 776460fc8dd343c1bcc772529b84f37a684cbb52 with merge 9f30f00ce14c3a9ce1ed4b943bc83a384408431c...

:sunny: Test successful - checks-actions
Approved by: saethlin
Pushing 9f30f00ce14c3a9ce1ed4b943bc83a384408431c to master...

authors: RalfJung bors saethlin


text:
Fix unnatural translation

I think this is more natural. How about?

Thanks for the PR! I'll cc some others who may be interested in taking a look.
cc @3442853561, @Wakamatz, @KeenS

URLリンクのタイトルとしては簡潔かつ明確である方がよいと考えます。
その意味でこの翻訳の方が遥かに優れていると思います。
1点だけ、「使用実績」より「利用実績」の方がURLリンクに対する訴求力があると思うのですが、いかがでしょうか？

なるほど。私も"利用実績"のほうが自然だとおもいました。

利用実績、賛成します。

@maekawatoshiki
賛同が得られたと思うので修正お願いします。

これでどうでしょうか。

良いと思います。
Now this patch looks good to me. How about @Wakamatz ?

@maekawatoshiki
Thank you for your wonderful patch.
@alexcrichton
The review has done. Please merge this PR.

Awesome thanks for the review everyone!

authors: KeenS Wakamatz alexcrichton maekawatoshiki

repo: rust-lang/rust-www


text:
Drop support for enum_set

enum_set was moved to libcollections crate, which is unstable and we shouldn't depend on it.
(As suggested in https://github.com/rust-lang/rustc-serialize/pull/14#issuecomment-68669064)

Thanks!

repo: rust-lang/rustc-serialize