Improve resolution of associated types in declarative macros 2.0
Make various identifier comparisons for associated types (and sometimes other associated items) hygienic.
Now declarative macros 2.0 can use `Self::AssocTy`, `TyParam::AssocTy`, `Trait<AssocTy = u8>` where `AssocTy` is an associated type of a trait `Trait` visible from the macro. Also, `Trait` can now be implemented inside the macro and specialization should work properly (fixes https://github.com/rust-lang/rust/pull/40847#issuecomment-310867299).
r? @jseyfried or @eddyb
incr compilation struct_defs.rs
I am prematurely openeing this as I need mentoring help from @michaelwoerister (also pinged @nikomatsakis)
First, is this the right approach for these changes?
Second, I'm a bit confused by the results so far.
- Changing `TupleStructFieldType(i32)` -> `...(u32)` changes only Hir and HirBody, not TypeOfItem
- Chaning `TupleStructAddField(i32)` -> `...(i32, u32)` *does* change TypeOfItem
This seems wrong. I feel like it should change TypeOfItem in both cases. Is this a bug in incr compilation or is it expected?
Faster compile times for release builds with llvm fix
Run global optimizations after the inliner to avoid spending time on optimizing dead code.
fixes#44655
The previous workaround for gibc's res_init bug is not thread-safe on
other implementations of libc, and it can cause crashes. Use a runtime
check to make sure we only call res_init when we need to, which is also
when it's safe. See https://github.com/rust-lang/rust/issues/43592.
There are a few exceptions to the rule that Arc/Rc are immutable. Rather
than dig into the details, add "generally" to hint at this difference,
as it's kind of a distraction at this point in the docs.
Additionally, Arc's docs were slightly different here generally, so add
in both the existing language and the exception.
Fixes#44105
`EndRegion` do not always correspond to borrow-data entries
Remove assertion that the argument to every `EndRegion` correspond to some dataflow-tracked borrow-data entry.
Fix#44828
(The comment thread on the aforementioned issue discusses why its best to just remove this assertion.)
fix ItemKind::DefaultImpl doc comment
Upgrade comment to doc comment.
...Is this actually used? If so, why does the `Impl` variant right below have a `Defaultness`?
Add links to headers in README and CONTRIBUTING
this also adds dependencies to CONTRIBUTING
I'm just getting started building the rust compiler and noticed this information/ability was missing.
It was also missing the gdb dependency for running tests. I pulled the information out of `appveyor.yml` and recommended later than 7.1 because that is what [apt ships](https://packages.ubuntu.com/search?suite=trusty&keywords=gdb). Feel free to tell me something different!
Don't unwrap work item results as the panic trace is useless
Fixes#43402 now there's no multithreaded panic printouts
Also update a comment
--------
Likely regressed in #43506, where the code was changed to panic in worker threads on error.
Unwrapping gives zero extra information since the stack trace is so short, so we may as well just surface that there was an error and exit the thread properly. Because there are then no multithreaded printouts, I think it should mean the output of the test for #26199 is deterministic and not interleaved (thanks to @philipc https://github.com/rust-lang/rust/issues/43402#issuecomment-333835271 for a hint).
Sadly the output is now:
```
thread '<unnamed>' panicked at 'aborting due to worker thread panic', src/librustc_trans/back/write.rs:1643:20
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: could not write output to : No such file or directory
error: aborting due to previous error
```
but it's an improvement over the multi-panic situation before.
r? @alexcrichton
* Use size_t where size_t is used, while it's not critical on our
specifically supported architectures, this is more accurate.
* Update HND_SPECIAL_COUNT to the correct value, and give it the size
that enum is likely to be.
