`tokio-tungstenite` + `SkipServerVerification` + `rustls ` seems never works

[Jhonfunk]

futures-util = "0.3.29"
rustls = { version = "0.21.8", features = ["dangerous_configuration"] }
tokio = { version = "1.34.0", features = ["full"] }
tokio-tungstenite = { version = "0.20.1", features = ["rustls-tls-native-roots"] }

struct SkipServerVerification;

impl SkipServerVerification {
    fn new() -> std::sync::Arc<Self> {
        std::sync::Arc::new(Self)
    }
}

impl rustls::client::ServerCertVerifier for SkipServerVerification {
    fn verify_server_cert(
        &self,
        _end_entity: &rustls::Certificate,
        _intermediates: &[rustls::Certificate],
        _server_name: &rustls::ServerName,
        _scts: &mut dyn Iterator<Item = &[u8]>,
        _ocsp_response: &[u8],
        _now: std::time::SystemTime,
    ) -> Result<rustls::client::ServerCertVerified, rustls::Error> {
        Ok(rustls::client::ServerCertVerified::assertion())
    }
}

#[tokio::main]
async fn main() -> Result<()> {
    let config = rustls::ClientConfig::builder()
        .with_safe_defaults()
        .with_custom_certificate_verifier(SkipServerVerification::new())
        .with_no_client_auth();

    let ccc = Some(Connector::Rustls(std::sync::Arc::new(config)));

    let mut stream = tokio::net::TcpStream::connect("socketsbay.com:443").await?;

    let (mut ws_stream, ws_res) =
        wskt::client_async_tls_with_config(ws_uri, stream, None, ccc).await?;

    let (mut ws_stream, _) = wskt::connect_async("wss://socketsbay.com/wss/v2/1/demo/").await?;

    while let Some(r) = ws_stream.next().await {
        match r {
            Ok(msg) => {}
            Err(e) => {
                println!("{:?}", e);
            }
        }
    }

}

Always get this

trap at Instance { def: Item(DefId(1:15281 ~ core[c0bc]::core_arch::x86::sha::_mm_sha1rnds4_epu32)), args: [0_i32] } (_ZN4core9core_arch3x863sha19_mm_sha1rnds4_epu3217hf81eea8ed44efb6fE): llvm.x86.sha1rnds4

[agalakhov]

This happens in the SHA1 library and not in Tungstenite. Could be hardware related since the function in question is this: https://doc.rust-lang.org/stable/core/arch/x86/fn._mm_sha1rnds4_epu32.html

[Jhonfunk]

@agalakhov

Confirmed to be caused by the rust nightly version