Don't promote to 'static the result of dereferences.
This is a **breaking change**, removing copies out of dereferences from rvalue-to-`'static` promotion.
With miri we won't easily know whether the dereference itself would see the same value at runtime as miri (e.g. after mutating a `static`) or even if it can be interpreted (e.g. integer pointers).
One alternative to this ban is defining at least *some* of those situations as UB, i.e. you shouldn't have a reference in the first place, and you should work through raw pointers instead, to avoid promotion.
**EDIT**: The other *may seem* to be to add some analysis which whitelists references-to-constant-values and assume any values produced by arbitrary computation to not be safe to promote dereferences thereof - but that means producing a reference from an associated constant or `const fn` would necessarily obscure it, and in the former case, this could still impact code that runs on stable today. What we do today to track "references to statics" only works because we restrict taking a reference to a `static` at all to other `static`s (which, again, are currently limited in that they can't be read at compile-time) and to runtime-only `fn`s (*not* `const fn`s).
I'm primarily opening this PR with a conservative first approximation (e.g. `&(*r).a` is not allowed, only reborrows are, and in the old borrow only implicit ones from adjustments, at that) for cratering.
r? @nikomatsakis
Remove "empty buffer" doc in read_until
This appears copied from fill_buf, but the above paragraph already indicates that a lack of delimiter at the end is EOF.
Primitive docs relevant
This fixes the documentation to show the right types in the examples for many integer methods.
I need to check if the result is correct before we merge.
add unit tests for rustdoc's processing of doctests
cc #42018
There's a lot of things that rustdoc will do to massage doctests into something that can be compiled, and a lot of options that can be toggled to affect this. Hopefully this list of tests can show off that functionality.
The first commit is slightly unrelated but doesn't touch public functionality, because i found that if you have a manual `fn main`, it adds an extra line break at the end, whereas it would trim this extra line break if it were putting a `fn main` in automatically. That first commit makes it trim out that whitespace ahead of time.
This is the ideal FileType on Windows. You may not like it, but this is what peak performance looks like.
Theoretically this would fix https://github.com/rust-lang/rust/issues/46484
The current iteration of this PR should not cause existing code to break, but instead merely improves handling around reparse points. Specifically...
* Reparse points are considered to be symbolic links if they have the name surrogate bit set. Name surrogates are reparse points that effectively act like symbolic links, redirecting you to a different directory/file. By checking for this bit instead of specific tags, we become much more general in our handling of reparse points, including those added by third parties.
* If something is a reparse point but does not have the name surrogate bit set, then we ignore the fact that it is a reparse point because it is actually a file or directory directly there, despite having additional handling by drivers due to the reparse point.
* For everything which is not a symbolic link (including non-surrogate reparse points) we report whether it is a directory or a file based on the presence of the directory attribute bit.
* Notably this still preserves invariant that when `is_symlink` returns `true`, both `is_dir` and `is_file` will return `false`. The potential for breakage was far too high.
* Adds an unstable `FileTypeExt` to allow users to determine whether a symbolic link is a directory or a file, since `FileType` by design is incapable of reporting this information.
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
