| Age | Commit message (Collapse) | Author | Lines |
|---|
|
proc_macro: Stay on the "use the cache" path more
Discovered in #50061 we're falling off the "happy path" of using a stringified
token stream more often than we should. This was due to the fact that a
user-written token like `0xf` is equality-different from the stringified token
of `15` (despite being semantically equivalent).
This patch updates the call to `eq_unspanned` with an even more awful solution,
`probably_equal_for_proc_macro`, which ignores the value of each token and
basically only compares the structure of the token stream, assuming that the AST
doesn't change just one token at a time.
While this is a step towards fixing #50061 there is still one regression
from #49154 which needs to be fixed.
|
|
Lazily evaluate EvalErrorKind::*.into() calls.
eval_context.rs calls `ok_or` in multiple places with an eagerly
evaluated `EvalErrorKind::*.into()` argument, which calls
EvalError::from(), which calls env::var("MIRI_BACKTRACE"), which
allocates a String. This code is hot enough for this to have a
measurable effect on some benchmarks.
This patch changes the `ok_or` calls into `ok_or_else`, thus avoiding
the evaluations when they're not needed. As a result, most of the
rustc-perf benchmarks get a measurable speedup, particularly the
shorter-running ones, where the improvement is as high as 6%.
Output from rustc-perf, comparing stage 2 builds with jemalloc disabled:
<details>
```
coercions
avg: -1.8% min: -6.0% max: -0.0%
helloworld-opt
avg: -3.7% min: -4.0% max: -3.4%
helloworld
avg: -3.7% min: -3.9% max: -3.5%
parser
avg: -3.5% min: -3.9% max: -3.1%
unify-linearly-opt
avg: -3.2% min: -3.8% max: -2.8%
unify-linearly
avg: -3.2% min: -3.7% max: -2.8%
parser-opt
avg: -3.2% min: -3.6% max: -2.8%
clap-rs
avg: -0.9% min: -3.6% max: 0.1%
encoding
avg: -1.9% min: -3.0% max: -1.2%
clap-rs-opt
avg: -0.8% min: -2.7% max: -0.1%
helloworld-check
avg: -1.9% min: -2.2% max: -1.7%
deeply-nested-check
avg: -1.4% min: -2.1% max: -0.9%
issue-46449-opt
avg: -0.7% min: -2.0% max: -0.3%
unify-linearly-check
avg: -1.5% min: -1.9% max: -1.2%
issue-46449
avg: -1.0% min: -1.8% max: -0.8%
deeply-nested-opt
avg: -0.7% min: -1.7% max: -0.2%
deeply-nested
avg: -1.0% min: -1.6% max: -0.6%
parser-check
avg: -1.3% min: -1.6% max: -0.8%
encoding-check
avg: -1.5% min: -1.6% max: -1.2%
tuple-stress
avg: -0.9% min: -1.5% max: 0.0%
tuple-stress-opt
avg: -1.0% min: -1.5% max: -0.3%
issue-46449-check
avg: -1.3% min: -1.4% max: -1.0%
encoding-opt
avg: -1.1% min: -1.2% max: -0.9%
regression-31157
avg: -0.7% min: -1.2% max: -0.2%
regression-31157-check
avg: -0.8% min: -1.2% max: -0.5%
futures-check
avg: -0.8% min: -1.2% max: -0.4%
unused-warnings-opt
avg: -1.0% min: -1.2% max: -0.9%
unused-warnings
avg: -1.0% min: -1.1% max: -0.9%
coercions-opt
avg: -0.6% min: -1.0% max: -0.2%
inflate-check
avg: -0.4% min: -0.9% max: -0.1%
regex-check
avg: -0.8% min: -0.9% max: -0.5%
piston-image-check
avg: -0.8% min: -0.9% max: -0.8%
deep-vector
avg: -0.3% min: -0.9% max: 0.1%
futures
avg: -0.5% min: -0.8% max: -0.2%
futures-opt
avg: -0.5% min: -0.7% max: -0.1%
html5ever
avg: -0.6% min: -0.7% max: -0.4%
tokio-webpush-simple-check
avg: -0.2% min: -0.7% max: 0.1%
piston-image-opt
avg: -0.3% min: -0.7% max: -0.1%
regex
avg: -0.4% min: -0.7% max: -0.1%
piston-image
avg: -0.4% min: -0.7% max: -0.2%
regex-opt
avg: -0.3% min: -0.7% max: 0.1%
tokio-webpush-simple-opt
avg: -0.2% min: -0.6% max: 0.0%
coercions-check
avg: -0.3% min: -0.6% max: -0.1%
hyper
avg: -0.4% min: -0.6% max: -0.2%
syn-opt
avg: -0.3% min: -0.6% max: -0.0%
hyper-check
avg: -0.5% min: -0.6% max: -0.3%
syn-check
avg: -0.4% min: -0.5% max: -0.2%
hyper-opt
avg: -0.3% min: -0.5% max: -0.1%
html5ever-opt
avg: -0.3% min: -0.5% max: -0.2%
syn
avg: -0.2% min: -0.4% max: -0.1%
deep-vector-opt
avg: -0.2% min: -0.4% max: 0.1%
tokio-webpush-simple
avg: -0.2% min: -0.4% max: -0.1%
inflate
avg: -0.2% min: -0.4% max: -0.1%
inflate-opt
avg: -0.2% min: -0.4% max: -0.0%
regression-31157-opt
avg: -0.1% min: -0.4% max: 0.0%
html5ever-check
avg: -0.3% min: -0.4% max: -0.2%
unused-warnings-check
avg: -0.2% min: -0.3% max: -0.2%
script-servo-check
avg: -0.1% min: -0.3% max: 0.0%
crates.io-check
avg: -0.2% min: -0.3% max: -0.0%
script-servo
avg: -0.1% min: -0.2% max: 0.0%
clap-rs-check
avg: 0.0% min: -0.1% max: 0.2%
deep-vector-check
avg: -0.0% min: -0.2% max: 0.2%
tuple-stress-check
avg: -0.1% min: -0.2% max: 0.0%
crates.io-opt
avg: -0.1% min: -0.2% max: 0.0%
crates.io
avg: -0.1% min: -0.2% max: -0.0%
script-servo-opt
avg: -0.0% min: -0.1% max: 0.0%
```
</details>
|
|
atomic: remove 'Atomic*' from Debug output
For the same reason that we don't show `Vec { data: [0, 1, 2, 3] }`, but just the array, the `AtomicUsize(1000)` is noisy, and seeing just `1000` is likely better.
|
|
Update clippy
r? @Manishearth
|
|
Add src/test/ui regression testing for NLL
This PR changes `x.py test` so that when you are running the `ui` test suite, it will also always run `compiletest` in the new `--compare-mode=nll`, which just double-checks that when running under the experimental NLL mode, the output matches the `<source-name>.nll.stderr` file, if present.
In order to reduce the chance of a developer revolt in response to this change, this PR also includes some changes to make the `--compare-mode=nll` more user-friendly:
1. It now generates nll-specific .stamp files, and uses them (so that repeated runs can reuse previously cached results).
2. Each line of terminal output distinguishes whether we are running under `--compare-mode=nll` by printing with the prefix `[ui (nll)]` instead of just the prefix `[ui]`.
Subtask of rust-lang/rust#48879
|
|
Sign extend constants in range patterns
fixes #49940
r? @Mark-Simulacrum
|
|
|
|
|
|
Add rustc_trans to x.py check
r? @Mark-Simulacrum
I looked at `bootstrap/compile.rs` and `bootstrap/check.rs` to try to work out which steps were appropriate, but I'm sure I've overlooked some details here, so it's worth checking carefully I've got all the steps right (e.g. I wasn't sure whether we want to build LLVM if necessary with `x.py check`, though I thought it was probably better to than to not).
From a quick test, it seems to be working, though.
|
|
Update Rhs on ShlAssign to default to Self
This matches the behavior on ShrAssign and all other *Assign operations.
|
|
Discovered in #50061 we're falling off the "happy path" of using a stringified
token stream more often than we should. This was due to the fact that a
user-written token like `0xf` is equality-different from the stringified token
of `15` (despite being semantically equivalent).
This patch updates the call to `eq_unspanned` with an even more awful solution,
`probably_equal_for_proc_macro`, which ignores the value of each token and
basically only compares the structure of the token stream, assuming that the AST
doesn't change just one token at a time.
While this is a step towards fixing #50061 there is still one regression
from #49154 which needs to be fixed.
|
|
rustc_trans: also check dominators for SSA values in mir::analyze
Fixes #50041
|
|
|
|
eval_context.rs calls `ok_or` in multiple places with an eagerly
evaluated `EvalErrorKind::*.into()` argument, which calls
EvalError::from(), which calls env::var("MIRI_BACKTRACE"), which
allocates a String. This code is hot enough for this to have a
measurable effect on some benchmarks.
This patch changes the `ok_or` calls into `ok_or_else`, thus avoiding
the evaluations when they're not needed. As a result, most of the
rustc-perf benchmarks get a measurable speedup, particularly the
shorter-running ones, where the improvement is as high as 6%.
|
|
Only emit save-analysis data for `cargo build` tasks
Previously, we were emittinng analysis data for all tasks, including `doc`. That meant we got two sets of save-analysis data, one from the normal build and one from the docs. That means indexing with the RLS took twice as long and made downloads larger and build times longer.
cc https://github.com/rust-lang-nursery/rls/issues/826
r? @Mark-Simulacrum
|
|
stabilize a bunch of minor api additions
besides `ptr::NonNull::cast` (which is 4 days away from end of FCP) all of these have been finished with FCP for a few weeks now with minimal issues raised
* Closes #41020
* Closes #42818
* Closes #44030
* Closes #44400
* Closes #46507
* Closes #47653
* Closes #46344
the following functions will be stabilized in 1.27:
* `[T]::rsplit`
* `[T]::rsplit_mut`
* `[T]::swap_with_slice`
* `ptr::swap_nonoverlapping`
* `NonNull::cast`
* `Duration::from_micros`
* `Duration::from_nanos`
* `Duration::subsec_millis`
* `Duration::subsec_micros`
* `HashMap::remove_entry`
|
|
Reorder injection of std to get better compilation error
Per #49851, reorder injection imports to get a better error message.
r? @oli-obk
|
|
Change the hashcounts in raw `Lit` variants from usize to u16.
This reduces the size of `Token` from 32 bytes to 24 bytes on 64-bit
platforms.
|
|
`foo.nll.stderr`
This allows easy revision of the update-references.sh script (included
here) so that it can update the expected output for nll rather than
stderr. It also reminds the rustc developer via the filename that they
are looking at output generated under comapre-mode=nll.
One could argue that there is still a problem with the strategy encoded here:
if we reach a scenario where a change to the compiler brings the output
under AST and NLL modes back into sync, this code will continue to still
generate output to distinct `foo.stderr` and `foo.nll.stderr` files, and
will continue to copy those two files back to corresponding distinct
files in the source tree, even if the *content* of the two files is now the
same.
* Arguably the "right thing" to do in that case is to remove the
`foo.nll.stderr` file entirely.
* However, I think the real answer is that we will probably want to
double-check such cases by hand anyway. We should be regularly
double-checking the diffs between `foo.stderr` and
`foo.nll.stderr`, and if we see a zero-diff case, then we should
evaluate whether that is correct, and if so, remove the file by
hand.)
* In any case, I think the default behavior encoded here (or at
least *intended* to be encoded here) is superior to the
alternative of *only* generating a `foo.nll.stderr` file if one
already existed in the source tree at the time that `compiletest`
was invoked (and otherwise unconditionally generating a
`foo.stderr` file, as was the behavior prior to this commit),
because that alternative is more likely to cause rustc developers
to overwrite a `foo.stderr` file with the stderr output from a
compare-mode=nll run, which will then break the *normal*
`compiletest` run and probably be much more confusing for the
average rustc developer.
|
|
nll-subminimal-causes` flag
This commit only applies the flag to the one test case,
ui/span/dropck_vec_cycle_checked.rs, that absolutely needs it. Without
the flag, that test takes an unknown amount of time (greater than 1
minute) to compile. But its possible that other tests would also
benefit from the flag, and we may want to make it the default (after
evaluating its impact on other tests).
In terms of its known impact on other tests, I have only evaluated the
ui tests, and the *only* ui test I have found that the flag impacts
(running under NLL mode, of course), is src/test/ui/nll/issue-31567.rs
In particular:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/nll/issue-31567.rs
error[E0597]: `*v.0` does not live long enough
--> ../src/test/ui/nll/issue-31567.rs:22:26
|
22 | let s_inner: &'a S = &*v.0; //~ ERROR `*v.0` does not live long enough
| ^^^^^ borrowed value does not live long enough
23 | &s_inner.0
24 | }
| - borrowed value only lives until here
|
note: borrowed value must be valid for the lifetime 'a as defined on the function body at 21:1...
--> ../src/test/ui/nll/issue-31567.rs:21:1
|
21 | fn get_dangling<'a>(v: VecWrapper<'a>) -> &'a u32 {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0597`.
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/nll/issue-31567.rs -Z nll-subminimal-causes
error[E0597]: `*v.0` does not live long enough
--> ../src/test/ui/nll/issue-31567.rs:22:26
|
22 | let s_inner: &'a S = &*v.0; //~ ERROR `*v.0` does not live long enough
| ^^^^^ borrowed value does not live long enough
23 | &s_inner.0
24 | }
| -
| |
| borrowed value only lives until here
| borrow later used here, when `v` is dropped
error: aborting due to previous error
For more information about this error, try `rustc --explain E0597`.
%
```
|
|
updating of cause map.
This seems to avoid poor scaling on src/test/ui/span/dropck_vec_cycle_checked.rs
|
|
`.stderr` files.
|
|
in messages.
|
|
current reality.
|
|
|
|
E.g. when running with `--compare-mode=nll`, then each test line will
look like e.g.:
```
test [ui (nll)] ui/issue-10969.rs ... ok
```
|
|
|
|
Properly handle ranges of signed enums using both extremums (fixes #49973)
Fixes #49973.
|
|
Fixes #50041
|
|
|
|
|
|
This deduplicates the LLVM building functionality from compile.rs and check.rs.
|
|
|
|
|
|
Make Handler more thread-safe
The use of `code_emitted` to suppress extended explanations is not thread safe. I'm not sure why we keep the documentation for errors outside `diagnostics.rs` anyway. It would be better to add a `teach` method to `DiagnosticsBuilder`, so instead of:
```
if self.tcx.sess.teach(&err.get_code().unwrap()) {
err.note("...");
}
```
we'd use `err.teach("...")`
cc @estebank
r? @michaelwoerister
|
|
Remove uses of Build across Builder steps
This is purely a code cleanup; there should be no functional changes.
r? @alexcrichton
|
|
Various rustfmt and commenting changes
These are factored out of #49320
There aren't actually any changes in functionality, just rustfmt and doccomments.
|
|
|
|
Improve query cycle error message
r? @michaelwoerister
|
|
Update Rustfmt
Fixes RLS and Rustfmt and enables a new nightly
r? @alexcrichton
|
|
|
|
Work around LLVM debuginfo problem in librustc_driver.
Works around a problem (https://github.com/rust-lang/rust/issues/48910) with global variable debuginfo generation for `rustc_driver::get_trans::LOAD` by applying `#[no_debug]` to it (which just disables debuginfo generation for that variable). This way we can build the compiler with debuginfo again.
Since the problem is also present in beta, this workaround might have to be backported.
r? @alexcrichton
|
|
Rollup of 4 pull requests
Successful merges:
- #49699 (Removed 'proc' from the reserved keywords list)
- #49966 (Multiple query search)
- #50013 (Remove no longer necessary comparison to Vec::splice.)
- #50032 (rustdoc: Don't include private paths in all.html)
Failed merges:
|
|
rustdoc: Don't include private paths in all.html
For example the `std` [`all.html`](https://doc.rust-lang.org/nightly/std/all.html) includes references to the `coresimd` module which is a private implementation detail.
r? @GuillaumeGomez
|
|
Remove no longer necessary comparison to Vec::splice.
`String::replace_range` was previously called `String::splice`, so this
note was necessary to differentiate it from the `Vec` method. Now that
it's renamed, this note no longer seems necessary.
|
|
Multiple query search
Part of #49757.
r? @QuietMisdreavus
|
|
Removed 'proc' from the reserved keywords list
Remove 'proc' from the reserved keywords list.
'proc' is a very useful identifier name for a lot of things. It's especially useful when dealing with processes, operating system internals, and kernel development.
|
|
|
|
|
|
|
