Add a `fatal_cycle` attribute for queries which indicates that they will cause a fatal error on query cycles
This moves us towards the goal of having cycle errors be non-fatal by not relying on the default implementation of `ty::maps::values::Value` which aborts on errors.
r? @nikomatsakis
Is it really time? Have our months, no, *years* of suffering come to an end? Are we finally able to cast off the pall of Hoedown? The weight which has dragged us down for so long?
-----
So, timeline for those who need to catch up:
* Way back in December 2016, [we decided we wanted to switch out the markdown renderer](https://github.com/rust-lang/rust/issues/38400). However, this was put on hold because the build system at the time made it difficult to pull in dependencies from crates.io.
* A few months later, in March 2017, [the first PR was done, to switch out the renderers entirely](https://github.com/rust-lang/rust/pull/40338). The PR itself was fraught with CI and build system issues, but eventually landed.
* However, not all was well in the Rustdoc world. During the PR and shortly after, we noticed [some differences in the way the two parsers handled some things](https://github.com/rust-lang/rust/issues/40912), and some of these differences were major enough to break the docs for some crates.
* A couple weeks afterward, [Hoedown was put back in](https://github.com/rust-lang/rust/pull/41290), at this point just to catch tests that Pulldown was "spuriously" running. This would at least provide some warning about spurious tests, rather than just breaking spontaneously.
* However, the problems had created enough noise by this point that just a few days after that, [Hoedown was switched back to the default](https://github.com/rust-lang/rust/pull/41431) while we came up with a solution for properly warning about the differences.
* That solution came a few weeks later, [as a series of warnings when the HTML emitted by the two parsers was semantically different](https://github.com/rust-lang/rust/pull/41991). But that came at a cost, as now rustdoc needed proc-macro support (the new crate needed some custom derives farther down its dependency tree), and the build system was not equipped to handle it at the time. It was worked on for three months as the issue stumped more and more people.
* In that time, [bootstrap was completely reworked](https://github.com/rust-lang/rust/pull/43059) to change how it ordered compilation, and [the method by which it built rustdoc would change](https://github.com/rust-lang/rust/pull/43482), as well. This allowed it to only be built after stage1, when proc-macros would be available, allowing the "rendering differences" PR to finally land.
* The warnings were not perfect, and revealed a few [spurious](https://github.com/rust-lang/rust/pull/44368) [differences](https://github.com/rust-lang/rust/pull/45421) between how we handled the renderers.
* Once these were handled, [we flipped the switch to turn on the "rendering difference" warnings all the time](https://github.com/rust-lang/rust/pull/45324), in October 2017. This began the "warning cycle" for this change, and landed in stable in 1.23, on 2018-01-04.
* Once those warnings hit stable, and after a couple weeks of seeing whether we would get any more reports than what we got from sitting on nightly/beta, [we switched the renderers](https://github.com/rust-lang/rust/pull/47398), making Pulldown the default but still offering the option to use Hoedown.
And that brings us to the present. We haven't received more new issues from this in the meantime, and the "switch by default" is now on beta. Our reasoning is that, at this point, anyone who would have been affected by this has run into it already.
Fix not running some steps in CI
We'd previously assumed that these paths would be relative to the src
dir, and that for example our various CI scripts would, when calling
x.py, use `../x.py build ../src/tools/...` but this isn't the case --
they use `../x.py` without using the relevant source-relative path.
We eventually may want to make this (actually somewhat logical) change,
but this is not that time.
r? @kennytm
Closes#47981
This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here.
Refactor diverging and numeric fallback.
This refactoring tries to make numeric fallback easier to reason about. Instead of applying all fallbacks at an arbitrary point in the middle of inference, we apply the fallback only when necessary and only for
the variable that requires it. The only place that requires early fallback is the target of numeric casts.
The visible consequences is that some error messages that got `i32` now get `{integer}` because we are less eager about fallback.
The bigger goal is to make it easier to integrate user fallbacks into inference, if we ever figure that out.
We'd previously assumed that these paths would be relative to the src
dir, and that for example our various CI scripts would, when calling
x.py, use `../x.py build ../src/tools/...` but this isn't the case --
they use `../x.py` without using the relevant source-relative path.
We eventually may want to make this (actually somewhat logical) change,
but this is not that time.
Primarily for CI purposes; this is intended to avoid cases where we
update rustbuild and unintentionally make CI stop running some builds to
the arguments being passed no longer applying for some reason.
#37653 support `default impl` for specialization
this commit implements the second part of the `default impl` feature:
> - a `default impl` need not include all items from the trait
> - a `default impl` alone does not mean that a type implements the trait
The first point allows rustc to compile and run something like this:
```
trait Foo {
fn foo_one(&self) -> &'static str;
fn foo_two(&self) -> &'static str;
}
default impl<T> Foo for T {
fn foo_one(&self) -> &'static str {
"generic"
}
}
struct MyStruct;
fn main() {
assert!(MyStruct.foo_one() == "generic");
}
```
but it shows a proper error if trying to call `MyStruct.foo_two()`
The second point allows a `default impl` to be considered as not implementing the `Trait` if it doesn't implement all the trait items.
The tests provided (in the compile-fail section) should cover all the possible trait resolutions.
Let me know if some tests is missed.
See [referenced ](https://github.com/rust-lang/rust/issues/37653) issue for further info
r? @nikomatsakis
It's unhelpful since raw pointers to trait objects are also FFI-unsafe and casting to a thin raw pointer loses the vtable. There are working solutions that _involve_ raw pointers but they're too complex to explain in one line and have serious trade offs.
The suggestion is unconditional, so following it could lead to further errors. This is already the case for the repr(C) suggestion, which makes this acceptable, though not *good*. Checking up-front whether the suggestion can help would be great but applies more broadly (and would require some refactoring to avoid duplicating the checks).
- Always name the non-FFI-safe
- Explain *why* the type is not FFI-safe
- Stop vaguely gesturing at structs/enums/unions if the non-FFI-safe types occured in a field.
The last part is arguably a regression, but it's minor now that the non-FFI-safe type is actually named. Removing it avoids some code duplication.
This dates back to at least #26583. At the time, usize and isize were considered ffi-unsafe to nudge people away from them, but this changed in the aforementioned PR, making it inconsistent to complain about it in enum discriminants. In fact, repr(usize) is probably the best way to interface with `enum Foo : size_t { ... }`.
Implement excluding a build-step via --exclude
First step to fixing https://github.com/rust-lang/rust/issues/47911. This doesn't change any CI configuration, but implements what I believe necessary to make that feasible in rustbuild.
In theory this should be sufficient to allow someone to open a PR against .travis.yml and appveyor.yml which splits the Windows 32-bit tests and maybe the OS X tests into multiple builders (depending on what our cost-concerns are) to reduce runtimes.
r? @alexcrichton
cc @kennytm
Clarified why `Sized` bound not implicit on trait's implicit `Self` type.
This part of the documentation was a little confusing to me on first read. I've added a couple lines for further explanation. Hopefully this makes things a bit clearer for new readers.
Try to fix 48116 and 48192
The bug #48116 happens because of a misoptimization of the `import_path_to_string` function, where a `names` slice is empty but the `!names.is_empty()` branch is executed.
4d2d3fc5da/src/librustc_resolve/resolve_imports.rs (L1015-L1042)
Yesterday, @eddyb had locally reproduced the bug, and [came across the `position` function](https://mozilla.logbot.info/rust-infra/20180214#c14296834) where the `assume()` call is found to be suspicious. We have *not* concluded that this `assume()` causes #48116, but given [the reputation of `assume()`](https://github.com/rust-lang/rust/pull/45501#issuecomment-340159627), this seems higher relevant. Here we try to see if commenting it out can fix the errors.
Later @alexcrichton has bisected and found a potential bug [in the LLVM side](https://github.com/rust-lang/rust/issues/48116#issuecomment-365624777). We are currently testing if reverting that LLVM commit is enough to stop the bug. If true, this PR can be reverted (keep the `assume()`) and we could backport the LLVM patch instead.
(This PR also includes an earlier commit from #48127 for help debugging ICE happening in compile-fail/parse-fail tests.)
The PR also reverts #48059, which seems to cause #48192.
r? @alexcrichton
cc @eddyb, @arthurprs (#47333)
