Skip to content

bash alias to rustc stops working #15662

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
edwardw opened this issue Jul 14, 2014 · 2 comments
Closed

bash alias to rustc stops working #15662

edwardw opened this issue Jul 14, 2014 · 2 comments

Comments

@edwardw
Copy link
Contributor

edwardw commented Jul 14, 2014

I usually maintain two versions of rustc in parallel. One is relatively stable and the other is compiled from my local repository. The stable one is in the bash path and the transient one is simply an alias like so:

alias rc1='path/to/rust/x86_64-apple-darwin/stage1/bin/rustc'

But recently the alias one doesn't work any more. If invoking that rustc from any directory other than the local rust repository, it is an error:

dyld: lazy symbol binding failed: Symbol not found: __ZN10lang_start20h795a192a885be7beEoeE
  Referenced from: /path/to/rust/x86_64-apple-darwin/stage1/bin/rustc
  Expected in: /usr/local/lib/libnative-4e7c5e5c.dylib

dyld: Symbol not found: __ZN10lang_start20h795a192a885be7beEoeE
  Referenced from: /path/to/rust/x86_64-apple-darwin/stage1/bin/rustc
  Expected in: /usr/local/lib/libnative-4e7c5e5c.dylib

Trace/BPT trap: 5

This is rather inconvenient.

@alexcrichton
Copy link
Member

Closing, this is due to disabling rpaths by default. I would recommend configuring local checkouts with --enable-rpath to preserve the old behavior.

@edwardw
Copy link
Contributor Author

edwardw commented Jul 14, 2014

Works like a charm. Thanks, @alexcrichton.

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
…ch, r=Veykril

fix: panic with wrapping/unwrapping result return type assists

With the `wrap_return_type_in_result` assist, the following code results in a panic (note the lack of a semicolon):

```rust
fn foo(num: i32) -> $0i32 {
    return num
}

=>

thread 'handlers::wrap_return_type_in_result::tests::wrap_return_in_tail_position' panicked at crates/syntax/src/ted.rs:137:41:
called `Option::unwrap()` on a `None` value
```

I think this is because it first walks the body expression to change any `return` expressions and then walks all tail expressions, resulting in the `return num` being changed twice since it is both a `return` and in tail position. This can also happen when a `match` is in tail position and `return` is used in a branch for example. Not really sure how big of an issue this is in practice though since this seems to be the only case that is impacted and can be reduced to just `num` instead of `return num`.

This also occurs with the `unwrap_result_return_type` assist but panics with the following instead:

```
thread 'handlers::unwrap_result_return_type::tests::wrap_return_in_tail_position' panicked at /rustc/3223b0b5e8dadda3f76c3fd1a8d6c5addc09599e/library/alloc/src/string.rs:1766:29:
assertion failed: self.is_char_boundary(n)
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants