`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
incr.comp.: Switch to red/green change tracking, remove legacy system.
This PR finally switches incremental compilation to [red/green tracking](https://github.com/rust-lang/rust/issues/42293) and completely removes the legacy dependency graph implementation -- which includes a few quite costly passes that are simply not needed with the new system anymore.
There's still some documentation to be done and there's certainly still lots of optimizing and tuning ahead -- but the foundation for red/green is in place with this PR. This has been in the making for a long time `:)`
r? @nikomatsakis
cc @alexcrichton, @rust-lang/compiler
Remove mem::transmute used in Box<str> conversions
Given that https://github.com/rust-lang/rust/pull/44877 is failing, I decided to make a separate PR. This is done with the same motivation: to avoid `mem::transmute`-ing non `#[repr(C)]` types.
Overlapping borrows can point to different lvalues.
Overlapping borrows can point to different lvalues.
There's always a basis for the overlap, so instead of removing the assert entirely, I instead pass in the prefix that we found and check that it actually is a prefix of both lvalues.
Fix#44829
make `backtrace = false` compile for windows targets.
when building for windows with `backtrace = false`, `libstd` fails to compile because some modules that use items from `sys_common::backtrace::*` are still included, even though those modules aren't used or referenced by anything.
`sys_common::backtrace` doesn't exist when the backtrace feature is turned off.
--
i've also added `#[cfg(feature = "backtrace")]` to various items that exist exclusively to support `mod backtrace` since the compilation would fail since they would be unused in a configuration with backtraces turned off.
Made `fs::copy` return the length of the main stream
On Windows with the NTFS filesystem, `fs::copy` would return the sum of the
lengths of all streams, which can be different from the length reported by
`metadata` and thus confusing for users unaware of this NTFS peculiarity.
This makes `fs::copy` return the same length `metadata` reports which is the
value it used to return before PR #26751. Note that alternate streams are still
copied; their length is just not included in the returned value.
This change relies on the assumption that the stream with index 1 is always the
main stream in the `CopyFileEx` callback. I could not find any official
document confirming this but empirical testing has shown this to be true,
regardless of whether the alternate stream is created before or after the main
stream.
Resolves#44532
