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
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
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
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)
Early exit for empty HashMap (issue #38880)
Addresses issue #38880 by checking if the HashMap is empty before computing the value of the hash.
Before (integer keys)
```
running 4 tests
test empty_once ... bench: 13 ns/iter (+/- 0)
test empty_100 ... bench: 1,367 ns/iter (+/- 35)
test exist_once ... bench: 14 ns/iter (+/- 0)
test exist_100 ... bench: 1,518 ns/iter (+/- 40)
```
After
```
running 4 tests
test empty_once ... bench: 2 ns/iter (+/- 0)
test empty_100 ... bench: 221 ns/iter (+/- 0)
test exist_once ... bench: 15 ns/iter (+/- 0)
test exist_100 ... bench: 1,515 ns/iter (+/- 92)
```
When the HashMap is not empty, the performance remains the same, and when it is empty the performance is significantly improved.
Update compiler-builtins to latest master.
- Rebase compiler-rt submodule to LLVM 6
- New VFP intrinsics on ARM
- Add generic conversion from a narrower to a wider FP type (f32 to f64)
- Fixes minor issues on _subsf3, __subdf3 and __aeabi_fcmple
- Split test suite to a separate crate
incr.comp.: Run cache directory garbage collection before loading dep-graph.
Prior to this PR, the incr. comp. cache directory would only be garbage collected after the final output artifacts were generated. However, compilation often aborts earlier and in the case of the RLS, which starts lots of compilation sessions, we might fill up the cache directory with chunk sessions.
This PR makes the compiler do a garbage collection run before loading the dep-graph.
cc @nrc https://github.com/rust-lang/rust/issues/48172
r? @nikomatsakis
Remove allocation from width of character function.
Locally this seems to eliminate the problem or at least resolve most of the
issue.
Fixes#48153.
r? @estebank
Update compiletest's `read2` function
This was originally copied over from Cargo and Cargo has since [been
updated][update] so let's pull in the fixes here too!
[update]: https://github.com/rust-lang/cargo/pull/5030
rustc: Persist LLVM's `Linker` in Fat LTO
This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's
"link modules" functionality. Previously whenever the
`LLVMRustLinkInExternalBitcode` function was called it would call LLVM's
`Linker::linkModules` wrapper. Internally this would crate an instance of a
`Linker` which internally creates an instance of an `IRMover`. Unfortunately for
us the creation of `IRMover` is somewhat O(n) with the input module. This means
that every time we linked a module it was O(n) with respect to the entire module
we had built up!
Now the modules we build up during LTO are quite large, so this quickly started
creating an O(n^2) problem for us! Discovered in #48025 it turns out this has
always been a problem and we just haven't noticed it. It became particularly
worse recently though due to most libraries having 16x more object files than
they previously did (1 -> 16).
This commit fixes this performance issue by preserving the `Linker` instance
across all links into the main LLVM module. This means we only create one
`IRMover` and allows LTO to progress much speedier.
From the `cargo-cache` project in #48025 a **full build** locally went from
5m15s to 2m24s. Looking at the timing logs each object file was linked in in
single-digit millisecond rather than hundreds, clearly being a nice improvement!
Closes#48025
Add std/core::iter::repeat_with
Adds an iterator primitive `repeat_with` which is the "lazy" version of `repeat` but also more flexible since you can build up state with the `FnMut`. The design is mostly taken from `repeat`.
r? @rust-lang/libs
cc @withoutboats, @scottmcm
Continue parsing function after finding `...` arg
When encountering a variadic argument in a function definition that
doesn't accept it, if immediately after there's a closing paren,
continue parsing as normal. Otherwise keep current behavior of emitting
error and stopping.
Fix#31481.
Update ops range example to avoid confusion between indexes and values.
Makes clearer the numbers in the range refer to indexes, not the values at those indexes.
Correct a few stability attributes
* `core_float_bits`, `duration_core`, `path_component_asref`, and `repr_align` were stabalized in 1.25.0 not 1.24.0.
* Impls for `NonNull` involving unstable things should remain unstable.
* `Duration` should remain stable since 1.3.0 so it appears correctly in the `std` docs.
* `cursor_mut_vec` is an impl on only stable things so should be marked stable.
Add Range[Inclusive]::is_empty
During https://github.com/rust-lang/rfcs/pull/1980, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- such as `Range<i64>` and `RangeInclusive<usize>`.
Things to ponder:
- Unless this is stabilized first, this makes stabilizing ExactSizeIterator::is_empty more icky, since this hides that.
- This is only on `Range` and `RangeInclusive`, as those are the only ones where it's interesting. But one could argue that it should be on more for consistency, or on RangeArgument instead.
- The bound on this is PartialOrd, since that works ok (see tests for float examples) and is consistent with `contains`. But ranges like `NAN..=NAN`_are_ kinda weird.
- [x] ~~There's not a real issue number on this yet~~
Apply optimization from #44355 to retain
As discussed in #44355 this PR applies a similar optimization to `Vec::retain`. For `drain_filter`, a very similar function, this improved performance by up to 20%.
Work around LLVM OCAML binding installation failure
Hello,
I have OCaml installed on my machine, and compiling rust systematically fails when LLVM attempts installing the OCaml bindings in `/usr/lib/ocaml`, which is write-protected. Here are the logs: https://gist.github.com/roblabla/3f147914c5df627c9d97ab311ba133ad
Some digging around the issue reveals:
- The code that finds if OCaml is installed, and sets the bindings to be compiled/installed: b24a45d2e9/cmake/config-ix.cmake (L612)
- b24a45d2e9/bindings/ocaml/llvm/CMakeLists.txt Some code that does the installation.
The problem seems to be that `LLVM_OCAML_INSTALL_PATH` is set to `OCAML_STDLIB_PATH` by default, which is in `/usr/lib/ocaml`, instead of the prefix.
This PR "fixes" the issue by setting `LLVM_OCAML_INSTALL_PATH` to `usr/lib/ocaml`. I haven't found a way to make LLVM not build OCaml, which would probably be a superior fix.
Changed color of struct link from #ff794d to #2dbfb8 for Rust docs
This is in reference to https://github.com/rust-lang/rust/issues/47801
here I have changed the default color of struct link for `#ff794d` to `#2dbfb8`
cc: @nagisa @timClicks
rustc: Add the ability to not run dsymutil
This commit adds the ability for rustc to not run `dsymutil` by default
on OSX. A new codegen option, `-Z run-dsymutil=no`, was added to specify
that `dsymutil` should *not* run and instead the compiler should
unconditionally keep the object files around in a compilation if
necessary for debug information.
cc #47240
Some Steps are by-default run but don't have any paths associated with
them. We need to have at least one PathSet per each Step, though, so we
add an empty one on calls to `never()`.
