profile
viewpoint

bjorn3/inline_asm_catalogue 7

Catalogue of asm! snippets to help the discussion about stabilization of inline asm

bjorn3/fractals 2

Just some experiments

bjorn3/goodgame_empire_import 2

A importer for goodgame empire

bjorn3/goodgame_empire_helpers 1

Helpers for goodgame empire

bjorn3/addr2line 0

A cross-platform `addr2line` clone written in Rust, using `gimli`

bjorn3/backtrace-rs 0

Backtraces in Rust

bjorn3/blog_os 0

Writing an OS in Rust

bjorn3/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

bjorn3/cretonne 0

Cretonne code generator

bjorn3/crev-proofs 0

My cref proofs

issue commentrust-lang/rustc-guide

Introduce something more about Codegen and LLVM

I wrote some advice from my experience writing a codegen backend at https://github.com/bjorn3/rustc_codegen_cranelift/issues/647. Maybe include some of it in the guide?

crlf0710

comment created time in 8 hours

issue commentgimli-rs/gimli

Getting started

Yes

akshat-khare

comment created time in 8 hours

issue commentgimli-rs/gimli

Getting started

Would cargo run <pathToFile> be the way to run it?

Yes

akshat-khare

comment created time in 8 hours

pull request commentbytecodealliance/cranelift

Tls support for ELF and MachO

Ok, thanks!

bjorn3

comment created time in 8 hours

issue commentsharkdp/hexyl

Hexyl don't respond to ctrl-c

libc::read will return EINTR when a signal handler was called. The read method for stdio and files in libstd loops until it doesn't return EINTR anymore. Try using the raw libc::read function.

secworks

comment created time in 9 hours

issue commentgimli-rs/gimli

Getting started

Does Cargo.toml contain edition = "2018"?

akshat-khare

comment created time in 9 hours

issue commentphil-opp/blog_os

disable-redzone flag in the target profile never gets passed to rustc

I don't think cargo cares about the content of the target json. Maybe open an issue?

vgarleanu

comment created time in 13 hours

pull request commentbytecodealliance/cranelift

Tls support for ELF and MachO

@abrown Has this been discussed?

bjorn3

comment created time in 14 hours

Pull request review commentrust-analyzer/rust-analyzer

Cut some deps

 crates/*/target *.log *.iml .vscode/settings.json+cargo-timing*.html

Missing trailing newline

matklad

comment created time in 14 hours

issue commentphil-opp/blog_os

Comments for "https://os.phil-opp.com/testing/"

Rustc suggests you to remove the ; after Mutex::new(serial_port). Doing this should fix the problem.

utterances-bot

comment created time in a day

issue commentphil-opp/blog_os

Weird UB and page faults when not running in release mode

Is it possible that a PIT interrupt fired before the last one was completely handled?

vgarleanu

comment created time in a day

push eventbjorn3/rustc_codegen_cranelift

dependabot-preview[bot]

commit sha 2714068b9709e3e1d13a55f6c442afaecbc08d90

Bump thiserror from 1.0.10 to 1.0.11 (#894) Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.10 to 1.0.11. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](https://github.com/dtolnay/thiserror/compare/1.0.10...1.0.11) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

push time in a day

PR merged bjorn3/rustc_codegen_cranelift

Bump thiserror from 1.0.10 to 1.0.11 dependencies

Bumps thiserror from 1.0.10 to 1.0.11. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/dtolnay/thiserror/commit/55d6fbb46032887f21e9c387671e01bca5392818"><code>55d6fbb</code></a> Release 1.0.11</li> <li><a href="https://github.com/dtolnay/thiserror/commit/0856edd777b3ca07df30f5d75d4b57c862e5d350"><code>0856edd</code></a> Link license files into impl subcrate</li> <li><a href="https://github.com/dtolnay/thiserror/commit/72528d09971a751df167c6b514a75ed3dd724540"><code>72528d0</code></a> Add missing code block language in readme</li> <li><a href="https://github.com/dtolnay/thiserror/commit/fefb9e5bbaac958a4ba8026b120ebc32ade41b2b"><code>fefb9e5</code></a> Make error(transparent) example doc test pass</li> <li>See full diff in <a href="https://github.com/dtolnay/thiserror/compare/1.0.10...1.0.11">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
  • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

  • Update frequency (including time of day and day of week)
  • Pull request limits (per update run and/or open at any time)
  • Automerge options (never/patch/minor, and dev/runtime dependencies)
  • Out-of-range updates (receive only lockfile updates, if desired)
  • Security updates (receive only security updates, if desired)

</details>

+7 -7

0 comment

1 changed file

dependabot-preview[bot]

pr closed time in a day

Pull request review commentphil-opp/blog_os

Add a language selector for browser-supported languages

 function toc_scroll_position(container) {     current_toc_item.classList.add("active");   } }++function show_lang_selector() {+  var show_lang_selector = false;+  for (language_selector of document.querySelectorAll('#language-selector li')) {+    var lang = language_selector.getAttribute("data-lang-switch-to");+    this.console.log(lang)+    if (this.navigator.languages.includes(lang)) {+      this.console.log("supported!");

Should these logs be removed?

phil-opp

comment created time in 2 days

Pull request review commentrust-lang/rust

[WIP] Implement new asm! syntax from RFC 2850

+use super::InlineAsmArch;+use rustc_macros::HashStable_Generic;+use std::fmt;++def_reg_class! {+    Arm ArmInlineAsmRegClass {+        reg: [],+        reg_thumb: [],+        sreg: [],+        sreg_low16: [],+        dreg: [],+        dreg_low16: [],+        dreg_low8: [],+        qreg: ['e', 'f'],+        qreg_low8: ['e', 'f'],+        qreg_low4: ['e', 'f'],+    }+}++impl ArmInlineAsmRegClass {+    pub fn validate_features(+        self,+        _arch: InlineAsmArch,+        mut has_feature: impl FnMut(&str) -> bool,+    ) -> Result<(), &'static str> {+        match self {+            Self::sreg+            | Self::sreg_low16+            | Self::dreg+            | Self::dreg_low16+            | Self::dreg_low8+            | Self::qreg+            | Self::qreg_low8+            | Self::qreg_low4+                if has_feature("soft-float") =>+            {+                Err("cannot be used with 'soft-float' target feature")+            }+            Self::dreg+            | Self::dreg_low16+            | Self::dreg_low8+            | Self::qreg+            | Self::qreg_low8+            | Self::qreg_low4+                if !has_feature("fp64") =>+            {+                Err("requires 'fp64' target feature")+            }+            Self::dreg | Self::qreg if !has_feature("d32") => Err("requires 'd32' target feature"),+            Self::qreg | Self::qreg_low8 | Self::qreg_low4 if has_feature("neon") => {

Missing !?

Amanieu

comment created time in 2 days

issue commentrust-analyzer/rust-analyzer

huge speed increase

That's even better! That would increase the quality of my code, because it will be tested on more projects.

Another idea would be to compile rust-analyzer itself using the tls branch of cg_clif. (I should actually try that)

jondot

comment created time in 2 days

issue commentrust-analyzer/rust-analyzer

huge speed increase

Should I add std::thread::sleep_ms(10_000) to the main loop to fix this? :)

jondot

comment created time in 2 days

issue commentfeenkcom/gtoolkit

fonts not displayed correctly on gtoolkit.com on windows Edge browser

Excerpt of the html causing one of the warnings:

<a class="footer-link" href="https://github.com/feenkcom/gtoolkit" title="Glamorous Toolkit on GitHub" target="_blank"><i class="fab fa-github fa-fw fa-2x"></i></a class="footer-link">

</a class="footer-link"> is not allowed. (not attrs for end tags)

georgeganea

comment created time in 2 days

Pull request review commentrust-lang/project-ffi-unwind

Blog post announcement of design meeting - draft

+# Announcing the first FFI-unwind project design meeting++-- Kyle Strand and Niko Matsakis on behalf of the FFI-unwind project group --++The FFI-unwind project group, announced in [this RFC][rfc-announcement], is+working to extend the language to support unwinding that crosses FFI+boundaries.++We have reached our first technical decision point, on a question we have been+discussing internally for quite a while. This blog post lays out the arguments+on each side of the issue and invites the Rust community to join us at the+[upcoming meeting](meeting-link) to help finalize our decision, which will be+formalized and published as our first language-change RFC. This RFC will+propose an "MVP" specification for well-defined cross-language unwinding.++The meeting will be on Monday the 24th at 17:00 UTC, via Zoom:++> Meeting ID: 768 231 760+> https://mozilla.zoom.us/j/768231760++## Background: what is unwinding?++Exceptions are a familiar control flow mechanism in many programming languages.+They are particularly commonplace in managed languages such as Java, but they+are also part of the C++ language, which introduced them to the world of+unmanaged systems programming.++When an exception is thrown, the runtime _unwinds_ the stack, essentially+traversing it backwards and calling clean-up or error-recovery code such as+destructors or `catch` blocks.++Compilers may implement their own unwinding mechanisms, but in native code such+as Rust binaries, the mechanism is more commonly provided by the platform ABI.++It is well known that Rust does not have exceptions as such. But Rust _does_+support unwinding! There are two scenarios that will cause unwinding to occur:++* By default, Rust's `panic!()` unwinds the stack.+* Using FFI, Rust can call functions in other languages (such as C++) that can+  unwind the stack.+  * There are some special cases where C libraries can actually cause+    unwinding.  For instance, on Microsoft platforms, `longjmp` is implemented+    as "forced unwinding" (see below)++Currently, when foreign (non-Rust) code invokes Rust code, the behavior of a+`panic!()` unwind that "escapes" from Rust is explicitly undefined. Similarly,+when Rust calls a foreign function that unwinds, the behavior once the unwind+operation encounters Rust frames is undefined. The primary reason for this is+to ensure that Rust implementations may use their own unwinding mechanism,+which may not be compatible with the platform-provided "native" unwinding+mechanism. Currently, however, `rustc` uses the native mechanism, and there are+no plans to change this.++### Forced unwinding++Platform ABIs can define a special kind of unwinding called "forced unwinding."+This type of unwinding is never supposed to be intercepted by the language+runtime; so, for instance, C++ destructors should not be invoked.

In that case I would prefer forced unwind to be UB, or aborting, so that other unwind mechanisms for Rust code are possible. One I once saw which may have an advantage is compiling the DWARF unwind tables to native code performing the unwinding without interpretation.

BatmanAoD

comment created time in 2 days

issue commentrust-analyzer/rust-analyzer

No errors reported when custom build command failed

The error seems to end up on stderr.

bjorn3

comment created time in 2 days

issue commentrust-analyzer/rust-analyzer

No errors reported when custom build command failed

$ cargo check --message-format=json
{"reason":"compiler-artifact","package_id":"cc 1.0.50 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"cc","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/cc-1.0.50/src/lib.rs","edition":"2018","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/libcc-00c5030842a6bd67.rlib","/home/bjorn/Documenten/backtrace-rs/target/debug/deps/libcc-00c5030842a6bd67.rmeta"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"libc 0.2.66 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["custom-build"],"crate_types":["bin"],"name":"build-script-build","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.66/build.rs","edition":"2015","doctest":false},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/build/libc-58f311a9c2a2a7c7/build-script-build"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"cfg-if 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"cfg-if","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/cfg-if-0.1.10/src/lib.rs","edition":"2018","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/libcfg_if-514b72ccd8f7fad1.rmeta"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"rustc-demangle 0.1.16 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"rustc-demangle","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.16/src/lib.rs","edition":"2015","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/librustc_demangle-1bc382716446cdbd.rmeta"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"backtrace-sys 0.1.32 (path+file:///home/bjorn/Documenten/backtrace-rs/crates/backtrace-sys)","target":{"kind":["custom-build"],"crate_types":["bin"],"name":"build-script-build","src_path":"/home/bjorn/Documenten/backtrace-rs/crates/backtrace-sys/build.rs","edition":"2015","doctest":false},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-c60479aaa6c68a55/build-script-build"],"executable":null,"fresh":true}
{"reason":"build-script-executed","package_id":"libc 0.2.66 (registry+https://github.com/rust-lang/crates.io-index)","linked_libs":[],"linked_paths":[],"cfgs":["freebsd11","libc_priv_mod_use","libc_union","libc_const_size_of","libc_align","libc_core_cvoid","libc_packedN"],"env":[]}
   Compiling backtrace-sys v0.1.32 (/home/bjorn/Documenten/backtrace-rs/crates/backtrace-sys)
{"reason":"compiler-artifact","package_id":"libc 0.2.66 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"libc","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.66/src/lib.rs","edition":"2015","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/liblibc-a74ecc186e44779d.rmeta"],"executable":null,"fresh":true}
error: failed to run custom build command for `backtrace-sys v0.1.32 (/home/bjorn/Documenten/backtrace-rs/crates/backtrace-sys)`

Caused by:
  process didn't exit successfully: `/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-c60479aaa6c68a55/build-script-build` (exit code: 1)
--- stdout
cargo:rustc-cfg=rbt
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("0")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-gnu = None
CC_x86_64_unknown_linux_gnu = None
HOST_CC = None
CC = None
CFLAGS_x86_64-unknown-linux-gnu = None
CFLAGS_x86_64_unknown_linux_gnu = None
HOST_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "src/libbacktrace" "-I" "/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-f1dc3b99f500d44a/out" "-fvisibility=hidden" "-DBACKTRACE_ELF_SIZE=64" "-DBACKTRACE_SUPPORTED=1" "-DBACKTRACE_USES_MALLOC=1" "-DBACKTRACE_SUPPORTS_THREADS=0" "-DBACKTRACE_SUPPORTS_DATA=0" "-DHAVE_DL_ITERATE_PHDR=1" "-D_GNU_SOURCE=1" "-D_LARGE_FILES=1" "-Dbacktrace_full=__rbt_backtrace_full" "-Dbacktrace_dwarf_add=__rbt_backtrace_dwarf_add" "-Dbacktrace_initialize=__rbt_backtrace_initialize" "-Dbacktrace_pcinfo=__rbt_backtrace_pcinfo" "-Dbacktrace_syminfo=__rbt_backtrace_syminfo" "-Dbacktrace_get_view=__rbt_backtrace_get_view" "-Dbacktrace_release_view=__rbt_backtrace_release_view" "-Dbacktrace_alloc=__rbt_backtrace_alloc" "-Dbacktrace_free=__rbt_backtrace_free" "-Dbacktrace_vector_finish=__rbt_backtrace_vector_finish" "-Dbacktrace_vector_grow=__rbt_backtrace_vector_grow" "-Dbacktrace_vector_release=__rbt_backtrace_vector_release" "-Dbacktrace_close=__rbt_backtrace_close" "-Dbacktrace_open=__rbt_backtrace_open" "-Dbacktrace_print=__rbt_backtrace_print" "-Dbacktrace_simple=__rbt_backtrace_simple" "-Dbacktrace_qsort=__rbt_backtrace_qsort" "-Dbacktrace_create_state=__rbt_backtrace_create_state" "-Dbacktrace_uncompress_zdebug=__rbt_backtrace_uncompress_zdebug" "-Dmacho_get_view=__rbt_macho_get_view" "-Dmacho_symbol_type_relevant=__rbt_macho_symbol_type_relevant" "-Dmacho_get_commands=__rbt_macho_get_commands" "-Dmacho_try_dsym=__rbt_macho_try_dsym" "-Dmacho_try_dwarf=__rbt_macho_try_dwarf" "-Dmacho_get_addr_range=__rbt_macho_get_addr_range" "-Dmacho_get_uuid=__rbt_macho_get_uuid" "-Dmacho_add=__rbt_macho_add" "-Dmacho_add_symtab=__rbt_macho_add_symtab" "-Dmacho_file_to_host_u64=__rbt_macho_file_to_host_u64" "-Dmacho_file_to_host_u32=__rbt_macho_file_to_host_u32" "-Dmacho_file_to_host_u16=__rbt_macho_file_to_host_u16" "-o" "/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-f1dc3b99f500d44a/out/src/libbacktrace/alloc.o" "-c" "src/libbacktrace/alloc.c"
cargo:warning=cc: error: src/libbacktrace/alloc.c: Bestand of map bestaat niet
cargo:warning=cc: fatal error: no input files
cargo:warning=compilation terminated.
exit code: 1

--- stderr


error occurred: Command "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m64" "-I" "src/libbacktrace" "-I" "/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-f1dc3b99f500d44a/out" "-fvisibility=hidden" "-DBACKTRACE_ELF_SIZE=64" "-DBACKTRACE_SUPPORTED=1" "-DBACKTRACE_USES_MALLOC=1" "-DBACKTRACE_SUPPORTS_THREADS=0" "-DBACKTRACE_SUPPORTS_DATA=0" "-DHAVE_DL_ITERATE_PHDR=1" "-D_GNU_SOURCE=1" "-D_LARGE_FILES=1" "-Dbacktrace_full=__rbt_backtrace_full" "-Dbacktrace_dwarf_add=__rbt_backtrace_dwarf_add" "-Dbacktrace_initialize=__rbt_backtrace_initialize" "-Dbacktrace_pcinfo=__rbt_backtrace_pcinfo" "-Dbacktrace_syminfo=__rbt_backtrace_syminfo" "-Dbacktrace_get_view=__rbt_backtrace_get_view" "-Dbacktrace_release_view=__rbt_backtrace_release_view" "-Dbacktrace_alloc=__rbt_backtrace_alloc" "-Dbacktrace_free=__rbt_backtrace_free" "-Dbacktrace_vector_finish=__rbt_backtrace_vector_finish" "-Dbacktrace_vector_grow=__rbt_backtrace_vector_grow" "-Dbacktrace_vector_release=__rbt_backtrace_vector_release" "-Dbacktrace_close=__rbt_backtrace_close" "-Dbacktrace_open=__rbt_backtrace_open" "-Dbacktrace_print=__rbt_backtrace_print" "-Dbacktrace_simple=__rbt_backtrace_simple" "-Dbacktrace_qsort=__rbt_backtrace_qsort" "-Dbacktrace_create_state=__rbt_backtrace_create_state" "-Dbacktrace_uncompress_zdebug=__rbt_backtrace_uncompress_zdebug" "-Dmacho_get_view=__rbt_macho_get_view" "-Dmacho_symbol_type_relevant=__rbt_macho_symbol_type_relevant" "-Dmacho_get_commands=__rbt_macho_get_commands" "-Dmacho_try_dsym=__rbt_macho_try_dsym" "-Dmacho_try_dwarf=__rbt_macho_try_dwarf" "-Dmacho_get_addr_range=__rbt_macho_get_addr_range" "-Dmacho_get_uuid=__rbt_macho_get_uuid" "-Dmacho_add=__rbt_macho_add" "-Dmacho_add_symtab=__rbt_macho_add_symtab" "-Dmacho_file_to_host_u64=__rbt_macho_file_to_host_u64" "-Dmacho_file_to_host_u32=__rbt_macho_file_to_host_u32" "-Dmacho_file_to_host_u16=__rbt_macho_file_to_host_u16" "-o" "/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-f1dc3b99f500d44a/out/src/libbacktrace/alloc.o" "-c" "src/libbacktrace/alloc.c" with args "cc" did not execute successfully (status code exit code: 1).



$ cargo check --message-format 2>/dev/null
{"reason":"compiler-artifact","package_id":"libc 0.2.66 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["custom-build"],"crate_types":["bin"],"name":"build-script-build","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.66/build.rs","edition":"2015","doctest":false},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/build/libc-58f311a9c2a2a7c7/build-script-build"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"cc 1.0.50 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"cc","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/cc-1.0.50/src/lib.rs","edition":"2018","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/libcc-00c5030842a6bd67.rlib","/home/bjorn/Documenten/backtrace-rs/target/debug/deps/libcc-00c5030842a6bd67.rmeta"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"rustc-demangle 0.1.16 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"rustc-demangle","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.16/src/lib.rs","edition":"2015","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/librustc_demangle-1bc382716446cdbd.rmeta"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"cfg-if 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"cfg-if","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/cfg-if-0.1.10/src/lib.rs","edition":"2018","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/libcfg_if-514b72ccd8f7fad1.rmeta"],"executable":null,"fresh":true}
{"reason":"build-script-executed","package_id":"libc 0.2.66 (registry+https://github.com/rust-lang/crates.io-index)","linked_libs":[],"linked_paths":[],"cfgs":["freebsd11","libc_priv_mod_use","libc_union","libc_const_size_of","libc_align","libc_core_cvoid","libc_packedN"],"env":[]}
{"reason":"compiler-artifact","package_id":"backtrace-sys 0.1.32 (path+file:///home/bjorn/Documenten/backtrace-rs/crates/backtrace-sys)","target":{"kind":["custom-build"],"crate_types":["bin"],"name":"build-script-build","src_path":"/home/bjorn/Documenten/backtrace-rs/crates/backtrace-sys/build.rs","edition":"2015","doctest":false},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/build/backtrace-sys-c60479aaa6c68a55/build-script-build"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"libc 0.2.66 (registry+https://github.com/rust-lang/crates.io-index)","target":{"kind":["lib"],"crate_types":["lib"],"name":"libc","src_path":"/home/bjorn/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.66/src/lib.rs","edition":"2015","doctest":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/home/bjorn/Documenten/backtrace-rs/target/debug/deps/liblibc-a74ecc186e44779d.rmeta"],"executable":null,"fresh":true}
bjorn3

comment created time in 2 days

issue commentphil-opp/blog_os

Invalid register in context_switch will cause a bunch of UB with RBP never being pushed onto the stack

Why is that even allowed by LLVM without crash?

vgarleanu

comment created time in 2 days

Pull request review commentrust-lang/miri

update Readme

 Several `-Z` flags are relevant for Miri:  * `-Zmiri-seed=<hex>` is a custom `-Z` flag added by Miri.  It configures the   seed of the RNG that Miri uses to resolve non-determinism.  This RNG is used-  to pick base addresses for allocations, and when the interpreted program-  requests system entropy.  The default seed is 0.+  to pick base addresses for allocations.  When isolation is disabled, this is

*enabled?

RalfJung

comment created time in 3 days

Pull request review commentrust-lang/rust

Canonicalize path when displaying a `FileName::Real`

 note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/m note: rustc VERSION running on TARGET  note: compiler flags: FLAGS-

I assumed that was the case :) My editor did the same thing recently.

LeSeulArtichaut

comment created time in 3 days

Pull request review commentrust-lang/project-ffi-unwind

Blog post announcement of design meeting - draft

+# Announcing the first FFI-unwind project design meeting++-- Kyle Strand and Niko Matsakis on behalf of the FFI-unwind project group --++The FFI-unwind project group, announced in [this RFC][rfc-announcement], is+working to extend the language to support unwinding that crosses FFI+boundaries.++We have reached our first technical decision point, on a question we have been+discussing internally for quite a while. This blog post lays out the arguments+on each side of the issue and invites the Rust community to join us at the+[upcoming meeting](meeting-link) to help finalize our decision, which will be+formalized and published as our first language-change RFC. This RFC will+propose an "MVP" specification for well-defined cross-language unwinding.++The meeting will be on Monday the 24th at 17:00 UTC, via Zoom:++> Meeting ID: 768 231 760+> https://mozilla.zoom.us/j/768231760++## Background: what is unwinding?++Exceptions are a familiar control flow mechanism in many programming languages.+They are particularly commonplace in managed languages such as Java, but they+are also part of the C++ language, which introduced them to the world of+unmanaged systems programming.++When an exception is thrown, the runtime _unwinds_ the stack, essentially+traversing it backwards and calling clean-up or error-recovery code such as+destructors or `catch` blocks.++Compilers may implement their own unwinding mechanisms, but in native code such+as Rust binaries, the mechanism is more commonly provided by the platform ABI.++It is well known that Rust does not have exceptions as such. But Rust _does_+support unwinding! There are two scenarios that will cause unwinding to occur:++* By default, Rust's `panic!()` unwinds the stack.+* Using FFI, Rust can call functions in other languages (such as C++) that can+  unwind the stack.+  * There are some special cases where C libraries can actually cause+    unwinding.  For instance, on Microsoft platforms, `longjmp` is implemented+    as "forced unwinding" (see below)++Currently, when foreign (non-Rust) code invokes Rust code, the behavior of a+`panic!()` unwind that "escapes" from Rust is explicitly undefined. Similarly,+when Rust calls a foreign function that unwinds, the behavior once the unwind+operation encounters Rust frames is undefined. The primary reason for this is+to ensure that Rust implementations may use their own unwinding mechanism,+which may not be compatible with the platform-provided "native" unwinding+mechanism. Currently, however, `rustc` uses the native mechanism, and there are+no plans to change this.++### Forced unwinding++Platform ABIs can define a special kind of unwinding called "forced unwinding."+This type of unwinding is never supposed to be intercepted by the language+runtime; so, for instance, C++ destructors should not be invoked.

Is it still possible to catch forced unwind, to for example translate to a different unwinding mechanism at the boundary between Rust and C?

BatmanAoD

comment created time in 3 days

Pull request review commentrust-lang/rust

Canonicalize path when displaying a `FileName::Real`

 note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/m note: rustc VERSION running on TARGET  note: compiler flags: FLAGS-

These extra trailing newlines have disappeared. They are necessary though, as the actual output of rustc does contain them. Please add them back.

LeSeulArtichaut

comment created time in 3 days

Pull request review commentrust-analyzer/rust-analyzer

Extend analysis-stats a bit

 authors = ["rust-analyzer developers"] publish = false  [dependencies]+itertools = "0.8.0" pico-args = "0.3.0" env_logger = { version = "0.7.1", default-features = false }+rand = { version = "0.7.0", features = ["small_rng"] }

Using a PRNG would make it deterministic, which is exactly the opposite of what the --randomize option is supposed to do.

flodiebold

comment created time in 3 days

PR opened rust-lang/backtrace-rs

Get register values

cc #288

This currently only works on x86_64 in combination with libunwind.

@alexcrichton do you have any idea how to test this? I am currently just printing the register values in the test.

+215 -2

0 comment

8 changed files

pr created time in 3 days

create barnchbjorn3/backtrace-rs

branch : register_values

created branch time in 3 days

issue commentrust-analyzer/rust-analyzer

0 implementations for all items

Do you have an Cargo.toml file in the directory you started VIM from?

Koxiaet

comment created time in 3 days

issue openedrust-analyzer/rust-analyzer

No errors reported when custom build command failed

$ git clone https://github.com/rust-lang/backtrace-rs.git
$ cd backtrace-rs
backtrace-rs $ cargo check
   Compiling backtrace-sys v0.1.32 (/Users/bjorn/Documents/backtrace-rs/crates/backtrace-sys)
error: failed to run custom build command for `backtrace-sys v0.1.32 (/Users/bjorn/Documents/backtrace-rs/crates/backtrace-sys)`

Caused by:
  process didn't exit successfully: `/Users/bjorn/Documents/backtrace-rs/target/debug/build/backtrace-sys-1f016f2963ab0034/build-script-build` (exit code: 1)
--- stdout
[...]

When opening in VSCode, it doesn't show any error however.

(By the way the error was because I didn't run git submodule update --init)

created time in 3 days

issue commentrust-analyzer/rust-analyzer

Allow rustup path configuration

rust-analyzer never invokes rustup itself.

https://github.com/rust-analyzer/rust-analyzer/search?q=rustup&unscoped_q=rustup

yaymalaga

comment created time in 4 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha bcb469e147dcaf2f9eb53e6f3c33a128522b51ba

Remove outdated troubleshooting section The nightly version is pinned since recently

view details

bjorn3

commit sha 9cfb9470c5296215ac696065446f9d44492c5b37

Allow unsized types as function parameters

view details

bjorn3

commit sha 242f2e3c7588574eb5f399dc4cde8f75d7e3e294

Fix correctness of optimization

view details

bjorn3

commit sha 74c7a7b7c530beb70b08fe8fe7acfdc1d7226dc5

Replace unimplemented! with unreachable! when it will never be supported

view details

bjorn3

commit sha 8de317dd8f3006531ee68992f8ea78c7248188c2

Update compiler_builtins

view details

bjorn3

commit sha 92d435613050a13a898bd6b611443efe4c01cc5a

Add #[cfg(debug_assertions)] to write_clif_file This silences a warning in release mode

view details

bjorn3

commit sha d821f154c5c6f46f5e461a28a7fd1ea7a2351620

Disable the code_layout optimization When compiling libcore, it causes ebb params to be dropped for a certain function

view details

dependabot-preview[bot]

commit sha 09c97475fb123ed191e3dc14629f84cfed19d555

Bump cranelift-codegen from `93e3bc1` to `9a578c1` Bumps [cranelift-codegen](https://github.com/bytecodealliance/cranelift) from `93e3bc1` to `9a578c1`. - [Release notes](https://github.com/bytecodealliance/cranelift/releases) - [Commits](https://github.com/bytecodealliance/cranelift/compare/93e3bc19985d0be2d0bfb7bcf990139c4a95358d...9a578c10924ce485a7b7e22dd5577ebc96538bb0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com>

view details

dependabot-preview[bot]

commit sha 2ad2ea73437533e4ecfb4fdf19b03dc5776ae9a2

Merge pull request #883 from bjorn3/dependabot/cargo/cranelift-codegen-9a578c1

view details

bjorn3

commit sha 9cdea312cf8373900ecb8d2f59b5e7348eab6ed8

Rustup to rustc 1.42.0-nightly (3761dcd34 2020-01-28)

view details

bjorn3

commit sha 7ec6bb21b6000b26b226759fbcb92fecd0c767b4

Update Cranelift

view details

bjorn3

commit sha f12c0d8ac75497b44c70220232668980a4b8c149

Update thiserror

view details

bjorn3

commit sha 8150f737c046f0bcc8501ad26f192b8c376580cb

Rustup to rustc 1.42.0-nightly (cd1ef390e 2020-01-31)

view details

bjorn3

commit sha 52d183ead624d43c293d12708a9eb3574e8cd17f

Update smallvec to 1.2.0

view details

bjorn3

commit sha 33e73091f8d4299e7f281a7d5da5184bf055c895

Don't mark unwind ebbs as cold This fixes the code_layout optimization, as it would previously try to move non-existing ebbs. Fixes #877

view details

bjorn3

commit sha eb4fc45310c70513d73d893616cd6735465680ca

Use CachingSourceMapView::byte_pos_to_line_and_col instead of SourceMap::lookup_char_pos The former calculates byte offsets instead of char offsets. It is faster to calculate byte offsets than char offsets. Also most DWARF producers and consumers use byte offsets instead of char offsets.

view details

bjorn3

commit sha fbe36ad68a226f389bf64f67ea60449b8d41efbf

Revert "Use CachingSourceMapView::byte_pos_to_line_and_col instead of SourceMap::lookup_char_pos" This reverts commit eb4fc45310c70513d73d893616cd6735465680ca. It caused a panic while compiling simple-raytracer

view details

bjorn3

commit sha 01f6f40ac24c32d61d2746d0f031279cf86ddd2f

Rustup to rustc 1.43.0-nightly (442ae7f04 2020-02-06)

view details

bjorn3

commit sha 5204a9839888c025d22656f7e9465c3eff2f7acd

Remove the sudo key from .travis.yml It has been deprecated and doesn't have any effect anymore

view details

bjorn3

commit sha bae0d9bb726b3524aee8ca4df1329b1233794a42

[OPT] Don't call monomorphize from clif_type

view details

push time in 4 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha 6156f48ffe43da77d98c1127acd393109619f471

Update Cranelift and use the new ineg instruction

view details

push time in 4 days

issue commentrust-analyzer/rust-analyzer

Can't Activate Features in Cargo Check

I believe the #[cfg] for the host system are used by rust-analyzer.

sanbox-irl

comment created time in 4 days

issue commentrust-analyzer/rust-analyzer

Can't Activate Features in Cargo Check

Did you intend to re-open?

sanbox-irl

comment created time in 4 days

delete branch bjorn3/cretonne

delete branch : group_small_memcpy_load_store

delete time in 4 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

then all the other details are regeneratable and don't need to be in the .rlink

No, link args can come from #[link] attributes on extern blocks. Because of proc-macros those can be generated non-deterministically.

alexcrichton

comment created time in 4 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

  1. the .rlink is a well-defined file with a documented schema

This will never happen. There are many implementation details written to .rlink. For example:

[...]
      "compiler_builtins" : 3,
[...]
      "missing_lang_items" : {
         "14" : [],
         "8" : [
            "EhPersonalityLangItem"
         ],
[...]
      },
      "panic_runtime" : 14,
      "profiler_runtime" : null,
[...]
   "metadata_module" : null,
   "allocator_module" : {
      "bytecode" : null,
      "name" : "33dyzt1ekirinwy8",
      "kind" : "Allocator",
      "object" : "rust_out.33dyzt1ekirinwy8.rcgu.o",
      "bytecode_compressed" : null
   },
[...]
   "modules" : [
      {
         "name" : "rust_out.7rcbfp3g-cgu.0",
         "bytecode" : null,
         "object" : "rust_out.rust_out.7rcbfp3g-cgu.0.rcgu.o",
         "bytecode_compressed" : null,
         "kind" : "Regular"
      },
[...]

compiler_builtins is an implementation detail and could technically be merged with libcore. Lang items are an implementation detail. panic_runtime and profiler_runtime are implementation details and could maybe in the future be replaced with normal deps. The exact things known about modules could change. For example bytecode_compressed may be removed once bytecode for LTO is no longer emitted alongside regular object files. metadata_module and allocator_module may in the future be folded into modules. ... (note: all things except for bytecode_compressed are purely hypothetical)

Step 1 is necessary because we need to be able to extract the path info, and rewrite it to remove/restructure absolute paths. The whole value in splitting linking is so we can run compilation of bin/dylib/procmacro crates and their linkage as separate build steps. "Splitting" them but then still requiring them to be run 1:1 on the same machine doesn't help all that much.

The splitting is mostly meant to be able to perform pipelined compilation on the final artifact, not to perform it codegen and linking on different machines. What is even the benefit of performing codegen and linking on different machines by the way? It doesn't increase parallelism, as the linking has to wait on codegen anyway.

Step 2 is necessary so we can avoid using static and cdylib crate types as they're painful to use in hybrid Rust/C++ programs where main() is not Rust (ie, we want to put the path to libstd on the final link line, not link it in multiple times for each C++ -> Rust dependency)..

That would require making the linker arguments stable, as changes could break such thing. Also why not create one rust library that depends on all rust dependencies and then depend on that rust library from C++?

alexcrichton

comment created time in 4 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

In a distributed build environment, the no-link and link-only steps are likely happening on different machines, with the intermediates being copied between them (or via some shared content store).

Many of the paths in the .rmeta file are absolute, so you will need to copy everything to the exact same location on the other machine. Also you don't know what files you have to copy. Even with -Zbinary-dep-depinfo the names of the intermediate files are not mentioned in neither the depinfo nor the artifact messages, and they are merely an implementation detail. In theory rustc could even put those intermediate files in /tmp. (For example if it detects that /tmp is a tmpfs, and the files fit in memory)

No, they're still useful for subsequent links if you're rebuilding the target executable because something else (eg non-Rust) changed.

You may just want to generate multiple versions of the same executable from the same inputs (eg built with different linker scripts, or static vs dynamic for system libraries).

When changing linker flags (this includes static vs dynamic for system libraries), you will need to call -Zno-link again to generate a new .rlink file with those linker flags.

alexcrichton

comment created time in 4 days

Pull request review commentbytecodealliance/cranelift

Merge emit_small_memcpy and emit_small_memmove

 impl<'a> FunctionBuilder<'a> {         self.ins().call(libc_memcpy, &[dest, src, size]);     } -    /// Optimised memcpy for small copies.-    pub fn emit_small_memcpy(+    /// Optimised memcpy or memmove for small copies.+    ///+    /// # Codegen safety+    ///+    /// The following properties must hold to prevent UB:+    ///+    /// * `src_align` and `dest_align` are an upper-bound on the alignment of `src` cq `dest`.

It seems that cq is a Dutch abbreviation: https://nl.m.wikipedia.org/wiki/Casu_quo. I also used it wrong. :man_facepalming: I meant: src_align is the upper-bound on the alignment of src and dest_align is the upper-bound on the alignment of dest. I replaced it with respectively.

bjorn3

comment created time in 4 days

push eventbjorn3/cretonne

bjorn3

commit sha ff059e7ede877e46bd81d37bd3caec24ab41a4e1

Fix typo

view details

push time in 4 days

Pull request review commentbytecodealliance/cranelift

wasm: Add support for passive data and element segments

 pub trait ModuleEnvironment<'data>: TargetEnvironment {         elements: Box<[FuncIndex]>,     ) -> WasmResult<()>; +    /// Declare a passive element segment.+    fn declare_passive_element(+        &mut self,+        index: PassiveElemIndex,+        elements: Box<[FuncIndex]>,+    ) -> WasmResult<()>;++    /// Provides the number of passive data segments up front.+    ///+    /// By default this does nothing, but implementations may use this to+    /// pre-allocate memory if desired.+    fn reserve_passive_data(&mut self, count: u32) -> WasmResult<()> {+        let _ = count;

Prefixing the argument with _ is the most common. (I haven't every seen it this way :) )

fitzgen

comment created time in 4 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

Sure, but they're not really internal tmp files in the no-link/link-only flow - they're outputs of one build step and inputs of the next, and build steps don't generally trash their inputs.

After the linking phase, when there is no shared cache, you will likely want to delete those intermediate files. Those intermediate files don't have predictable names, so cargo or other programs won't be able to remove them. Simply searching for .o files won't work, as other kinds of files are created and new kinds may be created in the future.

they're outputs of one build step and inputs of the next

It is very unlikely that you want to run either of the parts without the other. If any input file is changed, you need to run -Zno-link to handle the changes. If you run -Zno-link, you will also want to run -Zlink-only to perform the linking. If you didn't, you could just have used --emit metadata instead like cargo check does. The only reason -Zno-link and -Zlink-only are separated, is because you would otherwise need to notify rustc that all dependencies are fully built.

However, I was interested in the other info in that file, like the paths to other libraries which need to be linked in - though TBH I'm not sure that's the best way to receive that information.

Use -Zbinary-dep-depinfo to put all crate dependencies in the --emit dep-info file.

alexcrichton

comment created time in 4 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 impl ConstMethods<'tcx> for CodegenCx<'ll, 'tcx> {                 let base_addr = match alloc_kind {                     Some(GlobalAlloc::Memory(alloc)) => {                         let init = const_alloc_to_llvm(self, alloc);+                        let formatted_id = if self.sess().fewer_names() {

Insertions into const_globals are below in the same function, so they should always originate from a call of static_addr_of_mut.

chrissimpkins

comment created time in 4 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha a3f27a442838bf823b2071381cf6a26b566cfa3f

Use archive_format for determining if gnu style archives should be emitted Fixes #893

view details

push time in 4 days

issue closedbjorn3/rustc_codegen_cranelift

Use archive_kind from target options

https://github.com/bjorn3/rustc_codegen_cranelift/blob/e95a300630ce9f44b363ecc18e78a6f5df410b79/src/archive.rs#L44

https://github.com/servo/servo/issues/25550#issuecomment-584744199

closed time in 4 days

bjorn3

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 impl ConstMethods<'tcx> for CodegenCx<'ll, 'tcx> {                 let base_addr = match alloc_kind {                     Some(GlobalAlloc::Memory(alloc)) => {                         let init = const_alloc_to_llvm(self, alloc);+                        let formatted_id = if self.sess().fewer_names() {

It seems that static_addr_of{,_mut} already performs this check:

https://github.com/rust-lang/rust/blob/ebbb2bf37aedaaa64dfaa52ba337ca6efb6b9093/src/librustc_codegen_llvm/consts.rs#L176

chrissimpkins

comment created time in 4 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 #![crate_type = "rlib"] #![feature(thread_local)] -// CHECK: @STATIC_VAR_1 = thread_local local_unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4+// CHECK: @STATIC_VAR_1 = thread_local global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4 #[no_mangle] #[thread_local] static mut STATIC_VAR_1: [u32; 8] = [0; 8]; -// CHECK: @STATIC_VAR_2 = thread_local local_unnamed_addr global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4+// CHECK: @STATIC_VAR_2 = thread_local global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4

When a name is provided, static_addr_of_mut calls define_global instead of define_private_global:

https://github.com/rust-lang/rust/blob/ebbb2bf37aedaaa64dfaa52ba337ca6efb6b9093/src/librustc_codegen_llvm/consts.rs#L178

https://github.com/rust-lang/rust/blob/ebbb2bf37aedaaa64dfaa52ba337ca6efb6b9093/src/librustc_codegen_llvm/consts.rs#L184

chrissimpkins

comment created time in 4 days

Pull request review commentcfallin/cranelift

arm64: Fix incorrect assumption about modified registers

 fn arm64_get_regs(inst: &Inst) -> InstRegUses {         &Inst::Nop | Inst::Nop4 => {}     } -    debug_assert!(iru.modified.is_empty());+    // Enforce the invariant that if a register is in the 'modify' set, it+    // should not be in 'defined' or 'used'.+    iru.defined.remove(&iru.modified);+    iru.used.remove(&Set::from_vec(+        iru.modified.iter().map(|r| r.to_reg()).collect(),+    ));

Should this assert instead of modify?

jgouly

comment created time in 4 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha 430f738392dae75954bfa0059025dd18dadeff7d

Update Cranelift for basic blocks

view details

bjorn3

commit sha 6b2545402850eb57a7cbf54736042ad016ccfd0b

Update dependencies

view details

push time in 4 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 impl ConstMethods<'tcx> for CodegenCx<'ll, 'tcx> {                 let base_addr = match alloc_kind {                     Some(GlobalAlloc::Memory(alloc)) => {                         let init = const_alloc_to_llvm(self, alloc);+                        let formatted_id = if self.sess().fewer_names() {+                            None+                        } else {+                            Some(format!("{:?}", ptr.alloc_id))+                        };                         if alloc.mutability == Mutability::Mut {-                            self.static_addr_of_mut(init, alloc.align, None)+                            self.static_addr_of_mut(+                                init,+                                alloc.align,+                                formatted_id.as_ref().map(|x| &**x),

Try adding let formatted_id = formatted_id.as_ref().map(|x| &**x); before the if and then using formatted_id here to prevent duplication of this.

chrissimpkins

comment created time in 4 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha b5b2ffab6ae4026f8d9a8b552e075fdc81002ec7

Rustup to rustc 1.43.0-nightly (5d04ce67f 2020-02-13)

view details

push time in 4 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 impl ConstMethods<'tcx> for CodegenCx<'ll, 'tcx> {                     Some(GlobalAlloc::Memory(alloc)) => {                         let init = const_alloc_to_llvm(self, alloc);                         if alloc.mutability == Mutability::Mut {-                            self.static_addr_of_mut(init, alloc.align, None)+                            self.static_addr_of_mut(+                                init,+                                alloc.align,+                                Some(&ptr.alloc_id.to_string()),

You inverted the condition. It should be:

let formatted_id = if self.sess().fewer_names() {
    None
} else {
    Some(format!("alloc{}", ptr.alloc_id))
};

It should return None when fewer_names() is true, not when it is false.

chrissimpkins

comment created time in 4 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 impl ConstMethods<'tcx> for CodegenCx<'ll, 'tcx> {                     Some(GlobalAlloc::Memory(alloc)) => {                         let init = const_alloc_to_llvm(self, alloc);                         if alloc.mutability == Mutability::Mut {-                            self.static_addr_of_mut(init, alloc.align, None)+                            self.static_addr_of_mut(+                                init,+                                alloc.align,+                                Some(&ptr.alloc_id.to_string()),

I'm not seeing self.sess().opts.fewer_names but I think that we can test on self.sess().fewer_names()?

I too think self.sess().fewer_names() should be used.

chrissimpkins

comment created time in 4 days

push eventbjorn3/cretonne

Joshua Nelson

commit sha 280fd1e13b5cdad9d9d308b78bb94b0476f2d9f0

Use zeroinit API for faerie and object (#1209) * use new zeroinit API for faerie * use bss for cranelift-object * don't crash when initializing bss * fix formatting * Improve code locality Co-Authored-By: Philip Craig <philipjcraig@gmail.com> * use `as` instead of try_into() for usize -> u64 * don't allocate unnecessarily in `faerie` Co-authored-by: Philip Craig <philipjcraig@gmail.com>

view details

bjorn3

commit sha 38af2058980f78aad6f9aa91f6a605a8c5e51e00

Add TLS support

view details

bjorn3

commit sha 3f6dcf9edeed86c61b21cf2369b477f9d6f6e724

Add binemit and legalize tests

view details

push time in 5 days

pull request commentbytecodealliance/cranelift

Tls support for ELF and MachO

I rebased this and added tests for legalization of global_value and encoding of x86_{elf,macho}_tls_get_addr. Should I also add a test that cranelift-object correctly writes the tls section?

I mention that because the whole threading thing might require some back-and-forth discussion.

For cg_clif this is technically the only thing that prevents multithreading at the moment. I have made atomics atomic by using a global lock. While this is slow, at least it works. I would love to see atomic support in Cranelift, but for now TLS is more important for me.

bjorn3

comment created time in 5 days

push eventbjorn3/cretonne

bjorn3

commit sha fee342b63133755baa1fa1ec156a7f131dfb7013

Add binemit and legalize tests

view details

push time in 5 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 #![crate_type = "rlib"] #![feature(thread_local)] -// CHECK: @STATIC_VAR_1 = thread_local local_unnamed_addr global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4+// CHECK: @STATIC_VAR_1 = thread_local global <{ [32 x i8] }> zeroinitializer, section "__DATA,__thread_bss", align 4 #[no_mangle] #[thread_local] static mut STATIC_VAR_1: [u32; 8] = [0; 8]; -// CHECK: @STATIC_VAR_2 = thread_local local_unnamed_addr global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4+// CHECK: @STATIC_VAR_2 = thread_local global <{ [32 x i8] }> <{{[^>]*}}>, section "__DATA,__thread_data", align 4

STATIC_VAR_2 has a #[thread_local] attribute.

chrissimpkins

comment created time in 5 days

Pull request review commentrust-lang/rust

Add support for LLVM globals corresponding to miri allocations should be named alloc123

 impl ConstMethods<'tcx> for CodegenCx<'ll, 'tcx> {                     Some(GlobalAlloc::Memory(alloc)) => {                         let init = const_alloc_to_llvm(self, alloc);                         if alloc.mutability == Mutability::Mut {-                            self.static_addr_of_mut(init, alloc.align, None)+                            self.static_addr_of_mut(+                                init,+                                alloc.align,+                                Some(&ptr.alloc_id.to_string()),

I would prefer a global(_mut)_from_alloc over global(_mut)_from_value, as a lot of the constant handling can be shared.

chrissimpkins

comment created time in 5 days

issue commentrust-dev-tools/cargo-src

can't find crate rustc_parse

I meant cargo-src, not the component.

D1mon

comment created time in 5 days

issue commentrust-dev-tools/cargo-src

can't find crate rustc_parse

Looks like this needs to be updated for the latest nightly.

D1mon

comment created time in 5 days

issue commentrust-dev-tools/cargo-src

can't find crate rustc_parse

Have you installed the rustc-dev component? (rustup component add --toolchain nightly rustc-dev)

D1mon

comment created time in 5 days

issue openedbjorn3/rustc_codegen_cranelift

Use archive_kind from target options

https://github.com/bjorn3/rustc_codegen_cranelift/blob/e95a300630ce9f44b363ecc18e78a6f5df410b79/src/archive.rs#L44

https://github.com/servo/servo/issues/25550#issuecomment-584744199

created time in 5 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

-Zlink-only invokes the linker code like normal. Only when -Csave-temps is used, does the linker code not cleanup object files.

alexcrichton

comment created time in 5 days

Pull request review commentrust-analyzer/rust-analyzer

vscode: simplified config and to removed one source of truth of default values

 export interface CargoFeatures {     allFeatures: boolean;     features: string[]; }- export class Config {-    langServerSource!: null | BinarySource;+    private static readonly rootSection = "rust-analyzer";+    private static readonly requiresReloadOpts = [+        "cargoFeatures",+        "cargo-watch",+    ]+    .map(opt => `${Config.rootSection}.${opt}`);++    private cfg!: vscode.WorkspaceConfiguration;++    private refreshConfig() {+        this.cfg = vscode.workspace.getConfiguration(Config.rootSection);+        console.log("Using configuration:", this.cfg);+    } -    highlightingOn = true;-    rainbowHighlightingOn = false;-    enableEnhancedTyping = true;-    lruCapacity: null | number = null;-    displayInlayHints = true;-    maxInlayHintLength: null | number = null;-    excludeGlobs: string[] = [];-    useClientWatching = true;-    featureFlags: Record<string, boolean> = {};-    // for internal use-    withSysroot: null | boolean = null;-    cargoWatchOptions: CargoWatchOptions = {-        enable: true,-        arguments: [],-        command: '',-        allTargets: true,-    };-    cargoFeatures: CargoFeatures = {-        noDefaultFeatures: false,-        allFeatures: true,-        features: [],-    };+    constructor(private ctx: vscode.ExtensionContext) {+        vscode.workspace.onDidChangeConfiguration(this.onConfigChange, this, ctx.subscriptions);+        this.refreshConfig();+    }++    async onConfigChange(event: vscode.ConfigurationChangeEvent) {+        this.refreshConfig();++        const requiresReloadOpt = Config.requiresReloadOpts.find(+            opt => event.affectsConfiguration(opt)+        ); -    private prevEnhancedTyping: null | boolean = null;-    private prevCargoFeatures: null | CargoFeatures = null;-    private prevCargoWatchOptions: null | CargoWatchOptions = null;+        if (!requiresReloadOpt) return; -    constructor(ctx: vscode.ExtensionContext) {-        vscode.workspace.onDidChangeConfiguration(_ => this.refresh(ctx), null, ctx.subscriptions);-        this.refresh(ctx);+        const userResponse = await vscode.window.showInformationMessage(+            `Changing "${requiresReloadOpt}" requires a reload`,+            "Reload now"+        );++        if (userResponse === "Reload now") {+            vscode.commands.executeCommand("workbench.action.reloadWindow");+        }     } -    private static expandPathResolving(path: string) {-        if (path.startsWith('~/')) {-            return path.replace('~', os.homedir());+    private static replaceTildeWithHomeDir(path: string) {+        if (path.startsWith("~/")) {+            return os.homedir() + path.slice("~".length);

Does .replace(/~/g, "|") replace all occurences?

Veetaha

comment created time in 5 days

pull request commentbytecodealliance/cranelift

Tls support for ELF and MachO

I'm not familiar enough with other ways of implementing TLS to have much comment.

While there are other ways to implement TLS support, this matches the native TLS handling of ELF cq Mach-O. This way, it is possible to import/export tls variables from/to native objects. While this is not really necessary for cg_clif, as Rust makes a getter for the TLS var anyway and doesn't export the raw TLS var, for rcc it will likely be needed to interoperate with native code.

bjorn3

comment created time in 5 days

push eventbjorn3/cretonne

Andrew Brown

commit sha c73c3e8441efcb6324f18a22679e43e4bbd174cc

Remove unused import; fixes #1367 (#1368)

view details

Yury Delendik

commit sha 765d3d8416ae0e306499fc85ac303bf73ebf335c

Properly preserve and restore CFA state in FDE (#1373) * Properly preserve and restore CFA state in FDE

view details

Nick Fitzgerald

commit sha 666609065cd58fc0ad0af291418e0057f70fde1e

Bump to 0.57.0 (#1375) * Update wasmparser to 0.48.2 * Bump to version 0.57.0

view details

Nathan Froyd

commit sha bc99ff3c59c48832ff98789c954fb48f55850a08

add documentation mentions of cranelift-object where appropriate This change makes it slightly more obvious that `cranelift-object` can be used in lieu of `cranelift-faerie`.

view details

Ryan Hunt

commit sha c0f82dbdeca0d18c5a829463c616cc768657de3a

Mass rename Ebb and relatives to Block (#1365) * Manually rename BasicBlock to BlockPredecessor BasicBlock is a pair of (Ebb, Inst) that is used to represent the basic block subcomponent of an Ebb that is a predecessor to an Ebb. Eventually we will be able to remove this struct, but for now it makes sense to give it a non-conflicting name so that we can start to transition Ebb to represent a basic block. I have not updated any comments that refer to BasicBlock, as eventually we will remove BlockPredecessor and replace with Block, which is a basic block, so the comments will become correct. * Manually rename SSABuilder block types to avoid conflict SSABuilder has its own Block and BlockData types. These along with associated identifier will cause conflicts in a later commit, so they are renamed to be more verbose here. * Automatically rename 'Ebb' to 'Block' in *.rs * Automatically rename 'EBB' to 'block' in *.rs * Automatically rename 'ebb' to 'block' in *.rs * Automatically rename 'extended basic block' to 'basic block' in *.rs * Automatically rename 'an basic block' to 'a basic block' in *.rs * Manually update comment for `Block` `Block`'s wikipedia article required an update. * Automatically rename 'an `Block`' to 'a `Block`' in *.rs * Automatically rename 'extended_basic_block' to 'basic_block' in *.rs * Automatically rename 'ebb' to 'block' in *.clif * Manually rename clif constant that contains 'ebb' as substring to avoid conflict * Automatically rename filecheck uses of 'EBB' to 'BB' 'regex: EBB' -> 'regex: BB' '$EBB' -> '$BB' * Automatically rename 'EBB' 'Ebb' to 'block' in *.clif * Automatically rename 'an block' to 'a block' in *.clif * Fix broken testcase when function name length increases Test function names are limited to 16 characters. This causes the new longer name to be truncated and fail a filecheck test. An outdated comment was also fixed.

view details

Nick Fitzgerald

commit sha fd1784e0f000b80ea692d984bff8d061925b70e1

Enable `ref.func` global initializers (#1380) * Fix comment referencing an outdated instruction name * cranelift-wasm: Enable `ref.func` global initializers

view details

Gabor Greif

commit sha 071c11aab5a43f9ab5c3cbe8a9a8c57a000d48d8

Catch a few typos (#1381)

view details

Dan Gohman

commit sha dca43765212e0afb0a9ac8901111b236beb4208d

Bump version to 0.58.0 (#1382)

view details

Philip Craig

commit sha f549469064ea5546d68d3f181b0b55a3dd786a8b

cranelift-object: move relocation processing to `finish` This removes the need to call `finalize_definitions` for cranelift-object. `finalize_definitions` is only intended for backends that produce finalized functions and data objects, which cranelift-object does not.

view details

Philip Craig

commit sha 98c818c129979e98a3db150f8f9698f6451b7ef7

cranelift-module: document that finalize methods may not be relevant

view details

Y-Nak

commit sha 60ab06981ff9ab234d1a5fa4ffe30baeb9879319

Fix inverted result of is_leaf method

view details

bjorn3

commit sha a4ade05dc68e1e9d4d87261632576575fb039d58

Add TLS support

view details

push time in 5 days

Pull request review commentbytecodealliance/cranelift

Encode stack load store

 fn define_entity_ref(         is_pic,     ); -    // Stack addresses.-    //-    // TODO: Add encoding rules for stack_load and stack_store, so that they-    // don't get legalized to stack_addr + load/store.-    e.enc32(stack_addr.bind(I32), rec_spaddr4_id.opcodes(&LEA));-    e.enc64(stack_addr.bind(I64), rec_spaddr8_id.opcodes(&LEA).rex().w());+    // Stack accesses.+    e.enc32(stack_addr.bind(I32), rec_spaddr_ld_id.opcodes(&LEA));

Yeah, that put4 was the reason I removed it.

bjorn3

comment created time in 5 days

issue openedrust-lang/backtrace-rs

Get register values for frame

I got a PR for https://github.com/bjorn3/pretty_backtrace which shows the values of locals for every frame.This currently requires unwind-rs to get the register values. Unfortunately it only supports ELF based unixes. Adding support to backtrace-rs would make it possible to do it on macOS too.

When using libunwind, this can use _Unwind_GetGR. On Windows, you can get register values from CONTEXT.

created time in 6 days

pull request commentbytecodealliance/cranelift

Encode stack load store

I am curious about what would cause the slowdown. What kind of operations does that 1.8% slowdown benchmark perform. Does it use the same stack slot a lot? Or is is the generated code a bit bigger after this PR?

bjorn3

comment created time in 6 days

Pull request review commentbytecodealliance/cranelift

Encode stack load store

 fn define_entity_ref(         is_pic,     ); -    // Stack addresses.-    //-    // TODO: Add encoding rules for stack_load and stack_store, so that they-    // don't get legalized to stack_addr + load/store.-    e.enc32(stack_addr.bind(I32), rec_spaddr4_id.opcodes(&LEA));-    e.enc64(stack_addr.bind(I64), rec_spaddr8_id.opcodes(&LEA).rex().w());+    // Stack accesses.+    e.enc32(stack_addr.bind(I32), rec_spaddr_ld_id.opcodes(&LEA));

I can add the 8bit displacement back.

bjorn3

comment created time in 6 days

Pull request review commentbytecodealliance/cranelift

Encode stack load store

 pub(crate) fn define<'shared>(             ),     ); -    // Stack addresses.+    // Stack accesses.     //     // TODO Alternative forms for 8-bit immediates, when applicable. -    recipes.add_template_recipe(-        EncodingRecipeBuilder::new("spaddr4_id", &formats.stack_load, 6)+    recipes.add_template(Template::new(+        EncodingRecipeBuilder::new("spaddr_ld_id", &formats.stack_load, 6)             .operands_out(vec![gpr])             .emit(                 r#"-                    let sp = StackRef::sp(stack_slot, &func.stack_slots);-                    let base = stk_base(sp.base);-                    {{PUT_OP}}(bits, rex2(out_reg0, base), sink);-                    modrm_sib_disp8(out_reg0, sink);-                    sib_noindex(base, sink);-                    let imm : i32 = offset.into();-                    sink.put4(sp.offset.checked_add(imm).unwrap() as u32);-                "#,+                        let sp = StackRef::sp(stack_slot, &func.stack_slots);+                        let base = stk_base(sp.base);+                        {{PUT_OP}}(bits, rex2(base, out_reg0), sink);+                        modrm_sib_disp32(out_reg0, sink);+                        sib_noindex(base, sink);+                        let imm : i32 = offset.into();+                        sink.put4(sp.offset.checked_add(imm).unwrap() as u32);+                    "#,             ),-    );+        regs,+    )); -    recipes.add_template_recipe(-        EncodingRecipeBuilder::new("spaddr8_id", &formats.stack_load, 6)-            .operands_out(vec![gpr])+    recipes.add_template(Template::new(+        EncodingRecipeBuilder::new("spst_id", &formats.stack_store, 6)+            .operands_in(vec![gpr])             .emit(                 r#"-                    let sp = StackRef::sp(stack_slot, &func.stack_slots);-                    let base = stk_base(sp.base);-                    {{PUT_OP}}(bits, rex2(base, out_reg0), sink);-                    modrm_sib_disp32(out_reg0, sink);-                    sib_noindex(base, sink);-                    let imm : i32 = offset.into();-                    sink.put4(sp.offset.checked_add(imm).unwrap() as u32);-                "#,+                        sink.trap(TrapCode::StackOverflow, func.srclocs[inst]);

I followed the example of the spill and fill encodings. Stack loads should always have a stack store before them to prevent reading undefined bytes, so any stack overflow would have already been catched by the stack store. Unlike the fill instruction, a stack load of undefined bytes is possible, so maybe I should add a StackOverflow trap marker to load anyway.

bjorn3

comment created time in 6 days

Pull request review commentgluon-lang/lsp-types

Implement proposed semantic token protocol

 pub struct SemanticHighlightingParams {     pub lines: Vec<SemanticHighlightingInformation>, } +/**+ * A set of predefined token types. This set is not fixed+ * an clients can specify additional token types via the+ * corresponding client capabilities.+ *+ * @since 3.16.0 - Proposed state+ */+#[derive(Debug, Eq, PartialEq, Clone, Copy, Deserialize, Serialize)]+#[cfg(feature = "proposed")]+pub enum SemanticTokenTypes {+    #[serde(rename = "comment")]+    Comment,+    #[serde(rename = "keyword")]+    Keyword,+    #[serde(rename = "string")]+    String,+    #[serde(rename = "number")]+    Number,+    #[serde(rename = "regexp")]+    Regexp,+    #[serde(rename = "operator")]+    Operator,+    #[serde(rename = "namespace")]+    Namespace,+    #[serde(rename = "type")]+    Type,+    #[serde(rename = "struct")]+    Struct,+    #[serde(rename = "class")]+    Class,+    #[serde(rename = "interface")]+    Interface,+    #[serde(rename = "enum")]+    Enum,+    #[serde(rename = "typeParameter")]+    TypeParameter,+    #[serde(rename = "function")]+    Function,+    #[serde(rename = "member")]+    Member,+    #[serde(rename = "property")]+    Property,+    #[serde(rename = "macro")]+    Macro,+    #[serde(rename = "variable")]+    Variable,+    #[serde(rename = "parameter")]+    Parameter,+    #[serde(rename = "label")]+    Label,+}++/**+ * A set of predefined token modifiers. This set is not fixed+ * an clients can specify additional token types via the

*and

kjeremy

comment created time in 6 days

Pull request review commentgluon-lang/lsp-types

Implement proposed semantic token protocol

 pub struct SemanticHighlightingParams {     pub lines: Vec<SemanticHighlightingInformation>, } +/**+ * A set of predefined token types. This set is not fixed+ * an clients can specify additional token types via the

*and

kjeremy

comment created time in 6 days

pull request commentbytecodealliance/cranelift

Tls support for ELF and MachO

Ping?

bjorn3

comment created time in 6 days

Pull request review commentgluon-lang/lsp-types

Implement proposed semantic token protocol

 pub struct TextDocumentClientCapabilities {     #[serde(skip_serializing_if = "Option::is_none")]     #[cfg(feature = "proposed")]     pub semantic_highlighting_capabilities: Option<SemanticHighlightingClientCapability>,++    /*
    /**
kjeremy

comment created time in 6 days

Pull request review commentbytecodealliance/cranelift

Add ineg legalization for scalar integer types

 block0(v0: f32, v1: f32):     ; check: $done(v2: f32):     ; nextln: return v2 }++function %ineg_legalized_i8() {+block0:+    v0 = iconst.i8 1+    v1 = ineg v0+    ; check: v2 = iconst.i32 1+    ; nextln: v0 = ireduce.i8 v2+    ; nextln: v3 = iconst.i8 0+    ; nextln: v4 = uextend.i32 v3+    ; nextln: v5 = uextend.i32 v0+    ; nextln: v6 = isub v4, v5+    ; nextln: v1 = ireduce.i8 v6++    return+}++function %ineg_legalized_i16() {+block0:+    v0 = iconst.i16 1+    v1 = ineg v0+    ; check: v2 = iconst.i32 1+    ; nextln: v0 = ireduce.i16 v2+    ; nextln: v3 = iconst.i16 0+    ; nextln: v4 = uextend.i32 v3+    ; nextln: v5 = uextend.i32 v0+    ; nextln: v6 = isub v4, v5+    ; nextln: v1 = ireduce.i16 v6++    return+}++function %ineg_legalized_i32() {+block0:+    v0 = iconst.i32 1+    v1 = ineg v0+    ; check: v0 = iconst.i32 1+    ; nextln: v2 = iconst.i32 0+    ; nextln: v1 = isub v2, v0++    return+}++function %ineg_legalized_i64() {+block0:+    v0 = iconst.i64 1+    v1 = ineg v0+    ; check: v2 = iconst.i32 1+    ; check: v3 = iconst.i32 0+    ; check: v0 = iconcat v2, v3

There is also the narrow group for ints > pointer size.

peterdelevoryas

comment created time in 6 days

Pull request review commentrust-analyzer/rust-analyzer

Support trait auto import

 impl SourceAnalyzer {         self.resolve_hir_path(db, &hir_path)     } +    fn resolve_as_full_path(&self, path_expr: ast::PathExpr) -> Option<PathResolution> {+        let expr_id = self.expr_id(&path_expr.into())?;+        self.infer+            .as_ref()?+            .assoc_resolutions_for_expr(expr_id)+            .map(|assoc| PathResolution::AssocItem(assoc.into()))+    }++    fn resolve_as_path_to_method(+        &self,+        db: &impl HirDatabase,+        path_expr: &ast::PathExpr,+    ) -> Option<PathResolution> {+        let full_path = path_expr.path()?;+        let path_to_method = full_path.qualifier()?;+        let method_name = full_path.segment()?.syntax().to_string();+        match self.resolve_path(db, &path_to_method)? {+            PathResolution::Def(ModuleDef::Adt(adt)) => {+                let ty = adt.ty(db);+                iterate_method_candidates(

Isn't and_then a monad?

SomeoneToIgnore

comment created time in 6 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha 461157b3cadc3ab5d668fefff6bb9aea4103afaf

Implement return from shim

view details

push time in 6 days

issue commentrust-lang/miri

Compilation to WASM?

I haven't done anything more on this since my last comment. You can rebase my branch if you want to experiment with this. I doubt that I will be accepted upstream with the patches it needed. I needed to disable stuff like threads. Upstreaming the patches for platform specific stuff is more likely to succeed.

RReverser

comment created time in 6 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha c596e9a1e412ae895d4e857c8ac742c59c5cbd50

[WIP]

view details

push time in 6 days

Pull request review commentrust-analyzer/rust-analyzer

prevent "Play" symbol in "Run Test" code lens from rendering as emoji

 pub fn handle_code_lens(     // Gather runnables     for runnable in world.analysis().runnables(file_id)? {         let title = match &runnable.kind {-            RunnableKind::Test { .. } | RunnableKind::TestMod { .. } => "▶️Run Test",+            RunnableKind::Test { .. } | RunnableKind::TestMod { .. } => "▶️&#xFE0E;Run Test",

I don't think this will work correctly in non html based editors. Could you please use \u{fe0e}. (or at least I think that is the correct rust unicode codepoint syntax)

quanlou

comment created time in 6 days

push eventbjorn3/rustc_codegen_cranelift

bjorn3

commit sha f78e6bfd2b798751f48b5c9cec4375fc937a143c

[WIP]

view details

push time in 6 days

Pull request review commentrust-lang/rust

rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.

 const DW_TAG_arg_variable: c_uint = 0x101;  /// A context object for maintaining all state needed by the debuginfo module. pub struct CrateDebugContext<'a, 'tcx> {+    // FIXME(eddyb) we need this?! at all?!

DebugBuilder would be llvm::DIBuilder. CrateDebugContext is in my opinion everything non function local that is needed to create debuginfo. You ask it for the debuginfo of a Ty<'tcx>, and it will ask the DIBuilder to create the corresponding debuginfo. Think about it in terms of the split between cg_ssa::FunctionCx and cg_llvm::Builder. The former is like CrateDebugContext, while the later is like DIBuilder. DIBuilder is for low-level creation of debuginfo by specifying the name, size, fields (type+offset), .... CrateDebugContext is for high-level creation of debuginfo by specifying Ty<'tcx>.

eddyb

comment created time in 7 days

pull request commentrust-lang/rust

Separate `dealloc` from `AllocRef` into `DeallocRef`

The current name sounds like it only supports deallocation, not allocation.

TimDiekmann

comment created time in 7 days

Pull request review commentrust-lang/rust

rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.

 const DW_TAG_arg_variable: c_uint = 0x101;  /// A context object for maintaining all state needed by the debuginfo module. pub struct CrateDebugContext<'a, 'tcx> {+    // FIXME(eddyb) we need this?! at all?!

Most of the things required for debuginfo live in TyCtxt, at least what is needed for the typeinfo. In my PR I added a tcx field.

eddyb

comment created time in 7 days

issue commentrust-lang/rust

-Cdebuginfo=1 wastefully produces full type descriptions.

Right now we have no debuginfo at all AFAIK

Forgot that :)

since all you need is addresses, right?

And ASLR bias I think.

Or maybe we could take the backtrace they report, and the version, and generate the full backtrace ourselves using the right debuginfo

It would be nice if a bot could do it.

eddyb

comment created time in 7 days

pull request commentcfallin/cranelift

arm64: Change SImm7 to SImm7Scaled

I think this is nicer for debugging.

You could write a custom Debug impl showing the original value in addition to the scaled value and scale.

jgouly

comment created time in 7 days

issue commentrust-lang/rust

Add support for splitting linker invocation to a second execution of `rustc`

The rustc part of this has been merged. This is waiting on cargo support now.

alexcrichton

comment created time in 7 days

pull request commentrust-lang/rust

[experiment] Support linking from a .rlink file

Hooray! Next step: cargo support.

0dvictor

comment created time in 7 days

issue commentrust-lang/rust

-Cdebuginfo=1 wastefully produces full type descriptions.

Of course the ideal thing would be split DWARF and a rustc-debuginfo component in rustup but I am not sure how to get there.

That would reduce the quality of ICE backtraces reported by the average user.

eddyb

comment created time in 7 days

issue commentrust-lang/rust

-Cdebuginfo=1 wastefully produces full type descriptions.

In that issue you suggest we should not even be emitting DISubprogram, will that still let inlined calls show up on the backtrace?

Inlined calls are determined from DW_TAG_inlined_subroutine inside the respective DW_TAG_subroutine I believe.

eddyb

comment created time in 7 days

Pull request review commentrust-lang/rust

rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.

 const DW_TAG_arg_variable: c_uint = 0x101;  /// A context object for maintaining all state needed by the debuginfo module. pub struct CrateDebugContext<'a, 'tcx> {+    // FIXME(eddyb) we need this?! at all?!     llcontext: &'a llvm::Context,     llmod: &'a llvm::Module,+     builder: &'a mut DIBuilder<'a>,+     created_files: RefCell<FxHashMap<(Option<String>, Option<String>), &'a DIFile>>,-    created_enum_disr_types: RefCell<FxHashMap<(DefId, layout::Primitive), &'a DIType>>,+    namespace_map: RefCell<DefIdMap<&'a DIScope>>, +    // FIXME(eddyb) move all of the type stuff into `TypeMap` and out an `Option` around `RefCell`.

s/out/add?

eddyb

comment created time in 7 days

Pull request review commentrust-lang/rust

rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.

 const DW_TAG_arg_variable: c_uint = 0x101;  /// A context object for maintaining all state needed by the debuginfo module. pub struct CrateDebugContext<'a, 'tcx> {+    // FIXME(eddyb) we need this?! at all?!

A const int needs to be creates when emitting enum debuginfo. With my WIP PR the CodegenCx is no longer passed to all debuginfo functions, so the context is necessary to be stored here. I don't know where it is currently needed though.

eddyb

comment created time in 7 days

Pull request review commentrust-lang/rust

rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1.

 impl DebugInfoMethods<'tcx> for CodegenCx<'ll, 'tcx> {                     // so avoid methods on other types (e.g., `<*mut T>::null`).                     match impl_self_ty.kind {                         ty::Adt(def, ..) if !def.is_box() => {-                            Some(type_metadata(cx, impl_self_ty, rustc_span::DUMMY_SP))+                            // Again, only create type information if full debuginfo is enabled

Please remove the "again". Nowhere in this file is there another occurence of this check.

eddyb

comment created time in 7 days

pull request commentrust-lang/rust

Micro-optimize the heck out of LEB128 reading and writing.

UTF-8 validation handles a lot of codepoints every call, while these read and write methods only handle a single LEB128 int per call, so SIMD is likely not useful.

nnethercote

comment created time in 7 days

Pull request review commentrust-lang/rust

Micro-optimize the heck out of LEB128 reading and writing.

-#[inline]-pub fn write_to_vec(vec: &mut Vec<u8>, byte: u8) {-    vec.push(byte);-}--#[cfg(target_pointer_width = "32")]-const USIZE_LEB128_SIZE: usize = 5;-#[cfg(target_pointer_width = "64")]-const USIZE_LEB128_SIZE: usize = 10;--macro_rules! leb128_size {-    (u16) => {-        3-    };-    (u32) => {-        5-    };-    (u64) => {-        10-    };-    (u128) => {-        19-    };-    (usize) => {-        USIZE_LEB128_SIZE-    };-}- macro_rules! impl_write_unsigned_leb128 {     ($fn_name:ident, $int_ty:ident) => {         #[inline]         pub fn $fn_name(out: &mut Vec<u8>, mut value: $int_ty) {-            for _ in 0..leb128_size!($int_ty) {-                let mut byte = (value & 0x7F) as u8;-                value >>= 7;-                if value != 0 {-                    byte |= 0x80;-                }--                write_to_vec(out, byte);--                if value == 0 {+            loop {+                if value < 0x80 {+                    out.push(value as u8);                     break;+                } else {+                    out.push(((value & 0x7f) | 0x80) as u8);

Does LLVM optimize both to the same code?

nnethercote

comment created time in 7 days

Pull request review commentrust-analyzer/rust-analyzer

Add error context to failures in `ra_project_model` using `anyhow` crate

 ra_cfg = { path = "../ra_cfg" }  serde = { version = "1.0.89", features = ["derive"] } serde_json = "1.0.39"++anyhow = "1.0.26"

Missing trailing newline.

adamrk

comment created time in 7 days

more