Changed; I was just lifting the architecture test out of the loop since it's invariant, but I can't imagine that perf matters that much here.

@gbunt The reported Salt version is vulnerable. We recommend upgrading as soon as possible to at least the latest point release of v3002: https://github.com/saltstack/salt/releases/tag/v3002.6 or to latest. You can find those on releases here in GitHub or the package repo. Likely your issue will persist, but if you are able to upgrade can you please confirm the issue is still seen, please?

Hi I got issue when run AppScan as below

Please help to fix. <!-- NOTE: This repository is for issues with the https://swagger.io website content.

If you have a question or issue with the OpenAPI Specification or Swagger tools, please ask your question at the community forum:

https://community.smartbear.com/t5/Swagger-Open-Source-Tools/bd-p/SwaggerOSTools

-->

Hi

I got issue below when run AppScan

Please help to fix. <!-- NOTE: This repository is for issues with the https://swagger.io website content.

If you have a question or issue with the OpenAPI Specification or Swagger tools, please ask your question at the community forum:

https://community.smartbear.com/t5/Swagger-Open-Source-Tools/bd-p/SwaggerOSTools

-->

Hi

I got this issue when run AppScan.

Please help to fix. <!-- NOTE: This repository is for issues with the https://swagger.io website content.

If you have a question or issue with the OpenAPI Specification or Swagger tools, please ask your question at the community forum:

https://community.smartbear.com/t5/Swagger-Open-Source-Tools/bd-p/SwaggerOSTools

-->

https://swagger.io/docs/specification/describing-parameters/ check under "Header Parameters" and the table, where it says "Accept". It says it is part of responses.<code>.content.<media-type> and the link in the last column also links to response.

But Accept is part of a request.

@shixuan-fan I'm not sure where to get the ConnectorId from when initializing the CONNECTOR_SESSION with the toConnectorSession(ConnectorId connectorId) method.

As far as I can tell, this is basically a wash on just about every benchmark, except for the incredibly small/short ones where link time is a sufficiently large percentage of the total time that even a small change in the link time is prominent. (For instance, the largest regression is in helloworld.) As far as I can tell, in absolute rather than percentage terms, this seems negligible. Could I get some help confirming that from the perf results? If that's the case, I think this may potentially be worth doing, to make linking more robust and more usable.

(That said, I may potentially be able to reduce the cost further. We don't really need a linker group around the pure-Rust libraries, for instance.)

Also, this new idea will be most effective when we have row_number=1 pushdown to scan operator. So for now, don't change anything.

Is anyone else still seeing this problem in Salt 3003.1 (in my case against a Ubuntu 18.04 target)?

$ salt --versions
Salt Version:
          Salt: 3003.1

Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 2.10.1
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: 1.1.4
       msgpack: 1.0.0
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: Not Installed
  pycryptodome: 3.9.9
        pygit2: Not Installed
        Python: 3.8.5 (default, May 27 2021, 13:30:53)
  python-gnupg: Not Installed
        PyYAML: 5.3.1
         PyZMQ: 20.0.0
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.3

System Versions:
          dist: ubuntu 20.04 focal
        locale: utf-8
       machine: x86_64
       release: 5.10.16.3-microsoft-standard-WSL2
        system: Linux
       version: Ubuntu 20.04 focal

redacted.host.com:
    ----------
    _error:
        Failed to return clean data
    retcode:
        1
    stderr:
        Traceback (most recent call last):
          File "/var/tmp/.djn_165e34_salt/pyall/salt/loader_context.py", line 10, in <module>
            import _contextvars as contextvars
        ModuleNotFoundError: No module named '_contextvars'

        During handling of the above exception, another exception occurred:

        Traceback (most recent call last):
          File "/var/tmp/.djn_165e34_salt/salt-call", line 27, in <module>
            salt_call()
          File "/var/tmp/.djn_165e34_salt/pyall/salt/scripts.py", line 437, in salt_call
            import salt.cli.call
          File "/var/tmp/.djn_165e34_salt/pyall/salt/cli/call.py", line 6, in <module>
            import salt.cli.caller
          File "/var/tmp/.djn_165e34_salt/pyall/salt/cli/caller.py", line 14, in <module>
            import salt.loader
          File "/var/tmp/.djn_165e34_salt/pyall/salt/loader.py", line 26, in <module>
            import salt.config
          File "/var/tmp/.djn_165e34_salt/pyall/salt/config/__init__.py", line 103, in <module>
            _DFLT_IPC_WBUFFER = _gather_buffer_space() * 0.5
          File "/var/tmp/.djn_165e34_salt/pyall/salt/config/__init__.py", line 91, in _gather_buffer_space
            import salt.grains.core
          File "/var/tmp/.djn_165e34_salt/pyall/salt/grains/core.py", line 32, in <module>
            import salt.modules.cmdmod
          File "/var/tmp/.djn_165e34_salt/pyall/salt/modules/cmdmod.py", line 31, in <module>
            import salt.utils.templates
          File "/var/tmp/.djn_165e34_salt/pyall/salt/utils/templates.py", line 20, in <module>
            import salt.utils.jinja
          File "/var/tmp/.djn_165e34_salt/pyall/salt/utils/jinja.py", line 21, in <module>
            import salt.fileclient
          File "/var/tmp/.djn_165e34_salt/pyall/salt/fileclient.py", line 15, in <module>
            import salt.client
          File "/var/tmp/.djn_165e34_salt/pyall/salt/client/__init__.py", line 28, in <module>
            import salt.cache
          File "/var/tmp/.djn_165e34_salt/pyall/salt/cache/__init__.py", line 19, in <module>
            from salt.payload import Serial
          File "/var/tmp/.djn_165e34_salt/pyall/salt/payload.py", line 15, in <module>
            import salt.loader_context
          File "/var/tmp/.djn_165e34_salt/pyall/salt/loader_context.py", line 13, in <module>
            import contextvars
          File "/var/tmp/.djn_165e34_salt/py3/contextvars.py", line 1, in <module>
            from _contextvars import Context, ContextVar, Token, copy_context
        ModuleNotFoundError: No module named '_contextvars'
    stdout:
Completed in 0m57.7s, using 10.32% CPU.

ERROR: salt-ssh failed with exit code 20.

Well, the test passes when run in x86_64-pc-windows-msvc, though I'd like additional clarity on what we want to do with the various calling conventions on non-i686(/i586) platforms before relaxing the only header command.

I have really enjoyed using beanie. Highly recommend. 👍

If both definitions are in the same scope, it results in E0428 ("the name mumble is defined multiple times"). I wasn't able to find a test for the case where the definitions have different calling conventions, but test/ui/issues/issue-28472.rs comes close; it's two extern "C" functions with the same name and signature.

If the definitions are in different blocks (say, one inside a function and one at module top-level), then rustc just issues a lint warning: "mumble redeclared with a different signature;" this is covered by test/ui/lint/clashing-extern-function.rs. Do we need to upgrade this to an error?

I have what looks like a variant case, and Jeff pointed me to this case. I'm willing to open another issue, but I thought I'd add my findings.

My keys were all accepted before I created this nodegroup.

I did a full cache flush using the method Whytewolf suggested here: https://github.com/whytewolf/salt-phase0-orch/blob/master/orch/sys/salt/update.sls

My node group of the form:

group1: L@minion1, minion2, minion3

Works

My node group of the form:

group2:

• minion1
• minion2
• minion3

Does not work

My node group of the form with boolean or works:

group3:

• minion1
• 'or'
• minion2
• 'or'
• minion3

My node group in list form with L@ works:

group4:

• L@minion1,minion2,minion3

Salt Version: Salt: 3003

Dependency Versions: cffi: 1.13.2 cherrypy: 8.9.1 dateutil: 2.7.3 docker-py: Not Installed gitdb: 2.0.5 gitpython: 2.1.11 Jinja2: 2.10 libgit2: 1.1.0 M2Crypto: Not Installed Mako: Not Installed msgpack: 0.5.6 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: 2.19 pycrypto: 3.9.4 pycryptodome: 3.6.1 pygit2: 1.6.1 Python: 3.7.3 (default, Apr 3 2019, 05:39:12) python-gnupg: Not Installed PyYAML: 3.13 PyZMQ: 17.1.2 smmap: 2.0.5 timelib: Not Installed Tornado: 4.5.3 ZMQ: 4.3.1

System Versions: dist: debian 10 buster locale: UTF-8 machine: x86_64 release: 4.19.0-6-amd64 system: Linux version: Debian GNU/Linux 10 buster

re-run pr-opensuse-15-x86_64-py3-pytest re-run pr-ubuntu-2004-amd64-py3-pycryptodome-pytest

Description

If you pass an empty non-dict datatype to defaults.merge (defaults.update), you get the following stracktrace

local:
    Data failed to compile:
----------
    Rendering SLS 'base:monitoring.bug' failed: Jinja error: Cannot update using non-dict types in dictupdate.update()
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/salt/utils/templates.py", line 501, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))
  File "/usr/lib/python3.6/site-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 15, in top-level template code
  File "/usr/lib/python3.6/site-packages/jinja2/sandbox.py", line 462, in call
    return __context.call(__obj, *args, **kwargs)
  File "/usr/lib/python3.6/site-packages/salt/modules/defaults.py", line 134, in merge
    return dictupdate.update(merged, src, merge_lists=merge_lists)
  File "/usr/lib/python3.6/site-packages/salt/utils/dictupdate.py", line 45, in update
    raise TypeError("Cannot update using non-dict types in dictupdate.update()")
TypeError: Cannot update using non-dict types in dictupdate.update()

Setup

Copy/paste the following into your ssh session on your master...

<details><summary>1. create state file and reset grains</summary>

{% load_yaml as conf %}
default:
  loglevel:  error  (default)

role:
  db:
    loglevel: info (from role)

stage:
  dev:
    loglevel: debug (from stage)
{% endload %}

# Get the values...
{% set val_role  = salt.grains.filter_by(conf.role,    grain='role') %}
{% set val_stage = salt.grains.filter_by(conf.stage, grain='stage') %}

# Merge them...
{% set vals = salt.defaults.merge(conf.default, val_role) %}
{% set vals = salt.defaults.merge(vals,         val_stage) %}

Demonstrate Loglevel configuration:
  test.show_notification:
    - text: |
        stage: {{ salt.grains.get('stage', 'NOT SET') }}
        role:  {{ salt.grains.get('role', 'NOT SET') }}
        vals:
          loglevel: {{ vals.loglevel }}
EOF

salt-call grains.delkey role
salt-call grains.delkey stage

</details>

2. Ensure that the "role" and "stage" grains aren't set

# salt-call grains.delkey role
# salt-call grains.delkey stage

Steps to Reproduce the behavior

<details><summary>1. Run it (salt-call state.apply example) and get a big, ugly stacktrace</summary>

local:
    Data failed to compile:
----------
    Rendering SLS 'base:monitoring.bug' failed: Jinja error: Cannot update using non-dict types in dictupdate.update()
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/salt/utils/templates.py", line 501, in render_jinja_tmpl
    output = template.render(**decoded_context)tage, grain='stage') %}
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 1090, in render
    self.environment.handle_exception()
  File "/usr/lib/python3.6/site-packages/jinja2/environment.py", line 832, in handle_exception
    reraise(*rewrite_traceback_stack(source=source))stage) %}
  File "/usr/lib/python3.6/site-packages/jinja2/_compat.py", line 28, in reraise
    raise value.with_traceback(tb):
  File "<template>", line 21, in top-level template code
  File "/usr/lib/python3.6/site-packages/jinja2/sandbox.py", line 462, in call
    return __context.call(__obj, *args, **kwargs)
  File "/usr/lib/python3.6/site-packages/salt/modules/defaults.py", line 134, in merge
    return dictupdate.update(merged, src, merge_lists=merge_lists)
  File "/usr/lib/python3.6/site-packages/salt/utils/dictupdate.py", line 45, in update
    raise TypeError("Cannot update using non-dict types in dictupdate.update()")
TypeError: Cannot update using non-dict types in dictupdate.update()

; line 21

---
[...]
# Get the values...
{% set val_role  = salt.grains.filter_by(conf.role,    grain='role') %}
{% set val_stage = salt.grains.filter_by(conf.stage, grain='stage') %}

# Merge them...
{% set vals = salt.defaults.merge(conf.default, val_role) %}    <======================
{% set vals = salt.defaults.merge(vals,         val_stage) %}

Demonstrate Loglevel configuration:
  test.show_notification:
    - text: |
[...]
---

</details>

2. Obviously, if you set the grains....

salt-call grains.set role db
salt-call grains.set stage dev

<details><summary>3. And then run it (salt-call state.apply example), it works</summary>

local:
----------
          ID: Demonstrate Loglevel configuration
    Function: test.show_notification
      Result: True
     Comment: stage: dev
              role:  db
              vals:
                loglevel: debug (from stage)
     Started: 23:42:22.633862
    Duration: 1.346 ms
     Changes:

Summary for local
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   1.346 ms

</details>

Expected behavior

I can understand that defaults.update() wants a dict for both datasets, but if it's passed an empty dict or NoneType it should simply return the remaining dataset that is a dict. If both input datasets are empty/None then it should just return an empty dict.

Note: My one concern about the above set of empty/None values is that if you just use a "not" comparison (as is the pythonic way), the values for bool:False, str:'' (empty string), list:[ ], tuple:( ) will also be implicitly included in this request. I think that these values should raise the exception because they are, explicitly, a non-dict type and just letting them through would be a side-effect (and side-effects inevitably lead to 2am debugging sessions for some poor sod later on down the road)

What I'm not clear on is what is being passed to the renderer when when a salt.grains.filter_by() returns an empty dataset. I'm guessing that it's probably a NoneType, but perhaps it's an empty string (I doubt it, but I haven't looked)?

Ideally it's a NoneType and the fix is simple - test for isinstance(NoneType) or isinstance(dict) and not param

Anyways... There are a couple of workarounds for this , like supplying a "defaults" key under each subsection and then passing that key as the default return for filter_by(). Or, if you don't want to pollute your data with a bunch of defaults, you can do this:

{% set vals = salt.defaults.merge(conf.default, val_role if val_role else { }) %}
{% set vals = salt.defaults.merge(conf.default, val_stage if val_stage else {} ) %}

But it's just messy and it complicates the jinja and makes it harder to read... and jinja is already visually displeasing enough.

Versions Report <details><summary>salt --versions-report</summary> (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
          Salt: 3002.6

Dependency Versions:
          cffi: 1.9.1
      cherrypy: 5.6.0
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: 0.6.4
     gitpython: 1.0.1
        Jinja2: 2.11.1
       libgit2: Not Installed
      M2Crypto: 0.35.2
          Mako: Not Installed
       msgpack: 0.6.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.14
      pycrypto: Not Installed
  pycryptodome: 3.10.1
        pygit2: Not Installed
        Python: 3.6.8 (default, Nov 16 2020, 16:55:22)
  python-gnupg: Not Installed
        PyYAML: 3.13
         PyZMQ: 17.0.0
         smmap: 0.9.0
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.1.4

System Versions:
          dist: centos 7 Core
        locale: UTF-8
       machine: x86_64
       release: 3.10.0-957.1.3.el7.x86_64
        system: Linux
       version: CentOS Linux 7 Core

</details>

Additional context Add any other context about the problem here.

This pull request fixes #85871. The code in rustc_mir_build/src/check_unsafety.rs incorrectly assumes that a closure's owner always has a body, but only functions, closures, and constants have bodies, whereas a closure can also appear inside a struct or enum:

struct S {
    arr: [(); match || 1 { _ => 42 }]
}

enum E {
    A([(); { || 1; 42 }])
}

This pull request fixes the resulting ICE by checking whether the closure's owner is an ADT and only deferring to thir_check_unsafety(owner) if it isn't.

:hourglass: Testing commit b5610fbdae367f395899a40a4e92fd84e4d2d34c with merge 09bf8ad2a3c51c6434130c2ab1537a1f9eacf5cd... <!-- homu: {"type":"BuildStarted","head_sha":"b5610fbdae367f395899a40a4e92fd84e4d2d34c","merge_sha":"09bf8ad2a3c51c6434130c2ab1537a1f9eacf5cd"} -->

<!-- Thank you for finding an Internal Compiler Error! 🧊 If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples.

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

-->

Code

code from glacier fixed 67405.rs

struct Bug {
    inner: [(); match || 1 {
        n => n(),
    }],
}

fn main() {}

Meta

<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. -->

rustc --version --verbose:

rustc 1.54.0-nightly (c1e8f3a58 2021-05-30)
binary: rustc
commit-hash: c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b
commit-date: 2021-05-30
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

Error output

error: internal compiler error: compiler/rustc_middle/src/hir/map/mod.rs:423:13: body_owned_by: struct Bug (hir_id=HirId { owner: DefId(0:3 ~ 67405[c442]::Bug), local_id: 0 }) has no associated body
 --> ./67405.rs:1:1
  |
1 | / struct Bug {
2 | |     inner: [(); match || 1 {
3 | |         n => n(),
4 | |     }],
5 | | }
  | |_^

thread 'rustc' panicked at 'Box<Any>', /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/compiler/rustc_errors/src/lib.rs:951:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.54.0-nightly (c1e8f3a58 2021-05-30) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z thir-unsafeck=yes

query stack during panic:
#0 [thir_body] building THIR for `Bug`
#1 [thir_check_unsafety] unsafety-checking `Bug`
end of query stack
error: aborting due to previous error

<!-- Include a backtrace in the code block by setting RUST_BACKTRACE=1 in your environment. E.g. RUST_BACKTRACE=1 cargo build. --> <details><summary><strong>Backtrace</strong></summary> <p>

error: internal compiler error: compiler/rustc_middle/src/hir/map/mod.rs:423:13: body_owned_by: struct Bug (hir_id=HirId { owner: DefId(0:3 ~ 67405[c442]::Bug), local_id: 0 }) has no associated body
 --> ./67405.rs:1:1
  |
1 | / struct Bug {
2 | |     inner: [(); match || 1 {
3 | |         n => n(),
4 | |     }],
5 | | }
  | |_^

thread 'rustc' panicked at 'Box<Any>', /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/compiler/rustc_errors/src/lib.rs:951:9
stack backtrace:
   0:     0x7f109006ef80 - std::backtrace_rs::backtrace::libunwind::trace::h1a39bd9a98540471
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x7f109006ef80 - std::backtrace_rs::backtrace::trace_unsynchronized::h21a1eeae7103ab3f
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x7f109006ef80 - std::sys_common::backtrace::_print_fmt::hc9ffbae9ed6a9871
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x7f109006ef80 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h17510753a34a3f09
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x7f10900dc9ac - core::fmt::write::h1e5a1f350e43b10f
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/core/src/fmt/mod.rs:1110:17
   5:     0x7f1090060805 - std::io::Write::write_fmt::h06ec27c6d028baf1
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/io/mod.rs:1588:15
   6:     0x7f1090072ddb - std::sys_common::backtrace::_print::h1a02603349b1dc60
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x7f1090072ddb - std::sys_common::backtrace::print::h0fc317d31c48cd9b
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x7f1090072ddb - std::panicking::default_hook::{{closure}}::ha522601c22d7057b
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/panicking.rs:208:50
   9:     0x7f10900728b1 - std::panicking::default_hook::hd50ab173af9a3ce8
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/panicking.rs:225:9
  10:     0x7f10908439bd - rustc_driver::report_ice::h0bbc0ae77d597594
  11:     0x7f10900735e6 - std::panicking::rust_panic_with_hook::hb5a01416e02405ad
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/panicking.rs:626:17
  12:     0x7f109171d51b - std::panicking::begin_panic::{{closure}}::hc5eb45c8a89da605
  13:     0x7f109171d436 - std::sys_common::backtrace::__rust_end_short_backtrace::h56af134c087f8aee
  14:     0x7f10916da43f - std::panicking::begin_panic::h4dde37cbe49c77b2
  15:     0x7f1091683d4d - std::panic::panic_any::hbb79d7216fdc8ce6
  16:     0x7f1091682e95 - rustc_errors::HandlerInner::span_bug::hb4b5011e06706f0f
  17:     0x7f1091683cf0 - rustc_errors::Handler::span_bug::h6b81dbf6bf10ea08
  18:     0x7f1091786901 - rustc_middle::ty::context::tls::with_opt::h5d93e51ac4f84952
  19:     0x7f1091789d40 - rustc_middle::util::bug::opt_span_bug_fmt::h73ef8867dd647d6e
  20:     0x7f1091789d0c - rustc_middle::util::bug::span_bug_fmt::h9683e8642769e3a3
  21:     0x7f10922fb1dd - rustc_middle::hir::map::Map::body_owned_by::h825b0a25ecdb4483
  22:     0x7f1091d83d60 - rustc_mir_build::thir::cx::thir_body::h8fa569ef978ff906
  23:     0x7f1091c24084 - rustc_query_system::query::plumbing::get_query_impl::h7cc106b73e3396e7
  24:     0x7f1091c7d808 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::thir_body::h46ed27445f5f3020
  25:     0x7f1091d73a46 - rustc_mir_build::check_unsafety::check_unsafety::h1c9e984bce687c62
  26:     0x7f1091d746d9 - rustc_mir_build::check_unsafety::thir_check_unsafety::h2e92784c5bbd6545
  27:     0x7f1091c21965 - rustc_query_system::query::plumbing::get_query_impl::h6d097d1e3348018d
  28:     0x7f1091c7ea1d - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::thir_check_unsafety::hd87546f1283dca94
  29:     0x7f1091d73b16 - rustc_mir_build::check_unsafety::check_unsafety::h1c9e984bce687c62
  30:     0x7f1091d746d9 - rustc_mir_build::check_unsafety::thir_check_unsafety::h2e92784c5bbd6545
  31:     0x7f1091c21965 - rustc_query_system::query::plumbing::get_query_impl::h6d097d1e3348018d
  32:     0x7f1091c7ea1d - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::thir_check_unsafety::hd87546f1283dca94
  33:     0x7f1091d45a74 - rustc_mir_build::build::mir_built::h56e529540ba9284f
  34:     0x7f1091c224b4 - rustc_query_system::query::plumbing::get_query_impl::h73bb8f77cd67afeb
  35:     0x7f1091c7d978 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::mir_built::h70879b0013c6ce6a
  36:     0x7f1091f5f228 - rustc_mir::transform::check_unsafety::unsafety_check_result::h99b6f0ef5b715a73
  37:     0x7f1091f4f8a4 - core::ops::function::FnOnce::call_once::h15ca75fa8a6fa33c
  38:     0x7f1091c176ff - rustc_query_system::query::plumbing::get_query_impl::h41a86f74a2e14daf
  39:     0x7f1091c7e96d - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::unsafety_check_result::h20ecf6154f0dad18
  40:     0x7f1091f5d7f3 - <rustc_mir::transform::check_unsafety::UnsafetyChecker as rustc_middle::mir::visit::Visitor>::visit_rvalue::h7e12db47de6e237b
  41:     0x7f1091f5f5a2 - rustc_mir::transform::check_unsafety::unsafety_check_result::h99b6f0ef5b715a73
  42:     0x7f1091f4f8a4 - core::ops::function::FnOnce::call_once::h15ca75fa8a6fa33c
  43:     0x7f1091c176ff - rustc_query_system::query::plumbing::get_query_impl::h41a86f74a2e14daf
  44:     0x7f1091c7e96d - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::unsafety_check_result::h20ecf6154f0dad18
  45:     0x7f1091dec5b3 - rustc_mir::transform::mir_const::hb201e3f5174c238f
  46:     0x7f1091c224b4 - rustc_query_system::query::plumbing::get_query_impl::h73bb8f77cd67afeb
  47:     0x7f1091c7da28 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::mir_const::hb56d6d8473ac3073
  48:     0x7f1091debcbe - rustc_mir::transform::mir_const_qualif::h030a3730373a3d88
  49:     0x7f1091db0992 - core::ops::function::FnOnce::call_once::hafa792986bac0c80
  50:     0x7f1091c3d7eb - rustc_query_system::query::plumbing::get_query_impl::hefe6cb4080d2bc78
  51:     0x7f1091c7d8ba - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::mir_const_qualif::ha31834a0f82c3022
  52:     0x7f1091daf03b - rustc_middle::mir::query::<impl rustc_middle::ty::context::TyCtxt>::mir_const_qualif_opt_const_arg::hf0c56f1b7ad3bb15
  53:     0x7f1091dcb248 - rustc_mir::const_eval::eval_queries::eval_to_allocation_raw_provider::hc342a5cc80315017
  54:     0x7f1091c55efd - rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::eval_to_allocation_raw>::compute::h50f34bc5c1b84fb8
  55:     0x7f1091c26c64 - rustc_query_system::query::plumbing::get_query_impl::h82efa1836f4eb10a
  56:     0x7f1091c7edf7 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::eval_to_allocation_raw::h2b3ca26d4a0bfe39
  57:     0x7f1091dca1aa - rustc_mir::const_eval::eval_queries::eval_to_const_value_raw_provider::h492a1f0908ef1033
  58:     0x7f1091c55f3d - rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::eval_to_const_value_raw>::compute::hf332c6ae6cc62cca
  59:     0x7f1091c2f6e5 - rustc_query_system::query::plumbing::get_query_impl::ha84d8dc8b8f75ed2
  60:     0x7f1091c7ef17 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::eval_to_const_value_raw::h46d27616aa3d4e98
  61:     0x7f1091dca09e - rustc_mir::const_eval::eval_queries::eval_to_const_value_raw_provider::h492a1f0908ef1033
  62:     0x7f1091c55f3d - rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::eval_to_const_value_raw>::compute::hf332c6ae6cc62cca
  63:     0x7f1091c2f6e5 - rustc_query_system::query::plumbing::get_query_impl::ha84d8dc8b8f75ed2
  64:     0x7f1091c7ef17 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::eval_to_const_value_raw::h46d27616aa3d4e98
  65:     0x7f109225743c - rustc_middle::mir::interpret::queries::<impl rustc_middle::ty::context::TyCtxt>::const_eval_global_id::h5b31d85c4aaa4700
  66:     0x7f109226e35d - rustc_middle::mir::interpret::queries::<impl rustc_middle::ty::context::TyCtxt>::const_eval_resolve::h05ad8dfc76427d5b
  67:     0x7f109217746a - <rustc_trait_selection::traits::project::AssocTypeNormalizer as rustc_middle::ty::fold::TypeFolder>::fold_const::ha28a1f0b5ceac03e
  68:     0x7f10921c98df - rustc_middle::ty::structural_impls::<impl rustc_middle::ty::fold::TypeFoldable for &rustc_middle::ty::TyS>::super_fold_with::h3d1c86eeb9c4b425
  69:     0x7f1092176a57 - <rustc_trait_selection::traits::project::AssocTypeNormalizer as rustc_middle::ty::fold::TypeFolder>::fold_ty::h049c3916fb026aa1
  70:     0x7f1091a9c40a - rustc_data_structures::stack::ensure_sufficient_stack::hefe9147ea437d887
  71:     0x7f1091afe29f - rustc_trait_selection::traits::project::normalize::h1e841ffb46b015bb
  72:     0x7f1091aa92a6 - rustc_typeck::check::inherited::Inherited::normalize_associated_types_in::h00760ce7401afff6
  73:     0x7f1092621b86 - <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::h84786bf42b5f18ca
  74:     0x7f109258de39 - rustc_typeck::check::wfcheck::<impl rustc_typeck::check::fn_ctxt::FnCtxt>::non_enum_variant::h20bcf38b44962457
  75:     0x7f10925d1bd4 - rustc_typeck::check::inherited::InheritedBuilder::enter::hc7b47ef61ca52619
  76:     0x7f1091a617d5 - rustc_typeck::check::wfcheck::check_item_well_formed::h984027aa615a7822
  77:     0x7f1091c21965 - rustc_query_system::query::plumbing::get_query_impl::h6d097d1e3348018d
  78:     0x7f1091c7ff2d - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::check_item_well_formed::h27d5df3cbfeb8f6e
  79:     0x7f1091a673cc - <rustc_typeck::check::wfcheck::CheckTypeWellFormedVisitor as rustc_hir::intravisit::Visitor>::visit_item::h4f8bab9036ea26bc
  80:     0x7f1091b1ac7e - rustc_data_structures::sync::par_for_each_in::h00a8051912db38e6
  81:     0x7f10925c9599 - rustc_hir::hir::Crate::par_visit_all_item_likes::h9225f9a1d7b63519
  82:     0x7f10925afb46 - rustc_session::session::Session::track_errors::h3587c68e2a0045ce
  83:     0x7f1092636de8 - rustc_typeck::check_crate::h033d52ddf5a3c52c
  84:     0x7f10919464dc - rustc_interface::passes::analysis::h44573dd1f435360d
  85:     0x7f10926fbc14 - rustc_query_system::query::plumbing::get_query_impl::hb28d9338aaa73db6
  86:     0x7f1092795619 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis::h92a4884e0478500d
  87:     0x7f1092374aa7 - rustc_interface::passes::QueryContext::enter::hb9b4b642821635fe
  88:     0x7f10923506e3 - rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter::h16bd07ff16fa3d4a
  89:     0x7f109234cf0c - rustc_span::with_source_map::h6ee13da35fa72295
  90:     0x7f109234ff28 - scoped_tls::ScopedKey<T>::set::h9c6565b722913393
  91:     0x7f1092374e4b - std::sys_common::backtrace::__rust_begin_short_backtrace::hdcf17779193f6d57
  92:     0x7f109234bc15 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hf48084e1b458d4b2
  93:     0x7f109007fad7 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hf00ff0dfc0b9e39f
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/alloc/src/boxed.rs:1575:9
  94:     0x7f109007fad7 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h236979b1b61b3517
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/alloc/src/boxed.rs:1575:9
  95:     0x7f109007fad7 - std::sys::unix::thread::Thread::new::thread_start::h8f357e546e4775fa
                               at /rustc/c1e8f3a5857c3c8d095fd212acc6ed442f4cc58b/library/std/src/sys/unix/thread.rs:71:17
  96:     0x7f108ff8d299 - start_thread
  97:     0x7f108fea2053 - clone
  98:                0x0 - <unknown>

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.54.0-nightly (c1e8f3a58 2021-05-30) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z thir-unsafeck=yes

query stack during panic:
#0 [thir_body] building THIR for `Bug`
#1 [thir_check_unsafety] unsafety-checking `Bug`
#2 [thir_check_unsafety] unsafety-checking `Bug::inner::{constant#0}::{closure#0}`
#3 [mir_built] building MIR for `Bug::inner::{constant#0}::{closure#0}`
#4 [unsafety_check_result] unsafety-checking `Bug::inner::{constant#0}::{closure#0}`
#5 [unsafety_check_result] unsafety-checking `Bug::inner::{constant#0}`
#6 [mir_const] processing MIR for `Bug::inner::{constant#0}`
#7 [mir_const_qualif] const checking `Bug::inner::{constant#0}`
#8 [eval_to_allocation_raw] const-evaluating + checking `Bug::inner::{constant#0}`
#9 [eval_to_const_value_raw] simplifying constant for the type system `Bug::inner::{constant#0}`
#10 [eval_to_const_value_raw] simplifying constant for the type system `Bug::inner::{constant#0}`
#11 [check_item_well_formed] checking that `Bug` is well-formed
#12 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error

</p> </details>

:sunny: Test successful - checks-actions Approved by: nikomatsakis Pushing f1e691da2e640bb45fe18f8a5bd8f7afa65ce21d to master... <!-- homu: {"type":"BuildCompleted","approved_by":"nikomatsakis","base_ref":"master","builders":{"checks-actions":"https://github.com/rust-lang-ci/rust/runs/2900269234"},"merge_sha":"f1e691da2e640bb45fe18f8a5bd8f7afa65ce21d"} -->

Ok, I guess it's now all done.

Included a fix for #60418 as it was a simple change to do, related to Zabbix inventory and we're already touching salt/modules/zabbix.py

@shixuan-fan Before creating the CONNECTOR_SESSION I decided to try to change the toConnectorSession method to include the ConnectorId. I couldn't make it work, but I think this could be a solution, what do you think?

What I tried to do for now was:

public ConnectorSession toConnectorSession()
    {
        Map.Entry<ConnectorId, Map<String, String>> propertiesEntry = connectorProperties.entrySet().iterator().next();
        ConnectorId connectorId = propertiesEntry.getKey();
        Map<String, String> properties = propertiesEntry.getValue();
        String presentCatalog = catalog.isPresent() ? catalog.get() : "";
        return new FullConnectorSession(this, identity.toConnectorIdentity(), properties, connectorId, presentCatalog, sessionPropertyManager);
    }

This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.

This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.

This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this.

@henriqueccapozzi this PR contains the following merge commits:

• https://github.com/ansible/ansible/commit/80dc96eac9482e18fd302f5236dd8323ff03a3b9

Please rebase your branch to remove these commits.

click here for bot help <!--- boilerplate: merge_commit_notify --->

TestZOrder

Instead of using random, can we have some concrete numbers to validate the addresses are expected? For example, we can just take the example in https://en.wikipedia.org/wiki/Z-order_curve. The reason is to avoid any mistakes made by encode that could be corrected by "decode". So we also wanna validate the output is expected without a full roundtrip.

The reason typeck succeeds is that it calls normalize_associated_types_in here.

bound_sig is Binder((<u64 as Viewable<'_>>::View)->(), [Region(BrAnon(0))]).

Before that call, liberated_sig is (<u64 as Viewable<'_>>::View)->().

Afterwards, it is (u64)->().