]> git.lizzy.rs Git - rust.git/commit - src/tools/rust-analyzer
Rollup merge of #82804 - alexcrichton:fix-wasi, r=pnkfelix
authorYuki Okushi <huyuumi.dev@gmail.com>
Sun, 14 Mar 2021 04:07:33 +0000 (13:07 +0900)
committerGitHub <noreply@github.com>
Sun, 14 Mar 2021 04:07:33 +0000 (13:07 +0900)
commit9ce0820eefaa6dbfeadbca75f99063ae668cb30d
tree759700bd3a4f09c6b3a4640319721f56cbb0bf35
parent33614023a186133841322ac9bae70a6123f853f0
parentd6b06b8a327ff32d083bc0494cc3195d9f8082d2
Rollup merge of #82804 - alexcrichton:fix-wasi, r=pnkfelix

std: Fix a bug on the wasm32-wasi target opening files

This commit fixes an issue pointed out in #82758 where LTO changed the
behavior of a program. It turns out that LTO was not at fault here, it
simply uncovered an existing bug. The bindings to
`__wasilibc_find_relpath` assumed that the relative portion of the path
returned was always contained within thee input `buf` we passed in. This
isn't actually the case, however, and sometimes the relative portion of
the path may reference a sub-portion of the input string itself.

The fix here is to use the relative path pointer coming out of
`__wasilibc_find_relpath` as the source of truth. The `buf` used for
local storage is discarded in this function and the relative path is
copied out unconditionally. We might be able to get away with some
`Cow`-like business or such to avoid the extra allocation, but for now
this is probably the easiest patch to fix the original issue.