about summary refs log tree commit diff
path: root/src/libsyntax/parse
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2013-03-28 21:48:49 -0700
committerbors <bors@rust-lang.org>2013-03-28 21:48:49 -0700
commitf7a2371c176663d59062ec5158f39faecba45768 (patch)
tree51979c417b823bfd7e7f123eae26717d15fb8c15 /src/libsyntax/parse
parentd98a195ffc6f68cf071826917e50eb4ad80b270b (diff)
parent1163f69c847a768c6c0a987c8172c600519bf649 (diff)
downloadrust-f7a2371c176663d59062ec5158f39faecba45768.tar.gz
rust-f7a2371c176663d59062ec5158f39faecba45768.zip
auto merge of #5614 : graydon/rust/static-linkage-bug, r=catamorphism
re bug that @nikomatsakis was hitting: when you define a `static` (old: `const`) containing a `&` or `&[]` expression, it will create temporaries (the underlying pointee) by creating a throwaway symbol for each temporary, each with _global_ linkage, and each named `"const"`. LLVM will helpfully rename multiple copies of this throwaway symbol to `"const1"` and `"const2"` and so forth in the _same_ library. But if you have _2 libraries_ -- say, libcore and librustc -- that both do this, the dynamic linker (at least on linux) will happily do horrible things like make the slice in one library point to the bytes of the vector from the other library. This is obviously a recipe for much hilarity and head-scratching.

The solution is to change the linkage to something else, internal or (in the case of this patch) _private_.

It will require a snapshot to integrate this into stage0 and thereby fix the problem / unblock patches that were hitting this in stage1.
Diffstat (limited to 'src/libsyntax/parse')
0 files changed, 0 insertions, 0 deletions