Escaping issue in Rust completer

[Procrat]

When using YCM with this piece of Rust code:

pub fn main() {
    let x = b'\t';
    x.
}

and the cursor at then end of x., racerd returns an internal server error (500) with the following message:

bogofile:1:9: 1:12 error: unterminated byte constant: b'
bogofile:1 let x = b'  ';
                   ^~~
thread '<unnamed>' panicked at 'Box<Any>', /home/procrat/.cargo/registry/src/github.com-88ac128001ac3a9a/syntex_syntax-0.24.0/src/parse/lexer/mod.rs:1284
stack backtrace:
   1:     0x55ab38e51d60 - std::sys::backtrace::tracing::imp::write::h4c73fcd3363076f5
   2:     0x55ab38e553ab - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h0422dbb3077e6747
   3:     0x55ab38e55033 - std::panicking::default_hook::haac48fa641db8fa2
   4:     0x55ab38e421cf - std::sys_common::unwind::begin_unwind_inner::h39d40f52add53ef7
   5:     0x55ab38c7c687 - std::sys_common::unwind::begin_unwind::hf69049ee5c762d2b
   6:     0x55ab38d1c8d7 - syntex_syntax::parse::lexer::StringReader::next_token_inner::hfb52e3081df4b0a8
   7:     0x55ab38d155f3 - syntex_syntax::parse::lexer::StringReader::advance_token::h6dac164eeb436b8d
   8:     0x55ab38cadcc6 - _<parse..lexer..StringReader<'a> as parse..lexer..Reader>::next_token::hf483b662b1eee55e
   9:     0x55ab38c14b2d - syntex_syntax::parse::lexer::Reader::real_token::haf3bbd7299004478
  10:     0x55ab38cb81ae - syntex_syntax::parse::parser::Parser::bump::hde25b5c891f67427
  11:     0x55ab38cf3a87 - syntex_syntax::parse::parser::Parser::parse_local::hd01c504e8936a1e9
  12:     0x55ab38cf4a10 - syntex_syntax::parse::parser::Parser::parse_stmt_::h0251d305ae60ef0b
  13:     0x55ab38cabaea - syntex_syntax::parse::parser::Parser::parse_stmt::h1214bb530d8f1c1e
  14:     0x55ab38c153b3 - racer::ast::string_to_stmt::hd0215d747378f9cc
  15:     0x55ab38c2fc2e - racer::ast::parse_pat_bind_stmt::h24f0e4eb4865884a
  16:     0x55ab38c64f31 - racer::matchers::match_pattern_let::h7c211853598edde3
  17:     0x55ab38c4f372 - racer::nameres::search_scope::h5573949c67e86202
  18:     0x55ab38c56b5a - racer::nameres::search_local_scopes::h9390f63f9818b794
  19:     0x55ab38c4d66e - racer::nameres::resolve_name::hc6009ba5875e1d5a
  20:     0x55ab38c07995 - racer::nameres::resolve_path::h64b1713c5a48c8a3
  21:     0x55ab38c25899 - racer::nameres::resolve_path_with_str::h3f0a52c28a3ee334
  22:     0x55ab38c1fb99 - racer::ast::resolve_ast_path::h31783309488217f0
  23:     0x55ab38c21c64 - _<ast..ExprTypeVisitor<'c, 's> as syntex_syntax..visit..Visitor<'v>>::visit_expr::h7bd28390b9552380
  24:     0x55ab38c08835 - racer::ast::get_type_of::h35c2dd93874e62ee
  25:     0x55ab38c05f4f - racer::core::complete_from_file::h76c61183c9cf7bc3
  26:     0x55ab38bfadc1 - _<engine..racer..Racer<'a> as engine..SemanticEngine>::list_completions::h01ac73973c48cdf5
  27:     0x55ab38bf00f9 - libracerd::http::completion::list::had10a77f70561399
  28:     0x55ab38b8abbb - _<F as iron..middleware..Handler>::handle::h28b201a9e96aaef8
  29:     0x55ab38dbce00 - _<Box<middleware..Handler $u2b$$u20$$u27$static$GT$$u20$as$u20$middleware..Handler$GT$::handle::h3e73a879a2a11fa3
  30:     0x55ab38d849a1 - router::router::Router::handle_method::ha0041e51f56dd89a
  31:     0x55ab38d85d99 - _<router..Router as iron..Handler>::handle::ha25cb84d4bc0e427
  32:     0x55ab38dbca48 - iron::middleware::Chain::continue_from_handler::ha476291cbd870522
  33:     0x55ab38dbab5a - _<middleware..Chain as middleware..Handler>::handle::h2b0b1a5548888d40
  34:     0x55ab38b9da32 - hyper::server::listener::spawn_with::_$u7b$$u7b$closure$u7d$$u7d$::h7081fa622dbfbc06
  35:     0x55ab38b9c6c6 - std::sys_common::unwind::try::try_fn::h9119fce6669141f4
  36:     0x55ab38e50f3b - __rust_try
  37:     0x55ab38e50ecd - std::sys_common::unwind::inner_try::h9eebd8dc83f388a6
  38:     0x55ab38ba041b - _<F as std..boxed..FnBox<A>>::call_box::heb040cb42f6b2b60
  39:     0x55ab38e53b24 - std::sys::thread::Thread::new::thread_start::h471ad90789353b5b
  40:     0x7f80296f9473 - start_thread
  41:     0x7f8029efe69c - clone
  42:                0x0 - <unknown>

However, I'm not sure whether this is a ycm or ycmd issue. I don't think racerd is at fault here, since it behaves correctly (with a 204 No Content) when I send the same message directly to racerd with curl.

It probably doesn't matter, but I'm using Arch Linux (GNU/Linux 4.6.1).

[micbou]

I can reproduce the backtrace by directly using curl. Start racerd with backtrace enabled:

$ export RUST_BACKTRACE=1
$ ./racerd serve -l -p56773
racerd listening at 127.0.0.1:56773

Create the file request.json with the following contents (note the escaped \t):

{
    "buffers": [ {
        "file_path": "test.rs",
        "contents": "pub fn main() {\nlet x = b'\\t';\nx.\n}\n"
    } ],
    "file_path": "test.rs",
    "line": 3,
    "column": 2
}

and send the request with curl:

$ curl -H "Content-Type: application/json" -d @request.json 127.0.0.1:56773/list_completions

This results in a similar backtrace as the one you posted.

Ping @jwilm

[micbou]

Seems related to this racer issue.

[Procrat]

Ah, you're right. It seems like I didn't escape it correctly either when testing it with curl.

[theli-ua]

with RLS there doesn't seem to be any stack traces in rls log. However there are no completions for x. for the given snippet either. (There are completions if you change it to let x = 't'; however)

[puremourning]

Seems an RLS issue not a ycm one.