| Age | Commit message (Collapse) | Author | Lines |
|---|
|
https://github.com/rust-lang/rust/pull/92339#discussion_r792805289
|
|
Fix the unsoundness in the `early_otherwise_branch` mir opt pass
Closes #78496 .
This change is a significant rewrite of much of the pass. Exactly what it does is documented in the source file (with ascii art!), and all the changes that are made to the MIR that are not trivially sound are carefully documented. That being said, this is my first time touching MIR, so there are probably some invariants I did not know about that I broke.
This version of the optimization is also somewhat more flexible than the original; for example, we do not care how or where the value on which the parent is switching is computed. There is no requirement that any types be the same. This could be made even more flexible in the future by allowing a wider range of statements in the bodies of `BBC, BBD` (as long as they are all the same of course). This should be a good first step though.
Probably needs a perf run.
r? `@oli-obk` who reviewed things the last time this was touched
|
|
Fix ICE when parsing bad turbofish with lifetime argument
Generalize conditions where we suggest adding the turbofish operator, so we don't ICE during code like
```rust
fn foo() {
A<'a,>
}
```
but instead suggest adding a turbofish.
Fixes #93282
|
|
Add white-space: nowrap to links in the sidebar
We already have overflow: hidden on these links, but if there is a possibility to wrap, they will wrap. This happens in particular for trait implementations because the punctuation (`<>, `) introduces opportunities for breaks. That produces inconsistent UI. Fix it by forcing them not to wrap.
Demo: https://rustdoc.crud.net/jsha/sidebar-nowrap/std/string/struct.String.html
To see the effect, scroll down to the "Trait Implementations" portion of the sidebar and look at IndexMut. Compare vs:
https://doc.rust-lang.org/std/string/struct.String.html
https://doc.rust-lang.org/nightly/std/string/struct.String.html
r? `@camelid`
|
|
Remove deduplication of early lints
We already have a general mechanism for deduplicating reported
lints, so there's no need to have an additional one for early lints
specifically. This allows us to remove some `PartialEq` impls.
|
|
|
|
|
|
r=nikomatsakis
Implement stable overlap check considering negative traits
This PR implement the new disjointness rules for overlap check described in https://rust-lang.github.io/negative-impls-initiative/explainer/coherence-check.html#new-disjointness-rules
r? ``@nikomatsakis``
|
|
r=GuillaumeGomez
Fix inconsistency of local blanket impls
When a blanket impl is local, go through HIR instead of middle. This fixes inconsistencies with data detected during JSON generation.
Expected this change to take longer. I also tried doing the whole item through existing clean architecture, but it didn't work out trivially, and felt like it would have added more complexity than it removed.
Properly fixes #83718
|
|
Work around missing code coverage data causing llvm-cov failures
If we do not add code coverage instrumentation to the `Body` of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.
I've identified two main cases where we do not currently add code
coverage instrumentation to the `Body` of a function:
1. If the function has a single `BasicBlock` and it ends with a
`TerminatorKind::Unreachable`.
2. If the function is created using a proc macro of some kind.
For case 1, this is typically not important as this most often occurs as
a result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.
For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case
1) the skipped function coverage debug message is occasionally triggered
in large crate graphs by functions generated from a proc macro. This may
have something to do with weird spans being generated by the proc macro
but this is just a guess.
I think it's reasonable to land this change since currently, we fail to
generate *any* results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.
Fixes #93054 which occurs because of uncallable functions which shouldn't
have code coverage anyway.
I will open an issue for missing code coverage of proc macro generated
functions and leave a link here once I have a more minimal repro.
r? ``@tmandry``
cc ``@richkadel``
|
|
Move param count error emission to end of `check_argument_types`
The error emission here isn't exactly what is done in #92364, but replicating that is hard . The general move should make for a smaller diff.
Also included the `(usize, Ty, Ty)` to -> `Option<(Ty, Ty)>` commit.
r? ``@estebank``
|
|
Properly track `DepNode`s in trait evaluation provisional cache
Fixes #92987
During evaluation of an auto trait predicate, we may encounter a cycle.
This causes us to store the evaluation result in a special 'provisional
cache;. If we later end up determining that the type can legitimately
implement the auto trait despite the cycle, we remove the entry from
the provisional cache, and insert it into the evaluation cache.
Additionally, trait evaluation creates a special anonymous `DepNode`.
All queries invoked during the predicate evaluation are added as
outoging dependency edges from the `DepNode`. This `DepNode` is then
store in the evaluation cache - if a different query ends up reading
from the cache entry, it will also perform a read of the stored
`DepNode`. As a result, the cached evaluation will still end up
(transitively) incurring all of the same dependencies that it would
if it actually performed the uncached evaluation (e.g. a call to
`type_of` to determine constituent types).
Previously, we did not correctly handle the interaction between the
provisional cache and the created `DepNode`. Storing an evaluation
result in the provisional cache would cause us to lose the `DepNode`
created during the evaluation. If we later moved the entry from the
provisional cache to the evaluation cache, we would use the `DepNode`
associated with the evaluation that caused us to 'complete' the cycle,
not the evaluatoon where we first discovered the cycle. As a result,
future reads from the evaluation cache would miss some incremental
compilation dependencies that would have otherwise been added if the
evaluation was *not* cached.
Under the right circumstances, this could lead to us trying to force
a query with a no-longer-existing `DefPathHash`, since we were missing
the (red) dependency edge that would have caused us to bail out before
attempting forcing.
This commit makes the provisional cache store the `DepNode` create
during the provisional evaluation. When we move an entry from the
provisional cache to the evaluation cache, we create a *new* `DepNode`
that has dependencies going to *both* of the evaluation `DepNodes` we
have available. This ensures that cached reads will incur all of
the necessary dependency edges.
|
|
We already have overflow: hidden on these links, but if there is a
possibility to wrap, they will wrap. This happens in particular for trait
implementations because the punctuation (`<>, `) introduces opportunities
for breaks. That produces inconsistent UI. Fix it by forcing them not to
wrap.
|
|
Use `indexmap` to avoid sorting `LocalDefId`s
See discussion in https://github.com/rust-lang/rust/pull/90408#discussion_r745935459.
Related to work on https://github.com/rust-lang/rust/issues/90317.
|
|
Rollup of 8 pull requests
Successful merges:
- #92513 (std: Implement try_reserve and try_reserve_exact on PathBuf)
- #93152 (Fix STD compilation for the ESP-IDF target (regression from CVE-2022-21658))
- #93186 (Fix link to CVE-2022-21658)
- #93188 (rustdoc: fix bump down typing search on Safari)
- #93212 (Remove unneeded cursor pointer rule on mobile sidebar)
- #93231 (adjust sidebar link brightness)
- #93241 (Fix brief appearance of rust logo in the sidebar)
- #93253 (Update theme on pageshow event)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
adjust sidebar link brightness
Fairly simple change. I've taken the existing link colour and main body background colours, and made sure that the sidebar+link contrast is the same.
ayu:
- [main content contrast](https://colourcontrast.cc/0f1419/39afd7) - 7.31
- [current sidebar contrast](https://colourcontrast.cc/14191f/39afd7) - 6.97
- [new sidebar contrast](https://colourcontrast.cc/14191f/56b1d9) - 7.30
dark:
- [main content contrast](https://colourcontrast.cc/353535/d2991d) - 4.86
- [current sidebar contrast](https://colourcontrast.cc/14191f/d2991d) - 3.19
- [new sidebar contrast](https://colourcontrast.cc/14191f/fdbf35) - 4.87
light:
- [main content contrast](https://colourcontrast.cc/ffffff/3873ad) - 4.97
- [current sidebar contrast](https://colourcontrast.cc/f5f5f5/3873ad) - 4.56
- [new sidebar contrast](https://colourcontrast.cc/f5f5f5/356da4) - 4.97
|
|
r=the8472
Revert "Do not hash leading zero bytes of i64 numbers in Sip128 hasher"
Reverts rust-lang/rust#92103. It had a (in retrospect, obvious) correctness problem where changing the order of two adjacent values would produce identical hashes, which is problematic in stable hashing (see [this comment](https://github.com/rust-lang/rust/pull/92103#issuecomment-1014625442)).
I'll try to send the PR again with a fix for this issue.
r? `@the8472`
|
|
|
|
Check `const Drop` impls considering `~const` Bounds
This PR adds logic to trait selection to account for `~const` bounds in custom `impl const Drop` for types, elaborates the `const Drop` check in `rustc_const_eval` to check those bounds, and steals some drop linting fixes from #92922, thanks `@DrMeepster.`
r? `@fee1-dead` `@oli-obk` <sup>(edit: guess I can't request review from two people, lol)</sup>
since each of you wrote and reviewed #88558, respectively.
Since the logic here is more complicated than what existed, it's possible that this is a perf regression. But it works correctly with tests, and that makes me happy.
Fixes #92881
|
|
We already have a general mechanism for deduplicating reported
lints, so there's no need to have an additional one for early lints
specifically. This allows us to remove some `PartialEq` impls.
|
|
|
|
Liberate late bound regions when collecting GAT substs in wfcheck
The issue here is that the [`GATSubstCollector`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_typeck/src/check/wfcheck.rs#L604) does not currently do anything wrt `Binder`s, so the GAT substs it copies out have escaping late bound regions when it walks through types like `for<'x> fn() -> Self::Gat<'x>`.
I made that visitor call `liberate_late_bound_regions`, not sure if that's the right thing here or we need to do something else to replace these bound vars with placeholders. I'm not familiar with other code doing anything similar.. But the issue is indeed no longer ICEing.
Fixes #92954
r? `@jackh726`
since you last touched this code, feel free to reassign
|
|
Normalize field access types during borrowck
I think a normalize was just left out here, since we normalize analogously throughout this file.
Fixes #93141
|
|
Add preliminary support for inline assembly for msp430.
The `llvm_asm` macro was removed recently, and the MSP430 backend relies on inline assembly to build useful embedded apps. I conveniently "found" time to implement basic support for the new inline `asm` macro syntax with the help of `@Amanieu` :D.
In addition to tests in the compiler, I have tested this locally against deployed MSP430 code and have not found any noticeable differences in firmware operation or `objdump` disassemblies between the old `llvm_asm` and the new `asm` syntax.
|
|
Fix `let_chains` and `if_let_guard` feature flags
Fixes https://github.com/rust-lang/rust/issues/93150
cc #53667
|
|
|
|
Make `Decodable` and `Decoder` infallible.
`Decoder` has two impls:
- opaque: this impl is already partly infallible, i.e. in some places it
currently panics on failure (e.g. if the input is too short, or on a
bad `Result` discriminant), and in some places it returns an error
(e.g. on a bad `Option` discriminant). The number of places where
either happens is surprisingly small, just because the binary
representation has very little redundancy and a lot of input reading
can occur even on malformed data.
- json: this impl is fully fallible, but it's only used (a) for the
`.rlink` file production, and there's a `FIXME` comment suggesting it
should change to a binary format, and (b) in a few tests in
non-fundamental ways. Indeed #85993 is open to remove it entirely.
And the top-level places in the compiler that call into decoding just
abort on error anyway. So the fallibility is providing little value, and
getting rid of it leads to some non-trivial performance improvements.
Much of this PR is pretty boring and mechanical. Some notes about
a few interesting parts:
- The commit removes `Decoder::{Error,error}`.
- `InternIteratorElement::intern_with`: the impl for `T` now has the same
optimization for small counts that the impl for `Result<T, E>` has,
because it's now much hotter.
- Decodable impls for SmallVec, LinkedList, VecDeque now all use
`collect`, which is nice; the one for `Vec` uses unsafe code, because
that gave better perf on some benchmarks.
r? `@bjorn3`
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #90666 (Stabilize arc_new_cyclic)
- #91122 (impl Not for !)
- #93068 (Fix spacing for `·` between stability and source)
- #93103 (Tweak `expr.await` desugaring `Span`)
- #93113 (Unify search input and buttons size)
- #93168 (update uclibc instructions for new toolchain, add link from platforms doc)
- #93185 (rustdoc: Make some `pub` items crate-private)
- #93196 (Remove dead code from build_helper)
Failed merges:
- #93188 (rustdoc: fix bump down typing search on Safari)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Update `indexmap` to 1.8.0.
Bless test
|
|
|
|
Disable drop range tracking in generators
Generator drop tracking caused an ICE for generators involving the Never type (Issue #93161). Since this breaks a test case with miri, we temporarily disable drop tracking so miri is unblocked while we properly fix the issue.
|
|
|
|
Tweak `expr.await` desugaring `Span`
Fix #93074
|
|
Fix spacing for `·` between stability and source
This puts in an actual space (by adjusting the space-eating operators in our templates), updates the test, and remove the now-unnecessary CSS rule.
r? ``@GuillaumeGomez``
|
|
impl Not for !
The lack of this impl caused trouble for me in some degenerate cases of macro-generated code of the form `if !$cond {...}`, even without `feature(never_type)` on a stable compiler. Namely if `$cond` contains a `return` or `break` or similar diverging expression, which would otherwise be perfectly legal in boolean position, the code previously failed to compile with:
```console
error[E0600]: cannot apply unary operator `!` to type `!`
--> library/core/tests/ops.rs:239:8
|
239 | if !return () {}
| ^^^^^^^^^^ cannot apply unary operator `!`
```
|
|
|
|
Add missing GUI test explanations
Some GUI tests didn't have a global explanation about what they were testing. This fixes it.
r? ```@jsha```
|
|
Reject unsupported naked functions
Transition unsupported naked functions future incompatibility lint into an error:
* Naked functions must contain a single inline assembly block. Introduced as future incompatibility lint in 1.50 #79653. Change into an error fixes a soundness issue described in #32489.
* Naked functions must not use any forms of inline attribute. Introduced as future incompatibility lint in 1.56 #87652.
Closes #32490.
Closes #32489.
r? ```@Amanieu``` ```@npmccallum``` ```@joshtriplett```
|
|
Print a helpful message if unwinding aborts when it reaches a nounwind function
This is implemented by routing `TerminatorKind::Abort` back through the panic handler, but with a special flag in the `PanicInfo` which indicates that the panic handler should *not* attempt to unwind the stack and should instead abort immediately.
This is useful for the planned change in https://github.com/rust-lang/lang-team/issues/97 which would make `Drop` impls `nounwind` by default.
### Code
```rust
#![feature(c_unwind)]
fn panic() {
panic!()
}
extern "C" fn nounwind() {
panic();
}
fn main() {
nounwind();
}
```
### Before
```
$ ./test
thread 'main' panicked at 'explicit panic', test.rs:4:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Illegal instruction (core dumped)
```
### After
```
$ ./test
thread 'main' panicked at 'explicit panic', test.rs:4:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'panic in a function that cannot unwind', test.rs:7:1
stack backtrace:
0: 0x556f8f86ec9b - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hdccefe11a6ac4396
1: 0x556f8f88ac6c - core::fmt::write::he152b28c41466ebb
2: 0x556f8f85d6e2 - std::io::Write::write_fmt::h0c261480ab86f3d3
3: 0x556f8f8654fa - std::panicking::default_hook::{{closure}}::h5d7346f3ff7f6c1b
4: 0x556f8f86512b - std::panicking::default_hook::hd85803a1376cac7f
5: 0x556f8f865a91 - std::panicking::rust_panic_with_hook::h4dc1c5a3036257ac
6: 0x556f8f86f079 - std::panicking::begin_panic_handler::{{closure}}::hdda1d83c7a9d34d2
7: 0x556f8f86edc4 - std::sys_common::backtrace::__rust_end_short_backtrace::h5b70ed0cce71e95f
8: 0x556f8f865592 - rust_begin_unwind
9: 0x556f8f85a764 - core::panicking::panic_no_unwind::h2606ab3d78c87899
10: 0x556f8f85b910 - test::nounwind::hade6c7ee65050347
11: 0x556f8f85b936 - test::main::hdc6e02cb36343525
12: 0x556f8f85b7e3 - core::ops::function::FnOnce::call_once::h4d02663acfc7597f
13: 0x556f8f85b739 - std::sys_common::backtrace::__rust_begin_short_backtrace::h071d40135adb0101
14: 0x556f8f85c149 - std::rt::lang_start::{{closure}}::h70dbfbf38b685e93
15: 0x556f8f85c791 - std::rt::lang_start_internal::h798f1c0268d525aa
16: 0x556f8f85c131 - std::rt::lang_start::h476a7ee0a0bb663f
17: 0x556f8f85b963 - main
18: 0x7f64c0822b25 - __libc_start_main
19: 0x556f8f85ae8e - _start
20: 0x0 - <unknown>
thread panicked while panicking. aborting.
Aborted (core dumped)
```
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #91965 (Add more granular `--exclude` in `x.py`)
- #92467 (Ensure that early-bound function lifetimes are always 'local')
- #92586 (Set the allocation MIN_ALIGN for espidf to 4.)
- #92835 (Improve error message for key="value" cfg arguments.)
- #92843 (Improve string concatenation suggestion)
- #92963 (Implement tuple array diagnostic)
- #93046 (Use let_else in even more places)
- #93109 (Improve `Arc` and `Rc` documentation)
- #93134 (delete `Stdin::split` forwarder)
- #93139 (rustdoc: fix overflow-wrap for table layouts)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`Decoder` has two impls:
- opaque: this impl is already partly infallible, i.e. in some places it
currently panics on failure (e.g. if the input is too short, or on a
bad `Result` discriminant), and in some places it returns an error
(e.g. on a bad `Option` discriminant). The number of places where
either happens is surprisingly small, just because the binary
representation has very little redundancy and a lot of input reading
can occur even on malformed data.
- json: this impl is fully fallible, but it's only used (a) for the
`.rlink` file production, and there's a `FIXME` comment suggesting it
should change to a binary format, and (b) in a few tests in
non-fundamental ways. Indeed #85993 is open to remove it entirely.
And the top-level places in the compiler that call into decoding just
abort on error anyway. So the fallibility is providing little value, and
getting rid of it leads to some non-trivial performance improvements.
Much of this commit is pretty boring and mechanical. Some notes about
a few interesting parts:
- The commit removes `Decoder::{Error,error}`.
- `InternIteratorElement::intern_with`: the impl for `T` now has the same
optimization for small counts that the impl for `Result<T, E>` has,
because it's now much hotter.
- Decodable impls for SmallVec, LinkedList, VecDeque now all use
`collect`, which is nice; the one for `Vec` uses unsafe code, because
that gave better perf on some benchmarks.
|
|
|
|
|
|
rustdoc: fix overflow-wrap for table layouts
For all table layouts, set overflow-wrap: break-word.
Fixes #93135
Demo: https://rustdoc.crud.net/jsha/fix-wrapped-names/std/intrinsics/index.html#functions
(Compare vs https://doc.rust-lang.org/nightly/std/intrinsics/index.html - you may have to make your browser narrower to see the effect)
r? `@Nemo157`
|
|
Implement tuple array diagnostic
Fixes https://github.com/rust-lang/rust/issues/92089
|
|
Improve string concatenation suggestion
Before:
error[E0369]: cannot add `&str` to `&str`
--> file.rs:2:22
|
2 | let _x = "hello" + " world";
| ------- ^ -------- &str
| | |
| | `+` cannot be used to concatenate two `&str` strings
| &str
|
help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left
|
2 | let _x = "hello".to_owned() + " world";
| ~~~~~~~~~~~~~~~~~~
After:
error[E0369]: cannot add `&str` to `&str`
--> file.rs:2:22
|
2 | let _x = "hello" + " world";
| ------- ^ -------- &str
| | |
| | `+` cannot be used to concatenate two `&str` strings
| &str
|
= note: string concatenation requires an owned `String` on the left
help: create an owned `String` from a string reference
|
2 | let _x = "hello".to_owned() + " world";
| +++++++++++
|
|
r=nagisa
Improve error message for key="value" cfg arguments.
Hi, I ran into difficulties using the `--cfg` flag syntax, first hit when googling for the error was issue https://github.com/rust-lang/rust/issues/66450. Reading that issue, it sounded like the best way to improve the experience was to improve the error message, this is low risk and doesn't introduce any additional argument parsing.
The issue mentions that it is entirely dependent on the shell, while this may be true, I think guiding the the user into the realization that the quotes may need to be escaped is helpful. The two suggested escapings both work in Bash and in the Windows command prompt.
fyi `@ehuss`
|
