Now that new LLVM has landed, the debug info works on Windows as well. Most existing tests pass, except for the following four, which I left disabled for now:
lexical-scope-in-for-loop
lexical-scope-in-if
lexical-scope-in-match
lexical-scopes-in-block-expression
Also, fixed a small problem with the debug info test runner.
This is a pull request for #2275
I've created a small python script to generate test files for a list of keywords (as break do else enum extern false fn for if impl let loop match mod mut priv pub ref return self static struct super true trait type unsafe use while), but I'm not really sure where to put it. I've added the created files as well.
I did not use
fn main() {
let $KW = "foo"; //~ error
println($KW); //~ error
}
as template, because for return, self, ref, loop, mut and break this does not raise an error in the ```println``` line, only in the ```let``` line.
This is in preparation for making discriminants not always be int (#1647), but it also makes compiles for a 64-bit target not behave differently — with respect to how many bits of discriminants are preserved — depending on the build host's word size, which is a nice property to have.
We may want to standardize how to abbreviate "discriminant" in a followup change.
These new macros are all based on format! instead of fmt! and purely exist for
bootstrapping purposes. After the next snapshot, all uses of logging will be
migrated to these macros, and then after the next snapshot after that we can
drop the `2` suffix on everything
This resolves issue #908.
Notable changes:
- On Windows, LLVM integrated assembler emits bad stack unwind tables when segmented stacks are enabled. However, unwind info directives in the assembly output are correct, so we generate assembly first and then run it through an external assembler, just like it is already done for Android builds.
- Linker is invoked via "g++" command instead of "gcc": g++ passes the appropriate magic parameters to the linker, which ensure correct registration of stack unwind tables in dynamic libraries.
For #7083.
The metadata issue with the old version is now fixed. Ready for review.
This is also not the full solution to #7083, because this is not supported yet:
```
trait Foo : Send { }
impl <T: Send> Foo for T { }
fn foo<T: Foo>(val: T, chan: std::comm::Chan<T>) {
chan.send(val);
}
```
cc @nikomatsakis
