Aaron Hill [Mon, 21 Dec 2020 02:07:13 +0000 (21:07 -0500)]
Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv`
Fixes #80233
We already have logic in `evaluate_predicates` that tries to add
unimplemented predicates to our `ParamEnv`. Trying to add a predicate
that already holds can lead to errors later on, since projection
will prefer trait candidates from the `ParamEnv` to predicates from an
impl.
bors [Sun, 20 Dec 2020 16:36:23 +0000 (16:36 +0000)]
Auto merge of #74699 - notriddle:fd-non-negative, r=m-ou-se
Mark `-1` as an available niche for file descriptors
Based on discussion from <https://internals.rust-lang.org/t/can-the-standard-library-shrink-option-file/12768>, the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen, particularly on Linux, but would not necessarily be portable.
This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the "upper" bound, which is actually -1, to be expressed in two's complement.
bors [Sun, 20 Dec 2020 13:47:23 +0000 (13:47 +0000)]
Auto merge of #80213 - jryans:bootstrap-skip-dsymutil, r=nagisa
Skip `dsymutil` by default for compiler bootstrap
`dsymutil` adds time to builds on Apple platforms for no clear benefit, and also makes it more difficult for debuggers to find debug info (which `@pnkfelix` highlighted on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/does.20lldb.20%28or.20gdb%29.20work.20on.20rustc.20on.20Mac.3F/near/220482092)). The compiler currently defaults to running `dsymutil` to preserve its historical default, but when compiling the compiler itself, we skip it by default since we know it's safe to do so in that case.
This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090.
I believe this can unblock stabilization of or_patterns.
J. Ryan Stinnett [Sun, 20 Dec 2020 02:49:18 +0000 (02:49 +0000)]
Skip `dsymutil` by default for compiler bootstrap
`dsymutil` adds time to builds on Apple platforms for no clear benefit, and also
makes it more difficult for debuggers to find debug info. The compiler currently
defaults to running `dsymutil` to preserve its historical default, but when
compiling the compiler itself, we skip it by default since we know it's safe to
do so in that case.
bors [Sun, 20 Dec 2020 00:50:46 +0000 (00:50 +0000)]
Auto merge of #79635 - lcnr:const-eval-idk, r=oli-obk
const_evaluatable_checked: fix occurs check
fixes #79615
this is kind of a hack because we use `TypeRelation` for both the `Generalizer` and the `ConstInferUnifier` but i am not sure if there is a useful way to disentangle this without unnecessarily duplicating some code.
The error in the added test is kind of unavoidable until we erase the unused substs of `ConstKind::Unevaluated`. We talked a bit about this in the cg lazy norm meeting (https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/lazy_normalization_consts)
bors [Sat, 19 Dec 2020 21:57:38 +0000 (21:57 +0000)]
Auto merge of #79473 - m-ou-se:clamp-in-core, r=m-ou-se
Move {f32,f64}::clamp to core.
`clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`), the versions for the `f32` and `f64` primitives were added in `std` (together with `floor`, `sin`, etc.), not in `core` (together with `min`, `max`, `from_bits`, etc.).
This change moves them to `core`, such that `clamp` on floats is available in `no_std` programs as well.
bors [Sat, 19 Dec 2020 19:14:04 +0000 (19:14 +0000)]
Auto merge of #80104 - Nadrieril:usefulness-merging, r=varkor
Improve and fix diagnostics of exhaustiveness checking
Primarily, this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics:
```rust
match &[][..] {
[true] => {}
[true // detected as unreachable but that's not true
| false, ..] => {}
_ => {}
}
match (true, None) {
(true, Some(_)) => {}
(false, Some(true)) => {}
(true | false, None | Some(true // should be detected as unreachable
| false)) => {}
}
```
I did not measure any perf impact. However, I suspect that [`616ba9f`](https://github.com/rust-lang/rust/pull/80104/commits/616ba9f9f7f5845777a36e1a41a515e6c33a8776) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed.
EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x)
## Motivation
The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec, and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September, after the necessary const integer arithmetic was stabilized.
There is currently a PR open (#78802) to change the internal representation of `IpAddr{4,6}` from `libc` types to a byte array. This does not have any impact on the constness of the methods.
## Implementation
Most of the stabilizations are straightforward, with the exception of `Ipv6Addr::segments`, which uses the unstable feature `const_fn_transmute`. The code could be rewritten to equivalent stable code, but this leads to worse code generation (#75085).
This is why `segments` gets marked with `#[rustc_allow_const_fn_unstable(const_fn_transmute)]`, like the already const-stable `Ipv6Addr::new`, the justification being that a const-stable alternative implementation exists https://github.com/rust-lang/rust/pull/76206#issuecomment-685044184.
## Future posibilities
This PR const-stabilizes all currently stable ip methods, however there are also a number of unstable methods under the `ip` feature (#27709). These methods are already unstable const. There is a PR open (#76098) to stabilize those methods, which could include const-stabilization. However, stabilizing those methods as const is dependent on `Ipv4Addr::octets` and `Ipv6Addr::segments` (covered by this PR).
bors [Sat, 19 Dec 2020 07:23:41 +0000 (07:23 +0000)]
Auto merge of #80180 - JohnTitor:rollup-a31s996, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #78083 (Stabilize or_insert_with_key)
- #79211 (Add the "async" and "promise" doc aliases to `core::future::Future`)
- #79612 (Switch some links in compiler/ to intra-doc links)
- #80068 (Add `&mut` as an alias for 'reference' primitive)
- #80129 (docs: Edit rustc_ast::token::Token)
- #80133 (Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhere)
- #80155 (Fix typo)
Yuki Okushi [Sat, 19 Dec 2020 06:16:01 +0000 (15:16 +0900)]
Rollup merge of #79211 - yoshuawuyts:future-doc-alias, r=Mark-Simulacrum
Add the "async" and "promise" doc aliases to `core::future::Future`
Adds the "async" and "promise" doc aliases to `core::future::Future`. This enables people who search for "async" or "promise" to find `Future`, which is Rust's core primitive for async programming. Thanks!
Yuki Okushi [Sat, 19 Dec 2020 06:15:57 +0000 (15:15 +0900)]
Rollup merge of #78083 - ChaiTRex:master, r=m-ou-se
Stabilize or_insert_with_key
Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant.
The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)`, avoiding the need to copy or clone the key.
Nadrieril [Thu, 17 Dec 2020 01:56:22 +0000 (01:56 +0000)]
Unify the two kinds of usefulness merging
This is elegant but a bit of a perf gamble. That said, or-patterns
rarely have many branches and it's easy to optimize or revert if we ever
need to. In the meantime simpler code is worth it.
Ralf Jung [Fri, 18 Dec 2020 15:22:07 +0000 (16:22 +0100)]
Rollup merge of #80130 - pierwill:patch-7, r=oli-obk
docs: Edit rustc_span::symbol::Symbol method
Edit wording of the doc comment for [rustc_span::symbol::Symbol::can_be_raw](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/symbol/struct.Symbol.html#method.can_be_raw) to match related methods.
bors [Fri, 18 Dec 2020 08:44:50 +0000 (08:44 +0000)]
Auto merge of #80090 - jyn514:tcx-in-render, r=GuillaumeGomez
Pass a `TyCtxt` through to `FormatRender`
This is the next step after https://github.com/rust-lang/rust/pull/79957 for https://github.com/rust-lang/rust/issues/76382. Eventually I plan to use this to remove `stability`, `const_stability`, and `deprecation` from `Item`, but that needs more extensive changes (in particular, https://github.com/rust-lang/rust/pull/75355 or something like it).
This has no actual changes to behavior, it's just moving types around.
bors [Fri, 18 Dec 2020 03:01:14 +0000 (03:01 +0000)]
Auto merge of #80036 - sivadeilra:syms_no_macro, r=petrochenkov
Stop using intermediate macros in definition of symbols
Currently, the rustc_macros::symbols macro generates two
`macro_rules!` macros as its output. These two macros are
used in rustc_span/src/symbol.rs.
This means that each Symbol that we define is represented
in the AST of rustc_symbols twice: once in the definition
of the `define_symbols!` macro (similarly for the
`keywords! macro), and once in the rustc_span::symbols
definition.
That would be OK if there were only a handful of symbols,
but currently we define over 1100 symbols. The definition
of the `define_symbols!` macro contains the expanded definition
of each symbol, so that's a lot of AST storage wasted on a
macro that is used exactly once.
This commit removes the `define_symbols` macro, and simply
allows the proc macro to directly generate the
`rustc_symbols::symbol::sym` module.
The benefit is mainly in reducing memory wasted during
compilation of rustc itself. It should also reduce memory used
by Rust Analyzer.
This commit also reduces the size of the AST for symbol
definitions, by moving two `#[allow(...)]` attributes from
the symbol constants to the `sym` module. This eliminates 2200+
attribute nodes.
This commit also eliminates the need for the `digits_array`
constant. There's no need to store an array of Symbol values
for digits. We can simply define a constant of the base value,
and add to that base value.
I left the `sym::integer` function in rustc_span/src/symbol.rs
instead of moving it into rustc_macros/src/symbols.rs for two
reasons. First, because it's human-written code; it doesn't need
to be generated by the proc-macro. Second, because I didn't want
the `#[allow(...)]` attributes that I moved to the `sym` module
scope to apply to this function. The `sym` module re-exports the
`integer` function from its parent module.
bors [Fri, 18 Dec 2020 00:08:30 +0000 (00:08 +0000)]
Auto merge of #80138 - Dylan-DPC:rollup-qamsfyh, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #78164 (Prefer regions with an `external_name` in `approx_universal_upper_bound`)
- #80003 (Fix overflow when converting ZST Vec to VecDeque)
- #80023 (Enhance error message when misspelled label to value in break expression)
- #80046 (Add more documentation to `Diagnostic` and `DiagnosticBuilder`)
- #80109 (Remove redundant and unreliable coverage test results)
Dylan DPC [Thu, 17 Dec 2020 23:30:21 +0000 (00:30 +0100)]
Rollup merge of #80109 - richkadel:llvm-coverage-counters-2.3.0, r=tmandry
Remove redundant and unreliable coverage test results
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
r? `@tmandry`
Tyler - as we discussed offline...
FYI: `@wesleywiser` `@Swatinem`
Arpad, depending on the timing of this PR, it may not affect you, but I'm removing some of the files that produce slightly different results on Windows as they really aren't necessary to validate coverage results.
Dylan DPC [Thu, 17 Dec 2020 23:30:11 +0000 (00:30 +0100)]
Rollup merge of #80003 - Stupremee:fix-zst-vecdeque-conversion-panic, r=dtolnay
Fix overflow when converting ZST Vec to VecDeque
```rust
let v = vec![(); 100];
let queue = VecDeque::from(v);
println!("{:?}", queue);
```
This code will currently panic with a capacity overflow.
This PR resolves this issue and makes the code run fine.
Dylan DPC [Thu, 17 Dec 2020 23:30:09 +0000 (00:30 +0100)]
Rollup merge of #78164 - Aaron1011:fix/async-region-name, r=tmandry
Prefer regions with an `external_name` in `approx_universal_upper_bound`
Fixes #75785
When displaying a MIR borrowcheck error, we may need to find an upper
bound for a region, which gives us a region to point to in the error
message. However, a region might outlive multiple distinct universal
regions, in which case the only upper bound is 'static
To try to display a meaningful error message, we compute an
'approximate' upper bound by picking one of the universal regions.
Currently, we pick the region with the lowest index - however, this
caused us to produce a suboptimal error message in issue #75785
This PR `approx_universal_upper_bound` to prefer regions with an
`external_name`. This causes us to prefer regions from function
arguments/upvars, which seems to lead to a nicer error message in some
cases.
Arlie Davis [Mon, 14 Dec 2020 19:34:55 +0000 (11:34 -0800)]
Stop using intermediate macros in definition of symbols
Currently, the rustc_macros::symbols macro generates two
`macro_rules!` macros as its output. These two macros are
used in rustc_span/src/symbol.rs.
This means that each Symbol that we define is represented
in the AST of rustc_symbols twice: once in the definition
of the `define_symbols!` macro (similarly for the
`keywords! macro), and once in the rustc_span::symbols
definition.
That would be OK if there were only a handful of symbols,
but currently we define over 1100 symbols. The definition
of the `define_symbols!` macro contains the expanded definition
of each symbol, so that's a lot of AST storage wasted on a
macro that is used exactly once.
This commit removes the `define_symbols` macro, and simply
allows the proc macro to directly generate the
`rustc_symbols::symbol::sym` module.
The benefit is mainly in reducing memory wasted during
compilation of rustc itself. It should also reduce memory used
by Rust Analyzer.
This commit also reduces the size of the AST for symbol
definitions, by moving two `#[allow(...)]` attributes from
the symbol constants to the `sym` module. This eliminates 2200+
attribute nodes.
This commit also eliminates the need for the `digits_array`
constant. There's no need to store an array of Symbol values
for digits. We can simply define a constant of the base value,
and add to that base value.
bors [Thu, 17 Dec 2020 21:13:51 +0000 (21:13 +0000)]
Auto merge of #80122 - davidtwco:revert-76030, r=oli-obk
Revert "cg_llvm: `fewer_names` in `uncached_llvm_type`"
Fixes #76213 and fixes #79564.
This PR temporarily reverts commit fa01ce802f1b403a2140fd945b43af86ec3998a1 from #76030 to until the root issue can be resolved. Requested [in t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.20meeting.5D.202020-12-17.20.2354818/near/220261541).
*Note*: I was seeing some failing debuginfo-gdb tests locally but I wasn't sure if they were spurious.
Aaron Hill [Tue, 20 Oct 2020 20:31:54 +0000 (16:31 -0400)]
Prefer regions with an `external_name` in `approx_universal_upper_bound`
Fixes #75785
When displaying a MIR borrowcheck error, we may need to find an upper
bound for a region, which gives us a region to point to in the error
message. However, a region might outlive multiple distinct universal
regions, in which case the only upper bound is 'static
To try to display a meaningful error message, we compute an
'approximate' upper bound by picking one of the universal regions.
Currently, we pick the region with the lowest index - however, this
caused us to produce a suboptimal error message in issue #75785
This PR `approx_universal_upper_bound` to prefer regions with an
`external_name`. This causes us to prefer regions from function
arguments/upvars, which seems to lead to a nicer error message in some
cases.
bors [Thu, 17 Dec 2020 14:52:50 +0000 (14:52 +0000)]
Auto merge of #80113 - davidtwco:issue-80086-ci-llvm-stamp, r=Mark-Simulacrum
bootstrap: update ci-llvm stamp after #80087
Fixes #80086.
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This PR updates the ci-llvm stamp to resolve that problem.
bors [Thu, 17 Dec 2020 12:02:29 +0000 (12:02 +0000)]
Auto merge of #80114 - GuillaumeGomez:rollup-gszr5kn, r=GuillaumeGomez
Rollup of 5 pull requests
Successful merges:
- #80006 (BTreeMap: more expressive local variables in merge)
- #80022 (BTreeSet: simplify implementation of pop_first/pop_last)
- #80035 (Optimization for bool's PartialOrd impl)
- #80040 (Always run intrinsics lowering pass)
- #80047 (Use more symbols in rustdoc)
Guillaume Gomez [Thu, 17 Dec 2020 10:36:54 +0000 (11:36 +0100)]
Rollup merge of #80047 - jyn514:more-symbols, r=GuillaumeGomez
Use more symbols in rustdoc
Builds on https://github.com/rust-lang/rust/pull/80044 and should not be merged before.
I want to test if this is actually faster before merging it, there was a lot of `to_string()` calls so I'm not sure it will actually help. That means I have to wait for 80044 to get merged before running perf.
Guillaume Gomez [Thu, 17 Dec 2020 10:36:52 +0000 (11:36 +0100)]
Rollup merge of #80040 - tmiasko:always-lower-intrinsics, r=Dylan-DPC
Always run intrinsics lowering pass
Move intrinsics lowering pass from the optimization phase (where it
would not run if -Zmir-opt-level=0), to the drop lowering phase where it
runs unconditionally.
The implementation of those intrinsics in code generation and
interpreter is unnecessary. Remove it.
David Wood [Thu, 17 Dec 2020 10:29:58 +0000 (10:29 +0000)]
bootstrap: update ci-llvm stamp after #80087
Unfortunately, #80087 forgot to update the ci-llvm stamp, so the updated
ci-llvm tarball with `llvm-dwp` wasn't downloaded by users. This commit
updates the ci-llvm stamp to resolve that problem.
Rich Kadel [Thu, 17 Dec 2020 06:07:40 +0000 (22:07 -0800)]
Remove redundant and unreliable coverage test results
The `coverage-reports` tests still generate counters and JSON reports
for inspection, but these files are no longer used in Makefile diffs, to
reduce complexity and confusion from unreliable or unexpected test
results, especially when maintaining them (i.e., generating `--bless`ed
results).
The associated `expected_` files for counters and JSON reports have been
removed, leaving only the files actually used for testing: the `llvm-cov
show` reports.
projects / rust.git / log