forbid manually impl'ing one of an object type's marker traits
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.
bors [Sun, 13 Jan 2019 11:54:02 +0000 (11:54 +0000)]
Auto merge of #57568 - Centril:rollup, r=Centril
Rollup of 16 pull requests
Successful merges:
- #57351 (Don't actually create a full MIR stack frame when not needed)
- #57353 (Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).)
- #57412 (Improve the wording)
- #57436 (save-analysis: use a fallback when access levels couldn't be computed)
- #57453 (lldb_batchmode.py: try `import _thread` for Python 3)
- #57454 (Some cleanups for core::fmt)
- #57461 (Change `String` to `&'static str` in `ParseResult::Failure`.)
- #57473 (std: Render large exit codes as hex on Windows)
- #57474 (save-analysis: Get path def from parent in case there's no def for the path itself.)
- #57494 (Speed up item_bodies for large match statements involving regions)
- #57496 (re-do docs for core::cmp)
- #57508 (rustdoc: Allow inlining of reexported crates and crate items)
- #57547 (Use `ptr::eq` where applicable)
- #57557 (resolve: Mark extern crate items as used in more cases)
- #57560 (hygiene: Do not treat `Self` ctor as a local variable)
- #57564 (Update the const fn tracking issue to the new metabug)
Rollup merge of #57564 - varkor:update-const_fn-tracking-issue, r=Centril
Update the const fn tracking issue to the new metabug
The new `const fn` tracking issue is #57563. We don't want to point to a closed issue in the diagnostics (or FIXMEs), so these have been updated (from the old issue, #24111).
Rollup merge of #57547 - Xanewok:ptr-eq, r=petrochenkov
Use `ptr::eq` where applicable
Stumbled upon a few of `A as *const _ as usize == B as *const as usize`, so I decided to follow the programming boy scout rule (:smile:) and replaced the pattern with more widely used `ptr::eq`.
Rollup merge of #57508 - DebugSteven:inline-extern, r=GuillaumeGomez
rustdoc: Allow inlining of reexported crates and crate items
Fixes #46296
This PR checks for when a `pub extern crate` statement has a `#[doc(inline)]` attribute & inlines its contents. Code is based off of the inlining statements for `pub use` statements.
Rollup merge of #57494 - dotdash:expand, r=nikomatsakis
Speed up item_bodies for large match statements involving regions
These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead.
The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though).
Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them.
We have the right ID when looking for NodeId(31) and try with NodeId(32) (which
is the right thing to look for) from get_path_data. But not when we look from `write_sub_paths_truncated`
Basically process_path takes an id which is always the parent, and that we
fall back to in get_path_data(), so we get the right result for the last path
segment, but not for the other segments that get written to from
write_sub_paths_truncated.
I think we can stop passing the explicit `id` around to get_path_data as a followup.
Rollup merge of #57473 - alexcrichton:hex-display-on-windows, r=Kimundi
std: Render large exit codes as hex on Windows
On Windows process exit codes are never signals but rather always 32-bit
integers. Most faults like segfaults and such end up having large
integers used to represent them, like STATUS_ACCESS_VIOLATION being
0xC0000005. Currently, however, when an `ExitStatus` is printed this
ends up getting rendered as 3221225477 which is somewhat more difficult
to debug.
This commit adds a branch in `Display for ExitStatus` on Windows which
handles exit statuses where the high bit is set and prints those exit
statuses as hex instead of with decimals. This will hopefully preserve
the current display for small exit statuses (like `exit code: 22`), but
assist in quickly debugging segfaults/access violations/etc. I've
found at least that the hex codes are easier to search for than decimal.
I wasn't able to find any official documentation saying that all system
exit codes have the high bit set, but I figure it's a good enough
heuristic for now.
Rollup merge of #57436 - Xanewok:save-analysis-access-ice-fix, r=nikomatsakis
save-analysis: use a fallback when access levels couldn't be computed
Fixing an RLS regression I introduced in https://github.com/rust-lang/rust/pull/57343 :cry:
I missed a case where we get [called back with analysis when type checking fails](https://github.com/rust-lang/rust/blob/9d54812829e9d92dac35a4a0f358cdc5a2475371/src/librustc_driver/driver.rs#L1264). Since privacy checking normally is done afterwards, when we execute the `privacy_access_levels` query inside the save_analysis callback we'll calculate it for the first time and since typeck info isn't complete, we'll crash there.
Double-checked locally and it seems to have fixed the problem.
Rollup merge of #57353 - huonw:faster-finiteness-checks, r=KodrAus
Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).
These can both rely on IEEE754 semantics to be made faster, by folding
away the sign with an abs (left private for now), and then comparing
to infinity, letting the NaN semantics of a direct float comparison
handle NaN input properly.
The `abs` bit-fiddling is simple (a single and), and so these new
forms compile down to a few instructions, without branches, e.g. for
f32:
When used in loops/repeatedly, they get even better: the memory
operations (loading the mask 0x7FFFFFFF for abs, and infinity
0x7F80_0000) are likely to be hoisted out of the individual calls, to
be shared, and the `seta`/`setae` are likely to be collapsed into
conditional jumps or moves (or similar).
The old `is_infinite` did two comparisons, and the old `is_finite` did
three (with a branch), and both of them had to check the flags after
every one of those comparison. These functions have had that old
implementation since they were added in
https://github.com/rust-lang/rust/commit/6284190ef9918e05cb9147a2a81100ddcb06fea8
7 years ago.
Benchmark (`abs` is the new form, `std` is the old):
```
test f32_is_finite_abs ... bench: 55 ns/iter (+/- 10)
test f32_is_finite_std ... bench: 118 ns/iter (+/- 5)
test f32_is_infinite_abs ... bench: 53 ns/iter (+/- 1)
test f32_is_infinite_std ... bench: 84 ns/iter (+/- 6)
test f64_is_finite_abs ... bench: 52 ns/iter (+/- 12)
test f64_is_finite_std ... bench: 128 ns/iter (+/- 25)
test f64_is_infinite_abs ... bench: 54 ns/iter (+/- 5)
test f64_is_infinite_std ... bench: 93 ns/iter (+/- 23)
```
Rollup merge of #57351 - oli-obk:cheap_const_ops, r=RalfJung
Don't actually create a full MIR stack frame when not needed
r? @dotdash
This should significantly reduce overhead during const propagation and reduce overhead *after* copy propagation (cc https://github.com/rust-lang/rust/issues/36673)
bors [Sat, 12 Jan 2019 20:11:36 +0000 (20:11 +0000)]
Auto merge of #56759 - petrochenkov:prestabuni, r=nikomatsakis
Stabilize `uniform_paths`
Address all the things described in https://github.com/rust-lang/rust/issues/56417.
Assign visibilities to `macro_rules` items - `pub` to `macro_export`-ed macros and `pub(crate)` to non-exported macros, these visibilities determine how far these macros can be reexported with `use`.
Prohibit use of reexported inert attributes and "tool modules", after renaming (e.g. `use inline as imported_inline`) their respective tools and even compiler passes won't be able to recognize and properly check them.
Also turn use of uniform paths in 2015 macros into an error, I'd prefer to neither remove nor stabilize them right away because I still want to make some experiments in this area (uniform path fallback was added to 2015 macros used on 2018 edition in https://github.com/rust-lang/rust/pull/56053#issuecomment-441405140).
UPDATE: The last commit also stabilizes the feature `uniform_paths`.
resolve: Prohibit use of uniform paths in macros originating from 2015 edition
...while still keeping ambiguity errors future-proofing for uniform paths.
This corner case is not going to be stabilized for 1.32 and needs some more general experiments about retrofitting 2018 import rules to 2015 edition
bors [Sat, 12 Jan 2019 11:22:20 +0000 (11:22 +0000)]
Auto merge of #57542 - Centril:rollup, r=Centril
Rollup of 26 pull requests
Successful merges:
- #56425 (Redo the docs for Vec::set_len)
- #56906 (Issue #56905)
- #57042 (Don't call `FieldPlacement::count` when count is too large)
- #57175 (Stabilize `let` bindings and destructuring in constants and const fn)
- #57192 (Change std::error::Error trait documentation to talk about `source` instead of `cause`)
- #57296 (Fixed the link to the ? operator)
- #57368 (Use CMAKE_{C,CXX}_COMPILER_LAUNCHER for ccache)
- #57400 (Rustdoc: update Source Serif Pro and replace Heuristica italic)
- #57417 (rustdoc: use text-based doctest parsing if a macro is wrapping main)
- #57433 (Add link destination for `read-ownership`)
- #57434 (Remove `CrateNum::Invalid`.)
- #57441 (Supporting backtrace for x86_64-fortanix-unknown-sgx.)
- #57450 (actually take a slice in this example)
- #57459 (Reference tracking issue for inherent associated types in diagnostic)
- #57463 (docs: Fix some 'second-edition' links)
- #57466 (Remove outdated comment)
- #57493 (use structured suggestion when casting a reference)
- #57498 (make note of one more normalization that Paths do)
- #57499 (note that FromStr does not work for borrowed types)
- #57505 (Remove submodule step from README)
- #57510 (Add a profiles section to the manifest)
- #57511 (Fix undefined behavior)
- #57519 (Correct RELEASES.md for 1.32.0)
- #57522 (don't unwrap unexpected tokens in `format!`)
- #57530 (Fixing a typographical error.)
- #57535 (Stabilise irrefutable if-let and while-let patterns)
Rollup merge of #57511 - jethrogb:jb/fix-undef, r=cramertj
Fix undefined behavior
From the [`MaybeUninit::get_mut` docs](https://doc.rust-lang.org/std/mem/union.MaybeUninit.html):
> It is up to the caller to guarantee that the the MaybeUninit really is in an initialized state, otherwise this will immediately cause undefined behavior.
Rollup merge of #57459 - varkor:E0202-issue-reference, r=petrochenkov
Reference tracking issue for inherent associated types in diagnostic
This makes it clearer that associated types in inherent impls are an intended feature, like the diagnostic for equality constraints in where clauses. (This is more helpful, because the lack of associated types is a confusing omission and it lets users more easily track the state of the feature.)
Rollup merge of #57441 - VardhanThigle:Vardhan/x86_64-fortanix-unknown-sgx-backtrace-support, r=alexcrichton
Supporting backtrace for x86_64-fortanix-unknown-sgx.
# Overview
Implementing following functions required by `libstd/sys_common` to support `backtrace`:
```
1. unwind_backtrace
2. trace_fn
3. resolve_symname
```
# Description:
The changes here are quite similar to the Cloudabi target `src/libstd/sys/cloudabi/backtrace.rs`
The first 2 functions are implemented via calls to libunwind.a that is linked to the `x86_64-fortanix-unknown-sgx` (#56979), we have not implemented functionality needed by `resolve_symname` (or `dladdr`) to reduce SGX TCB. Rather, we print the function address (relative to enclave image base) in `resolve_symname` which can be later translated to correct symbol name (say, via `addr2line`).
# Note:
For `x86_64-fortanix-unknown-sgx`, the `RUST_BACKTRACE` environment has to be set from within the program running in an enclave.
cc: @jethrogb
r? @alexcrichton
Rollup merge of #57417 - QuietMisdreavus:semi-revert-doctest-parsing, r=GuillaumeGomez
rustdoc: use text-based doctest parsing if a macro is wrapping main
This is a "forward-port" of https://github.com/rust-lang/rust/pull/57019, intended to get https://github.com/rust-lang/rust/issues/56898 on nightly, since it's now fixed on beta (and already worked on stable).
To recap:
* The libsyntax-based doctest parsing now checks to see whether there is a top-level macro invocation in the doctest while it's checking for `fn main` and an `extern crate` statement.
* If it finds a macro invocation and *didn't* find `fn main`, then it performs the older text-based scan to allow doctests like the ones in `allocator_api` to still compile.
A "proper" fix will involve changing how `make_test` works to call it later in the `run_test` function, after the initial steps of compilation have completed. I've filed [a separate issue](https://github.com/rust-lang/rust/issues/57415) for that, though.
Rollup merge of #57400 - tspiteri:source-serif-pro-it, r=GuillaumeGomez
Rustdoc: update Source Serif Pro and replace Heuristica italic
When Source Serif Pro was used to replace Heuristica in #15530, the italic variant was not ready yet, but now it is. This PR updates the Source Serif Pro font files to the [latest release](https://github.com/adobe-fonts/source-serif-pro/releases/tag/2.007R-ro%2F1.007R-it) which includes an italic variant, and replaces Heuristica italic with Source Serif Pro italic.
Rollup merge of #57368 - petrhosek:cmake-compiler-launcher, r=alexcrichton
Use CMAKE_{C,CXX}_COMPILER_LAUNCHER for ccache
CMake 3.4 and newer which is the required minimum version for LLVM
supports CMAKE_{C,CXX}_COMPILER_LAUNCHER for settting the compiler
launcher such as ccache which doesn't require shifting arguments.
Rollup merge of #57175 - oli-obk:const_let_stabilization, r=nikomatsakis
Stabilize `let` bindings and destructuring in constants and const fn
r? @Centril
This PR stabilizes the following features in constants and `const` functions:
* irrefutable destructuring patterns (e.g. `const fn foo((x, y): (u8, u8)) { ... }`)
* `let` bindings (e.g. `let x = 1;`)
* mutable `let` bindings (e.g. `let mut x = 1;`)
* assignment (e.g. `x = y`) and assignment operator (e.g. `x += y`) expressions, even where the assignment target is a projection (e.g. a struct field or index operation like `x[3] = 42`)
* expression statements (e.g. `3;`)
This PR does explicitly *not* stabilize:
* mutable references (i.e. `&mut T`)
* dereferencing mutable references
* refutable patterns (e.g. `Some(x)`)
* operations on `UnsafeCell` types (as that would need raw pointers and mutable references and such, not because it is explicitly forbidden. We can't explicitly forbid it as such values are OK as long as they aren't mutated.)
* We are not stabilizing `let` bindings in constants that use `&&` and `||` short circuiting operations. These are treated as `&` and `|` inside `const` and `static` items right now. If we stopped treating them as `&` and `|` after stabilizing `let` bindings, we'd break code like `let mut x = false; false && { x = true; false };`. So to use `let` bindings in constants you need to change `&&` and `||` to `&` and `|` respectively.
Rollup merge of #57042 - pnkfelix:issue-57038-sidestep-ice-in-fieldplacement-count, r=michaelwoerister
Don't call `FieldPlacement::count` when count is too large
Sidestep ICE in `FieldPlacement::count` by not calling it when count will not fit in host's usize.
(I briefly played with trying to fix this by changing `FieldPlacement::count` to return a `u64`. However, based on how `FieldPlacement` is used, it seems like this would be a largely pointless pursuit... I'm open to counter-arguments, however.)
Rollup merge of #56906 - blitzerr:master, r=nikomatsakis
Issue #56905
Adding a map to TypeckTables to get the list of all the Upvars
given a closureID. This is help us get rid of the recurring
pattern in the codebase of iterating over the free vars
using with_freevars.
bors [Thu, 10 Jan 2019 21:31:34 +0000 (21:31 +0000)]
Auto merge of #57484 - alexcrichton:fix-nightlies, r=Mark-Simulacru
Integrate miri into build-manifest
This fixes a mistake where miri was accidentally left out of the
build-manifest parsing, meaning that today's nightly generated a
manifest with invalid urls!
Björn Steinbrink [Thu, 10 Jan 2019 18:28:42 +0000 (19:28 +0100)]
Add a fast path for identical regions in lub_concrete_regions
In functions with lots of region constraint, if the fixed point
iteration converges only slowly, a lot of the var/var constraints will
have equal regions most of the time. Yet, we still perform the LUB
calculation and try to intern the result. Especially the latter incurs
quite some overhead.
This reduces the take taken by the item bodies checking pass for the
unicode_normalization crate by about 75%.
Once a region has been expanded to cover a fixed region, a corresponding
RegSubVar constraint won't have any effect on the expansion anymore, the
same is true for constraints where the variable on the RHS has already
reached static scope. By removing those constraints from the set that
we're iterating over, we remove a lot of needless overhead in case of
slow convergences (i.e. lots of iterations).
For the unicode_normalization crate, this about cuts the time required
for item_bodies checking in half.
Alex Crichton [Thu, 10 Jan 2019 01:14:11 +0000 (17:14 -0800)]
Integrate miri into build-manifest
This fixes a mistake where miri was accidentally left out of the
build-manifest parsing, meaning that today's nightly generated a
manifest with invalid urls!
Alex Crichton [Wed, 9 Jan 2019 17:35:09 +0000 (09:35 -0800)]
std: Render large exit codes as hex on Windows
On Windows process exit codes are never signals but rather always 32-bit
integers. Most faults like segfaults and such end up having large
integers used to represent them, like STATUS_ACCESS_VIOLATION being
0xC0000005. Currently, however, when an `ExitStatus` is printed this
ends up getting rendered as 3221225477 which is somewhat more difficult
to debug.
This commit adds a branch in `Display for ExitStatus` on Windows which
handles exit statuses where the high bit is set and prints those exit
statuses as hex instead of with decimals. This will hopefully preserve
the current display for small exit statuses (like `exit code: 22`), but
assist in quickly debugging segfaults/access violations/etc. I've
found at least that the hex codes are easier to search for than decimal.
I wasn't able to find any official documentation saying that all system
exit codes have the high bit set, but I figure it's a good enough
heuristic for now.
We have the right ID when looking for NodeId(31) and try with NodeId(32) (which
is the right thing to look for) from get_path_data, but not for the segments
that we write from `write_sub_paths_truncated`.
Basically `process_path` takes an id which is always the parent, and that we
fall back to in `get_path_data()`, so we get the right result for the last path
segment, but not for the other segments that get written to from
`write_sub_paths_truncated`.
I think we can stop passing the explicit id around to `get_path_data` now, will
consider sending that as a followup.