I've managed to create a predicates_of ICE locally by changing a file in a dependency, without modifying the timestamp. When Rust tries to read in an 'external src file' from the dependency during the second compilation session, the src_hash will no longer match. This causes span_to_snippet to fail, causing us to generate a different span in predicates_of.

However, I'm not sure if this is the same ICE that you've reported. @rana: Is there any change that /home/rana/.cargo/registry/src/github.com-1ecc6299db9ec823/bitpacking-0.8.4/src/lib.rs somehow got modified between compilation sessions? Is /home/rana/.cargo on an atypical partition (e.g. NFS)?

The lsp-completion-no-cache here means not caching the returned completions from the server per keystroke. I.e,: we sent a new completion request on every user key typed. The lsp-completion--cache is used even in that case since on one keystroke, we may have multiple calling to completion-at-point function, also we used that as global var to pass value around to processing in one keystroke too. That's why the lsp-completion--cache may contain value even if lsp-completion-no-cache is set.

@yyoncho Do we have a method to force release memory immediately (not waiting for garbage collection) after the memory is no longer use by us?

I have another PR that make 0.20.0 version to work with lsp-mode in #2946

Fix yaml-language-server not working with lsp-mode in 0.20.0 version. Related: #2943

LGTM - Approved

On 6/19/21, brotzeit ***@***.***> wrote:

@brotzeit approved this pull request.

LGTM

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/emacs-ng/emacs-ng/pull/335#pullrequestreview-687855493

The last predicate listed in the error message is interesting: Binder(TraitPredicate(<Self as pck::test::bitpacking::BitPacker>), []), /home/rana/.cargo/registry/src/github.com-1ecc6299db9ec823/bitpacking-0.8.4/src/lib.rs:162:1: 263:2 (#0))

It appears to be generated here:

https://github.com/rust-lang/rust/blob/f639657fe4a16ec7704e0af77d0e5d5f587b59df/compiler/rustc_typeck/src/collect.rs#L1919-L1924

The fact that we call guess_head_span means that the span should be a single line (containing pub trait BitPacker: Sized + Clone + Copy). However, the span is for the entire definition of the BitPacker trait, indicating that guess_head_span failed.

The file in question is part of a dependency, so it shouldn't have changed between compilation sessions (if the version number changed, then we would be dealing with a different file, since the version number is included in the directory name bitpacking-0.8.4). I suspect that there's a bug in some of the filesystem-loading code involved in guess_head_span - I'll investigate further.

@Aaron1011 I'm not able to reproduce it here again as well. If I see it again I'll do a screen record and post it.

@rana: Unfortunately, I'm not able to reproduce your crash locally. Could you elaborate on the kinds if changes you were making to the tests before the crash started occuring?

:hourglass: Testing commit 15cdb28f5bd4cae04d6fd0bc9ae2faf079448d22 with merge 192920c22bc8433ab14706ee0829e707d119b74f... <!-- homu: {"type":"BuildStarted","head_sha":"15cdb28f5bd4cae04d6fd0bc9ae2faf079448d22","merge_sha":"192920c22bc8433ab14706ee0829e707d119b74f"} -->

:broken_heart: Test failed - checks-actions <!-- homu: {"type":"BuildFailed","builder_url":"https://github.com/rust-lang-ci/rust/runs/2867115187","builder_name":"checks-actions"} -->

The job test-various failed! Check out the build log: (web) (plain)

<details><summary><i>Click to see the possible cause of the failure (guessed by this bot)</i></summary>

[RUSTC-TIMING] coretests test:true 36.022
    Finished release [optimized] target(s) in 40.52s
     Running tests/lib.rs (build/x86_64-unknown-linux-gnu/stage2-std/wasm32-unknown-unknown/release/deps/coretests-d7406a103b3fd9c6.wasm)
RuntimeError: unreachable
    at __rust_start_panic (<anonymous>:wasm-function[1988]:0x1503ff)
    at rust_panic (<anonymous>:wasm-function[1977]:0x15010b)
    at _ZN3std9panicking20rust_panic_with_hook17h5ccb5bdcd34631a8E (<anonymous>:wasm-function[1970]:0x14fdd0)
    at _ZN3std9panicking11begin_panic28_$u7b$$u7b$closure$u7d$$u7d$17h4b079a85c853017cE (<anonymous>:wasm-function[718]:0xd50c3)
    at _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17hebc5c9bf2558c4a9E (<anonymous>:wasm-function[717]:0xd508a)
    at _ZN3std9panicking11begin_panic17hc9d2eb3c14256968E (<anonymous>:wasm-function[173]:0x84a51)
    at _ZN9coretests4iter8adapters3zip45test_zip_trusted_random_access_next_back_drop17h78266124f4eb31b9E (<anonymous>:wasm-function[216]:0x891fb)
    at _ZN4core3ops8function6FnOnce9call_once17h226bf9d90c80c729E (<anonymous>:wasm-function[852]:0xddfee)
    at _ZN4test28__rust_begin_short_backtrace17h64f35c79219c786dE (<anonymous>:wasm-function[1600]:0x11c3cf)
    at _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h2aad70032d941592E (<anonymous>:wasm-function[1599]:0x11c3b1)
    at _ZN4test8run_test14run_test_inner17h05c809612e14f86aE (<anonymous>:wasm-function[1728]:0x13a194)
    at _ZN4test8run_test17h5daeaa0299d1a7c2E (<anonymous>:wasm-function[1682]:0x12d701)
    at _ZN4test7console17run_tests_console17h42d68f80f0f18bf7E (<anonymous>:wasm-function[1676]:0x1295a2)
    at _ZN4test9test_main17h95710762cd3a72ccE (<anonymous>:wasm-function[1726]:0x139076)
    at _ZN4test16test_main_static17h0839790a395daff6E (<anonymous>:wasm-function[1727]:0x139efb)
    at _ZN9coretests4main17ha70dbf5e8e4935cdE (<anonymous>:wasm-function[1358]:0xfbaed)
    at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h12ef3977288498daE (<anonymous>:wasm-function[719]:0xd50e2)
    at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h98d8bcc2dfd3ba70E (<anonymous>:wasm-function[720]:0xd5116)
    at _ZN3std2rt19lang_start_internal17he10975b331fcd316E (<anonymous>:wasm-function[1978]:0x1501ca)
    at main (<anonymous>:wasm-function[1359]:0xfbb23)
error: test failed, to rerun pass '-p core --test coretests'


command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "wasm32-unknown-unknown" "-Zbinary-dep-depinfo" "-j" "16" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/checkout/library/test/Cargo.toml" "-p" "core" "--"


failed to run: /checkout/obj/build/bootstrap/debug/bootstrap --stage 2 test --host= --target wasm32-unknown-unknown src/test/run-make src/test/ui src/test/mir-opt src/test/codegen-units library/core
Build completed unsuccessfully in 0:21:17

</details>

Even the simplest config does not work for me:

(require 'exwm)
(require 'exwm-config)
(exwm-config-default)

Hi Aaron,

Great to hear from you. You're fast :slightly_smiling_face:

Attached is the project that generated the bug.

Most of it is hello_world-level stuff- and disconnected tinkering.

The workflow was to run a test, write some code, run a test.

By about the second or third test-change the defect was consistent to get.

Hope that helps, and let me know if you have any questions.

Cheers!

Rana Ian

tsr.zip

:hourglass: Testing commit 8b518542d042a0b046d44d5c2b754976481c80ce with merge 1c8899cd89868eb5cd168a631594fcfdf1dfbe47... <!-- homu: {"type":"BuildStarted","head_sha":"8b518542d042a0b046d44d5c2b754976481c80ce","merge_sha":"1c8899cd89868eb5cd168a631594fcfdf1dfbe47"} -->

The second copy could be made using ptr::copy_nonoverlapping instead of ptr::copy, since aliasing won't allow self and bytes to overlap. LLVM even seems to recognize this, replacing the second memmove with a memcopy, so this makes it so it's always applied.

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

Can you check your system clock? That might be the issue. Also did you use RUST_BACKTRACE=full to get the full backtrace?

Hm, IIUC map_while does an operation like "do take_while while map returns Some" and this doesn't seem to be a case?

One question I have is whether we should gate this behind another build flag (prof) or just include it under debug. One of the reasons for using Tracy is that it is designed to be fast enough to profile release applications (since that's what you want to profile...).

For us that's a bit tricky with our caching setup. In the current implementation this does not cache object files across runs, which is anticipatory of when we have embedded source line information. But for now I think we could do something like:

• include tracy under debug builds
• the current zone markings are always added and the object files are cached persistently
• once we have source line information, we can consider how to best handle that: perhaps a runtime -fprof option that adds the extra information, but doesn't store those results in the persistent cache?

This (equivalent to.. vs. equivalent erroneous code) sounds slightly redundant, maybe we could improve the above wording instead.

Used git blame blindly, didn't get deep enough. Sorry for disturbing.

Then I guess @jethrogb may clarify it

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

Makes "{:?}" switch to exponential for floats based on magnitude.

See the discussion thread for RFC rust-lang/rfcs#2729. (note: this is not an implementation of the RFC; it is an implementation of the alternative where the format of {:?} is changed. See this comment from the libs team)

Thresholds chosen were 1e-4 and 1e16. Justification described here.

As mentioned in the commit message of 8731d4dfb47, this behavior will not apply when a precision is supplied, because I wanted to preserve the following existing and useful behavior of {:.PREC?} (which recursively applies {:.PREC} to floats in a struct):

assert_eq!(
    format!("{:.2?}", [100.0, 1234567.8901]),
    "[100.00, 1234567.89]",
)

I looked around and am not sure where there are any tests that actually use this in the test suite, though?

All things considered, I'm surprised that this change did not seem to break even a single existing test in x.py test --stage 2. (even when I tried a smaller threshold of 1e6)

why not use join and join_with for iterators too? I feel like join implies the creation of something monolithic from a sequence and a separator, i.e

let items = vec!["foo", "bar", "blah"];
let result = items.join(" ");

will create the string foo bar blah.

But in my mind intersperse better communicates the idea of placing separators in between a sequence, without creating something monolithic using the results of that.

I suppose I mean that if I intersperse an iterator of &strs with " ", it makes sense to me that I get an iterator back. But if I have an iterator of &strs, and the method is named join, I feel like it's a little less clear. Without looking further into it, it might seem like that I'd get a concatenated String back, or similar. For other types it may be less unclear but I'm still unsure on whether calling the method join is a good fit.

Screenshot:

The unstable is linked to the tracking issue. Should I change the color?