| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=GuillaumeGomez
rustdoc: clean up source sidebar hide button
This is a redesign of the feature, with parts pulled from https://github.com/rust-lang/rust/pull/119049 but with a button that looks more like a button and matches the one used on other sidebar pages.
Preview:
* http://notriddle.com/rustdoc-html-demo-8/source-sidebar-resize/src/std/lib.rs.html
* http://notriddle.com/rustdoc-html-demo-8/source-sidebar-resize/std/index.html
| | Before | After |
|--|--|--|
| Closed |  | 
| Open |  | 
| Mobile Closed |  | 
| Mobile Open |  | 
|
|
Don't drop a hir node after lowering
Fixes https://github.com/rust-lang/rust/issues/119271.
It seems that all hir nodes that get allocated an id must be placed within the hir on pain of ICEs. In https://github.com/rust-lang/rust/pull/118527 I dropped guards on never patterns since they're not useful, which caused the ICE.
|
|
This involves lots of breaking changes. There are two big changes that
force changes. The first is that the bitflag types now don't
automatically implement normal derive traits, so we need to derive them
manually.
Additionally, bitflags now have a hidden inner type by default, which
breaks our custom derives. The bitflags docs recommend using the impl
form in these cases, which I did.
|
|
Rollup of 5 pull requests
Successful merges:
- #119158 (Clean up alloc::sync::Weak Clone implementation)
- #119386 (fix typo in `IpAddr::to_canonical`)
- #119413 (solaris support on bootstrap lock)
- #119424 (Primitive docs: fix confusing `Send` in `&T`'s list)
- #119425 (Fix invalid check-cfg Cargo feature diagnostic help)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix invalid check-cfg Cargo feature diagnostic help
#118213 added specialized diagnostic for Cargo `feature` cfg. However when providing an empty `#[cfg(feature)]` condition the suggestion would suggest adding `feature` as a feature in `Cargo.toml` (wtf!).
This PR removes the invalid logic, which even brings a nice improvement.
```diff
--> $DIR/cargo-feature.rs:18:7
|
LL | #[cfg(feature)]
- | ^^^^^^^
+ | ^^^^^^^- help: specify a config value: `= "bitcode"`
|
= note: expected values for `feature` are: `bitcode`
- = help: consider defining `feature` as feature in `Cargo.toml`
```
The first commit add a test showing the bug and the second commit fixes the bug.
`@rustbot` label +F-check-cfg
|
|
Don't validate / lint MIR before each pass
To avoid redundant work and verbose output in case of failures.
|
|
Implement constant propagation on top of MIR SSA analysis
This implements the idea I proposed in https://github.com/rust-lang/rust/pull/110719#issuecomment-1718324700
Based on https://github.com/rust-lang/rust/pull/109597
The value numbering "GVN" pass formulates each rvalue that appears in MIR with an abstract form (the `Value` enum), and assigns an integer `VnIndex` to each. This abstract form can be used to deduplicate values, reusing an earlier local that holds the same value instead of recomputing. This part is proposed in #109597.
From this abstract representation, we can perform more involved simplifications, for example in https://github.com/rust-lang/rust/pull/111344.
With the abstract representation `Value`, we can also attempt to evaluate each to a constant using the interpreter. This builds a `VnIndex -> OpTy` map. From this map, we can opportunistically replace an operand or a rvalue with a constant if their value has an associated `OpTy`.
The most relevant commit is [Evaluated computed values to constants.](https://github.com/rust-lang/rust/commit/2767c4912ea249c2f613a9cedcd6c13ea1237e54)"
r? `@oli-obk`
|
|
|
|
|
|
Rename test to be more descriptive
As suggested in https://github.com/rust-lang/rust/pull/119402#discussion_r1438171079
r? ``@Nilstrieb``
|
|
Add non-regression test for ATPIT ICE #114325
ATPIT issue #114325 had been unknowingly fixed by https://github.com/rust-lang/rust/pull/107421, so this PR adds its [MCVE](https://github.com/rust-lang/rust/issues/114325#issuecomment-1721561552) as a non-regression test.
Closes #114325.
|
|
rustc_lint: Prevent triplication of various lints
Prevent triplication of various lints. The triplication happens because we run the same lint three times (or less in some cases):
* In `BuiltinCombinedPreExpansionLintPass`
* In `BuiltinCombinedEarlyLintPass`
* In `shallow_lint_levels_on()`
Only run the lints one time by checking the `lint_added_lints` bool.
Set your GitHub diff setting to ignore whitespaces changes when reviewing this PR, since I had to enclose a block inside an if.
Closes #73301
(I found this while exploring the code related to [this](https://github.com/rust-lang/rust/pull/119251#discussion_r1435677330) comment.)
|
|
fix: correct the args for `disambiguate the associated function` diagnostic
This is somehow silimar to https://github.com/rust-lang/rust/pull/118502, we shouldn't take receiver as first arg all the cases.
close https://github.com/rust-lang/rust/issues/118819
|
|
|
|
|
|
|
|
Remove movability from `TyKind::Coroutine`
There's no reason to store movability in the generator struct directly. It is computed from the HIR, and can be pulled into a query to access when necessary.
|
|
|
|
|
|
Prevent multiple 'ignored unless specified at crate level' lints. The
multiplication happens because we run the same lint three times:
* In BuiltinCombinedEarlyLintPass
* In BuiltinCombinedPreExpansionLintPass
* In shallow_lint_levels_on
Only run the lint one time by checking the `lint_added_lints` bool.
|
|
Don't suggest writing a bodyless arm if the pattern can never be a never pattern
#118527 enabled arms to be bodyless for never patterns ; this PR removes the `,` and `}` suggestions for patterns that could never be never patterns.
|
|
Add regression test for #106630
This PR adds a regression test for #106630. I was unsure where exactly to place the test or how to test it locally so please let me know if I should change something.
|
|
r=GuillaumeGomez
rustdoc-search: count path edits with separate edit limit
Avoids strange-looking results like this one, where the path component seems to be ignored:
Since the two are counted separately elsewhere, they should get their own limits, too. The biggest problem with combining them is that paths are loosely checked by not requiring every component to match, which means that if they are short and matched loosely, they can easily find "drunk typist" matches that make no sense, like this old result:
std::collections::btree_map::itermut matching slice::itermut
maxEditDistance = ("slice::itermut".length) / 3 = 14 / 3 = 4
editDistance("std", "slice") = 4
editDistance("itermut", "itermut") = 0
4 + 0 <= 4 PASS
Of course, `slice::itermut` should not match stuff from btreemap. `slice` should not match `std`.
The new result counts them separately:
maxPathEditDistance = "slice".length / 3 = 5 / 3 = 1
maxEditDistance = "itermut".length / 3 = 7 / 3 = 2
editDistance("std", "slice") = 4
4 <= 1 FAIL
Effectively, this makes path queries less "typo-resistant". It's not zero, but it means `vec` won't match the `v1` prelude.
This commit also adds substring matching to paths. It's stricter than the substring matching in the main part, but loose enough that what I expect to match does.
Queries without parent paths are unchanged.
|
|
|
|
To avoid redundant work and verbose output in case of failures.
|
|
|
|
|
|
Fix parenthesization of subexprs containing statement boundary
This PR fixes a multitude of false negatives and false positives in the AST pretty printer's parenthesis insertion related to statement boundaries — statements which terminate unexpectedly early if there aren't parentheses.
Without this fix, the AST pretty printer (including both `stringify!` and `rustc -Zunpretty=expanded`) is prone to producing output which is not syntactically valid Rust. Invalid output is problematic because it means Rustfmt is unable to parse the output of `cargo expand`, for example, causing friction by forcing someone trying to debug a macro into reading poorly formatted code.
I believe the set of bugs fixed in this PR account for the most prevalent reason that `cargo expand` produces invalid output in real-world usage.
Fixes #98790.
## False negatives
The following is a correct program — `cargo check` succeeds.
```rust
macro_rules! m {
($e:expr) => {
match () { _ => $e }
};
}
fn main() {
m!({ 1 } - 1);
}
```
But `rustc -Zunpretty=expanded main.rs` produces output that is invalid Rust syntax, because parenthesization is needed and not being done by the pretty printer.
```rust
fn main() { match () { _ => { 1 } - 1, }; }
```
Piping this expanded code to rustfmt, it fails to parse.
```console
error: unexpected `,` in pattern
--> <stdin>:1:38
|
1 | fn main() { match () { _ => { 1 } - 1, }; }
| ^
|
help: try adding parentheses to match on a tuple...
|
1 | fn main() { match () { _ => { 1 } (- 1,) }; }
| + +
help: ...or a vertical bar to match on multiple alternatives
|
1 | fn main() { match () { _ => { 1 } - 1 | }; }
| ~~~~~
```
Fixed output after this PR:
```rust
fn main() { match () { _ => ({ 1 }) - 1, }; }
```
## False positives
Less problematic, but worth fixing (just like #118726).
```rust
fn main() {
let _ = match () { _ => 1 } - 1;
}
```
Output of `rustc -Zunpretty=expanded lib.rs` before this PR. There is no reason parentheses would need to be inserted there.
```rust
fn main() { let _ = (match () { _ => 1, }) - 1; }
```
After this PR:
```rust
fn main() { let _ = match () { _ => 1, } - 1; }
```
## Alternatives considered
In this PR I opted to parenthesize only the leading subexpression causing the statement boundary, rather than the entire statement. Example:
```rust
macro_rules! m {
($e:expr) => {
$e
};
}
fn main() {
m!(loop { break [1]; }[0] - 1);
}
```
This PR produces the following pretty-printed contents for fn main:
```rust
(loop { break [1]; })[0] - 1;
```
A different equally correct output would be:
```rust
(loop { break [1]; }[0] - 1);
```
I chose the one I did because it is the *only* approach used by handwritten code in the standard library and compiler. There are 4 places where parenthesization is being used to prevent a statement boundary, and in all 4, the developer has chosen to parenthesize the smallest subexpression rather than the whole statement:
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_codegen_cranelift/example/alloc_system.rs#L102
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/compiler/rustc_parse/src/errors.rs#L1021-L1029
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/future/poll_fn.rs#L151
https://github.com/rust-lang/rust/blob/b37d43efd9c5a7a3d76ed21c454dd0f40945d77d/library/core/src/ops/range.rs#L824-L828
|
|
Introduce `const Trait` (always-const trait bounds)
Feature `const_trait_impl` currently lacks a way to express “always const” trait bounds. This makes it impossible to define generic items like fns or structs which contain types that depend on const method calls (\*). While the final design and esp. the syntax of effects / keyword generics isn't set in stone, some version of “always const” trait bounds will very likely form a part of it. Further, their implementation is trivial thanks to the `effects` backbone.
Not sure if this needs t-lang sign-off though.
(\*):
```rs
#![feature(const_trait_impl, effects, generic_const_exprs)]
fn compute<T: const Trait>() -> Type<{ T::generate() }> { /*…*/ }
struct Store<T: const Trait>
where
Type<{ T::generate() }>:,
{
field: Type<{ T::generate() }>,
}
```
Lastly, “always const” trait bounds are a perfect fit for `generic_const_items`.
```rs
#![feature(const_trait_impl, effects, generic_const_items)]
const DEFAULT<T: const Default>: T = T::default();
```
Previously, we (oli, fee1-dead and I) wanted to reinterpret `~const Trait` as `const Trait` in generic const items which would've been quite surprising and not very generalizable.
Supersedes #117530.
---
cc `@oli-obk`
As discussed
r? fee1-dead (or compiler)
|
|
Suggest `=>` --> `>=` in comparisons
Fixes #117245
|
|
|
|
rustdoc: treat query string `+` as space
Fixes #119219
|
|
fix: diagnostic for casting reference to slice
fixes: #118790
Removes `if self.cast_ty.is_trait()` to produce the same diagnostic for cast to slice and trait.
|
|
|
|
|
|
Since the two are counted separately elsewhere, they should get
their own limits, too. The biggest problem with combining them
is that paths are loosely checked by not requiring every component
to match, which means that if they are short and matched loosely,
they can easily find "drunk typist" matches that make no sense,
like this old result:
std::collections::btree_map::itermut matching slice::itermut
maxEditDistance = ("slice::itermut".length) / 3 = 14 / 3 = 4
editDistance("std", "slice") = 4
editDistance("itermut", "itermut") = 0
4 + 0 <= 4 PASS
Of course, `slice::itermut` should not match stuff from btreemap.
`slice` should not match `std`.
The new result counts them separately:
maxPathEditDistance = "slice".length / 3 = 5 / 3 = 1
maxEditDistance = "itermut".length / 3 = 7 / 3 = 2
editDistance("std", "slice") = 4
4 <= 1 FAIL
Effectively, this makes path queries less "typo-resistant".
It's not zero, but it means `vec` won't match the `v1` prelude.
Queries without parent paths are unchanged.
|
|
Given `foo: &String` and `bar: str`, suggest `==` when given `if foo = bar {}`:
```
error[E0308]: mismatched types
--> $DIR/assignment-expected-bool.rs:37:8
|
LL | if foo = bar {}
| ^^^^^^^^^ expected `bool`, found `()`
|
help: you might have meant to compare for equality
|
LL | if foo == bar {}
| +
```
|
|
Emit better suggestions for `&T == T` and `T == &T`
Fixes #40660
Fixes #44695
|
|
Fixes #119219
|
|
Rollup of 5 pull requests
Successful merges:
- #119235 (Add missing feature gate for sanitizer CFI cfgs)
- #119240 (Make some non-diagnostic-affecting `QPath::LangItem` into regular `QPath`s)
- #119297 (Pass DeadItem and lint as consistent group in dead-code.)
- #119307 (Clean up some lifetimes in `rustc_pattern_analysis`)
- #119323 (add test for coercing never to infinite type)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add test for coercing never to infinite type
Closes https://github.com/rust-lang/rust/issues/113197.
This was fixed in https://github.com/rust-lang/rust/pull/118308, probably https://github.com/rust-lang/rust/pull/118308/commits/1978168c136ba65b8da3f5a45834631c13d7c56f.
|
|
Pass DeadItem and lint as consistent group in dead-code.
Fixes https://github.com/rust-lang/rust/issues/119267
|
|
Make some non-diagnostic-affecting `QPath::LangItem` into regular `QPath`s
The rest of 'em affect diagnostics, so leave them alone... for now.
cc #115178
|
|
r=Nilstrieb
Add missing feature gate for sanitizer CFI cfgs
Found during the review of https://github.com/rust-lang/rust/pull/118494 in https://github.com/rust-lang/rust/pull/118494#discussion_r1416079288.
cc `@rcvalle`
|
|
fallback `default` to `None` during ast-lowering for lifetime binder
Fixes #118697
This is another attempt. It has a fallback, setting `default` to `None` and emit an error for non-lifetime binders during ast lowering.
r? `@compiler-errors`
|
|
|
|
|
|
Add `hint::assert_unchecked`
Libs-API expressed interest, modulo bikeshedding, in https://github.com/rust-lang/libs-team/issues/315#issuecomment-1863159430
I think that means this is good for nightly, since we can always rename it before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/119131
|
|
rework `-Zverbose`
implements the changes described in https://github.com/rust-lang/compiler-team/issues/706
the first commit is only a name change from `-Zverbose` to `-Zverbose-internals` and does not change behavior. the second commit changes diagnostics.
possible follow up work:
- `ty::pretty` could print more info with `--verbose` than it does currently. `-Z verbose-internals` shows too much info in a way that's not helpful to users. michael had ideas about this i didn't fully understand: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408984200
- `--verbose` should imply `-Z write-long-types-to-disk=no`. the code in `ty_string_with_limit` should take `--verbose` into account (apparently this affects `Ty::sort_string`, i'm not familiar with this code). writing a file to disk should suggest passing `--verbose`.
r? `@compiler-errors` cc `@estebank`
|
|
|
