1. Is doing part (b) necessary? That is, does LLVM's optimization
already eliminate unused code?
I don't believe that it is from a final binary point of view.
Unreachable functions will be flagged as internal, and LLVM can do
whatever it wants with internal symbols. I would imagine that it
On 24/11/13 20:15, Alex Crichton wrote:
3. My code also marks the function `load_argc_and_argv` in
libstd/os.rs as dead when in fact it isn't. I would guess it's because
that function is only used when compiling the rustc source code on
Mac, whereas I'm compiling it on Linux. How do I modify my
I had the following idea to approach language evolution:
Problem:
Languages try to be backward compatible by stabilizing, and only slowly
deprecating old features. This results in a language which does not
evolve. Some different takes about this:
C++: adds new features but does not fix
Hi Manuel,
I must say that on a conceptual point of view I like the approach, keeping
one's libraries up to date is the only way to go, however I am afraid that
you are glossing over certain details here:
- you assume that the source code is available, this is a problem if I am
using a 3rd party
On Sat, Nov 23, 2013 at 10:44 PM, Kiet Tran ktt...@virginia.edu wrote:
1. Is doing part (b) necessary? That is, does LLVM's optimization
already eliminate unused code?
LLVM does, yes, but I'd still be interested in a perf comparison of us
not translating the dead code compared to LLVM
Welcome to another issue of *This Week in Rust*!
# What's cooking on master?
47 PRs were merged this week.
## Breaking Changes
- Non-ASCII identifiers are [feature
gated](https://github.com/mozilla/rust/pull/10605), due to open questions
about how it should be done. They aren't being
Hi Manuel,
I must say that on a conceptual point of view I like the approach,
keeping one's libraries up to date is the only way to go, however I am
afraid that you are glossing over certain details here:
- you assume that the source code is available, this is a problem if I
am using a 3rd
LLVM does, yes, but I'd still be interested in a perf comparison of us
not translating the dead code compared to LLVM stripping it later.
Clang does this, for example.
But if the idea here is also to provide a dead-code warning during
compilation, is it necessary to add this feature to the