| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add `<meta charset="utf-8">` to `-Zdump-mir-spanview` output
Without an explicit `<meta charset>` declaration, some browsers (e.g. Safari) won't detect the page encoding as UTF-8, causing unicode characters in the dump output to display incorrectly.
|
|
[rustdoc] Fix invalid handling of "going back in history" when "go to only search result" setting is enabled
You can test the fix [here](https://rustdoc.crud.net/imperio/back-in-history-fix/lib2/index.html). Enable "Directly go to item in search if there is only one result", then search for `HasALongTraitWithParams` and finally go back to previous page. It should be back on the `index.html` page.
The reason for this bug is that the JS state is cached as is, so when we go back to the page, it resumes where it was left, somewhat (very weird), meaning the search is run again etc. The best way to handle this is to force the JS re-execution in this case so that it doesn't try to resume from where it left and then lead us back to the current page.
r? ``@notriddle``
|
|
fix ICE on specific malformed asm clobber_abi
fixes #112635
|
|
|
|
Add `AliasKind::Weak` for type aliases.
`type Foo<T: Debug> = Bar<T>;` does not check `T: Debug` at use sites of `Foo<NotDebug>`, because in contrast to a
```rust
trait Identity {
type Identity;
}
impl<T: Debug> Identity for T {
type Identity = T;
}
<NotDebug as Identity>::Identity
```
type aliases do not exist in the type system, but are expanded to their aliased type immediately when going from HIR to the type layer.
Similarly:
* a private type alias for a public type is a completely fine thing, even though it makes it a bit hard to write out complex times sometimes
* rustdoc expands the type alias, even though often times users use them for documentation purposes
* diagnostics show the expanded type, which is confusing if the user wrote a type alias and the diagnostic talks about another type that they don't know about.
For type alias impl trait, these issues do not actually apply in most cases, but sometimes you have a type alias impl trait like `type Foo<T: Debug> = (impl Debug, Bar<T>);`, which only really checks it for `impl Debug`, but by accident prevents `Bar<T>` from only being instantiated after proving `T: Debug`. This PR makes sure that we always check these bounds explicitly and don't rely on an implementation accident.
To not break all the type aliases out there, we only use it when the type alias contains an opaque type. We can decide to do this for all type aliases over an edition.
Or we can later extend this to more types if we figure out the back-compat concerns with suddenly checking such bounds.
As a side effect, easily allows fixing https://github.com/rust-lang/rust/issues/108617, which I did.
fixes https://github.com/rust-lang/rust/issues/108617
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #111074 (Relax implicit `T: Sized` bounds on `BufReader<T>`, `BufWriter<T>` and `LineWriter<T>`)
- #112226 (std: available_parallelism using native netbsd api first)
- #112474 (Support 128-bit enum variant in debuginfo codegen)
- #112662 (`#[lang_item]` for `core::ptr::Unique`)
- #112665 (Make assumption functions in new solver take `Binder<'tcx, Clause<'tcx>>`)
- #112684 (Disable alignment checks on i686-pc-windows-msvc)
- #112706 (Add `SyntaxContext::is_root`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Disable alignment checks on i686-pc-windows-msvc
r? `@wesleywiser` Because you were in the Zulip discussion of this: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202023-06-15
cc #112480
|
|
Support 128-bit enum variant in debuginfo codegen
fixes #111600
|
|
Only use it when the type alias contains an opaque type.
Also does wf-checking on such type aliases.
|
|
|
|
Ignore the always part of #[inline(always)] in MIR inlining
`#[inline(always)]` is used in two cases: for functions that are so trivial it is always profitable to inline them, but also for functions which LLVM thinks are a bad inlining candidate, but which actually turn out to be profitable to inline. That second justification doesn't apply to the MIR inliner, so ignoring our cost estimation for these functions is not necessarily the right right thing to do.
This is basically a wash on non-check runs and a perf benefit in check runs. There are some notable regressions, and I think we might be able to claw those back by turning `#[inline(always)]` into a stronger hint. But I think this PR stands decently on its own as a tidy simplification.
|
|
|
|
rustdoc: Add search result item types after their name
Here what it looks like:
The idea is to improve accessibility by providing this information directly in the text and not only in the text color. Currently we already use it for doc aliases and for primitive types, so I extended it to all types.
r? `@notriddle`
|
|
|
|
Handle interpolated literal errors
Not sure why it was doing a whole dance to re-match on the token kind when it seems like `Lit::from_token` does the right thing for both macro-arg and regular literals. Nothing seems to have regressed diagnostics-wise from the change, though.
Fixes #112622
r? ``@nnethercote``
|
|
compiler-errors:next-solver-opportunistically-resolve-regions, r=lcnr
Opportunistically resolve regions in new solver
Use `opportunistic_resolve_var` during canonicalization to collapse some regions.
We have to start using `CanonicalVarValues::is_identity_modulo_regions`. We also have to modify that function to consider responses like `['static, ^0, '^1, ^2]` to be an "identity" response, since because we opportunistically resolve regions, there's no longer a 1:1 mapping between canonical var values and bound var indices in the response...
There's one nasty side-effect -- one test (`tests/ui/dyn-star/param-env-infer.rs`) starts to ICE because the certainty goes from `Yes` to `Maybe(Overflow)`... Not exactly sure why, though? Putting this up for discussion/investigation.
r? ```@lcnr```
|
|
Instantiate closure synthetic substs in root universe
In the UI test example, we end up generalizing an associated type (something like `<Map<Option<i32>, [closure upvars=?0]> as IntoIterator>::Item` generalizes into `<Map<Option<i32>, [closure upvars=?1]> as IntoIterator>::Item`) then assigning it to itself, emitting an alias-relate goal. This trivially holds via one of the normalizes-to candidates, instead of relating substs, so when closure analysis eventually sets `?0` to the actual upvars, `?1` never gets constrained. This ends up being reported as an ambiguity error during writeback.
Instead, we can take advantage of the fact that we *know* the closure substs live in the root universe. This will prevent them being generalized, since they always can be named, and the alias-relate above never gets emitted at all.
We can probably do this to a handful of other `next_ty_var` calls in typeck for variables that are clearly associated with the body of the program, but I wanted to limit this for now. Eventually, if we end up representing universes more faithfully like a tree or whatever, we can remove this and turn it back to just a call to `next_ty_var`.
Note: This is incredibly order-dependent -- we need to be assigning a type variable that was created *before* the closure substs, and we also need to actually have an unnormalized type at the time of the assignment. This currently seems easiest to trigger during call argument analysis just due to the fact that we instantiate the call's substs, normalize, THEN check args.
r? ```@lcnr```
|
|
fix: inline `predicate_may_hold_fatal` and remove expect call in it
- Fixes #105231
- Discussion: https://github.com/rust-lang/rust/pull/111985#discussion_r1208888821
r? ``@compiler-errors``
|
|
|
|
Remove comments from mir-opt MIR dumps
See https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Line.20numbers.20in.20mir-opt.20tests/near/363849874
In https://github.com/rust-lang/rust/pull/99780 there is mention that "there has been a zulip conversation about disabling line numbers with mixed opinions" which to me means that some people opposed this. I can't find the referenced conversation so... here we go.
The current situation is quite chaotic. It's not hard to find MIR diffs which contain
* Absolute line numbers
* Relative line numbers
* Substituted line numbers (LL)
For example: https://github.com/rust-lang/rust/blob/408bbd040613f6776e0a7d05d582c81f4ddc189a/tests/mir-opt/inline/inline_shims.drop.Inline.diff#L10-L17
And sometimes adding a comment at the top of a mir-opt test generates a diff in the test because a line number changed: https://github.com/rust-lang/rust/pull/98112/files#diff-b8cf4bcce95078e6a3faf075e9abf6864872fb28a64d95c04f04513b9e3bbd81
And irrelevant changes to the standard library can generate diffs in mir-opt tests: https://github.com/rust-lang/rust/pull/110694/files#diff-bf96b0e7c67b8b272814536888fd9428c314991e155beae1f0a2a67f0ac47b2c
https://github.com/rust-lang/rust/commit/769886cc35ce08b76839f4cf72b8af1161c432e1
I think we should, specifically in mir-opt tests, completely remove the comments, or insert placeholders for all line and column numbers.
|
|
normalize closure output in equate_inputs_and_outputs
Fixes #112604
|
|
tweak suggestion for argument-position `impl ?Sized`
fixes this invalid suggestion:
```text
help: consider removing the `?Sized` bound to make the type parameter `Sized`
|
1 - fn foo(_: impl ?Sized) {}
1 + fn foo(_: impl ) {}
|
```
|
|
Extend `unused_must_use` to cover block exprs
Given code like
```rust
#[must_use]
fn foo() -> i32 {
42
}
fn warns() {
{
foo();
}
}
fn does_not_warn() {
{
foo()
};
}
fn main() {
warns();
does_not_warn();
}
```
### Before This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: 1 warning emitted
```
### After This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: unused return value of `foo` that must be used
--> test.rs:14:9
|
14 | foo()
| ^^^^^
|
help: use `let _ = ...` to ignore the resulting value
|
14 | let _ = foo();
| +++++++ +
warning: 2 warnings emitted
```
Fixes #104253.
|
|
`suspicious_double_ref_op`: don't lint on `.borrow()`
closes #112489
|
|
Prevent `.eh_frame` from being emitted for `-C panic=abort`
Since `CheckAlignment` pass is after the `AbortUnwindingCalls` pass, the `UnwindAction::Terminate` inserted in it has no chance to be converted to `UnwindAction::Unreachable` anymore, causing us to emit landing pads that are not necessary. Although these landing pads can themselves be eliminated by LLVM, `.eh_frame` sections are still generated. This causes trouble for Rust-for-Linux project recently.
This PR changes it to generate `UnwindAction::Terminate` when we opt for `-Cpanic=unwind`, and `UnwindAction::Unreachable` for `-Cpanic=abort`.
`@ojeda`
|
|
|
|
add InlineConst check
add check to close #112438
|
|
Fix suggestion for E0404 not dealing with multiple generics
Fixes #112472.
|
|
Add chapter in rustdoc book for re-exports and add a regression test for `#[doc(hidden)]` behaviour
Fixes https://github.com/rust-lang/rust/issues/109449.
Fixes https://github.com/rust-lang/rust/issues/53417.
After the discussion in #109697, I made a few PRs to fix a few corner cases:
* https://github.com/rust-lang/rust/pull/112178
* https://github.com/rust-lang/rust/pull/112108
* https://github.com/rust-lang/rust/pull/111997
With this I think I covered all cases. Only thing missing at this point was a chapter covering re-exports in the rustdoc book.
r? `@notriddle`
|
|
Add casting suggestion when assigning negative 2's complement bin or hex literal to a size compatible signed integer
Fixes #107896
The issue stated the case for `iX::MIN` variants. This PR extends the cases for other negative values (in the 2's complement).
Leveraged sign bits to detect such cases.
Example cases:
- <img width="845" alt="image" src="https://user-images.githubusercontent.com/65026286/236289682-19859f59-a9c5-48c5-b15f-78a935fbfcec.png">
- <img width="831" alt="image" src="https://user-images.githubusercontent.com/65026286/236289805-5b16488d-9138-4363-a1b6-a5c027c50aba.png">
- <img width="912" alt="image" src="https://user-images.githubusercontent.com/65026286/236290065-685a9777-034b-4def-83a8-cc4e20b1ed0c.png">
|
|
|
|
|
|
|
|
|
|
|
|
|
|
optimize slice::Iter::fold
Fixes 2 of 4 cases from #106288
```
OLD: test slice::fold_to_last ... bench: 248 ns/iter (+/- 3)
NEW: test slice::fold_to_last ... bench: 0 ns/iter (+/- 0)
```
|
|
rustdoc-search: clean up type unification and "unboxing"
This PR redesigns parameter matching, return matching, and generics matching to use a single function that compares two lists of types.
It also makes the algorithms more consistent, so the "unboxing" behavior where `Vec<i32>` is considered a match for `i32` works inside generics, and not just at the top level.
|
|
|
|
Don't drain-on-drop in DrainFilter impls of various collections.
This removes drain-on-drop behavior from various unstable DrainFilter impls (not yet for HashSet/Map) because that behavior [is problematic](https://github.com/rust-lang/rust/issues/43244#issuecomment-641638196) (because it can lead to panic-in-drop when user closures panic) and may become forbidden if [this draft RFC passes](https://github.com/rust-lang/rfcs/pull/3288).
closes #101122
[ACP](https://github.com/rust-lang/libs-team/issues/136)
affected tracking issues
* #43244
* #70530
* #59618
Related hashbrown update: https://github.com/rust-lang/hashbrown/pull/374
|
|
this seems to produce less IR
|
|
Rollup of 7 pull requests
Successful merges:
- #112584 (loongarch64-none*: Remove environment component from llvm target)
- #112600 (Introduce a `Stable` trait to translate MIR to SMIR)
- #112605 (Improve docs/clean up negative overlap functions)
- #112611 (Error on unconstrained lifetime in RPITIT)
- #112612 (Fix explicit-outlives-requirements lint span)
- #112613 (Fix rustdoc-gui tests on Windows)
- #112620 (Fix small typo)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Rollup of 6 pull requests
Successful merges:
- #98202 (Implement `TryFrom<&OsStr>` for `&str`)
- #107619 (Specify behavior of HashSet::insert)
- #109814 (Stabilize String::leak)
- #111974 (Update runtime guarantee for `select_nth_unstable`)
- #112109 (Don't print unsupported split-debuginfo modes with `-Zunstable-options`)
- #112506 (Properly check associated consts for infer placeholders)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix rustdoc-gui tests on Windows
The browser-ui-test update contains fixes needed for backslash handling (they were not correctly escaped).
Since we have a mix of slash and backslash in some tests, I replaced `DOC_FOLDER` variable backslashes with slashes.
And finally it seemed like the unicode escaped wasn't much appreciated on Windows for some reason so I used the character directly.
cc `@klensy`
r? `@notriddle`
|
|
Fix explicit-outlives-requirements lint span
Fixes #105150 which caused the span reported by the explicit-outlives-requirements lint to be incorrect when
1) the lint should suggest the entire where clause to be removed and
2) there are inline bounds present that are not inferable outlives requirements
In particular, this would cause rustfix to leave a dangling empty where clause.
|
|
Error on unconstrained lifetime in RPITIT
Fixes #109468
The only thing is that I had to split `tests/ui/impl-trait/in-trait/method-signature-matches.rs` into a bunch of different revisions because some error aren't being emitted if all the different examples are all together in one file :thinking:
r? `@oli-obk` just because i know you'll review it, feel free to re-roll
|
|
Properly check associated consts for infer placeholders
We only reported an error if it was in a "suggestable" position (according to `is_suggestable_infer_ty`) -- this isn't correct for infer tys that can show up in other places in the constant's type, like behind a dyn trait.
fixes #112491
|
|
|
|
Add support for targets without unwinding in `mir-opt`, and improve `--bless` for it
The main goal of this PR is to add support for targets without unwinding support in the `mir-opt` test suite, by adding the `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment. Similarly to 32bit vs 64bit, when that comment is present, blessed output files will have the `.panic-unwind` or `.panic-abort` suffix, and the right one will be chosen depending on the target's panic strategy.
The `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment replaced all the `ignore-wasm32` comments in the `mir-opt` test suite, as those comments were added due to `wasm32` being a target without unwinding support. The comment was also added on other tests that were only executed on x86 but were still panic strategy dependent.
The `mir-opt` suite was then blessed, which caused a ton of churn as most of the existing output files had to be renamed and (mostly) duplicated with the abort strategy.
---
After [asking on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mir-opt.20tests.20and.20panic.3Dabort), the main concern about this change is it'd make blessing the `mir-opt` suite even harder, as you'd need to both bless it with an unwinding target and an aborting target. This exacerbated the current situation, where you'd need to bless it with a 32bit and a 64bit target already.
Because of that, this PR also makes significant enhancements to `--bless` for the `mir-opt` suite, where it will automatically bless the suite four times with different targets, while requiring minimal cross-compilation.
To handle the 32bit vs 64bit blessing, there is now an hardcoded list of target mapping between 32bit and 64bit. The goal of the list is to find a related target that will *probably* work without requiring additional cross-compilation toolchains on the system. If a mapping is found, bootstrap will bless the suite with both targets, otherwise just with the current target.
To handle the panic strategy blessing (abort vs unwind), I had to resort to what I call "synthetic targets". For each of the target we're blessing (so either the current one, or a 32bit and a 64bit depending on the previous paragraph), bootstrap will extract the JSON spec of the target and change it to include `"panic-strategy": "abort"`. It will then build the standard library with this synthetic target, and bless the `mir-opt` suite with it.
As a result of these changes, blessing the `mir-opt` suite will actually bless it two or four times with different targets, ensuring all possible variants are actually blessed.
---
This PR is best reviewed commit-by-commit.
r? `@jyn514`
cc `@saethlin` `@oli-obk`
|
