| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
let-else: test else block with non-never uninhabited type
let else currently does not allow uninhabited types for the `else` block that aren't `!`. One can maybe think about relaxing this in the future, but if it is done, it should be an explicit choice and not an unexpected side effect of e.g. a refactor. Thus, I'm extending a test that will fail if the behaviour changes.
|
|
r=GuillaumeGomez
rustdoc: remove unused CSS `.content .item-list`
When these rules were added in 4fd061c426902b0904c65e64a3780b21f9ab3afb (yeah, that's the very first commit of rustdoc_ng), `.item-list` was a `<ul>`, and this would override the default style for that tag.
In c1b1d6804bfce1aee3a95b3cbff3eaeb15bad9a4, it was changed to use a `<div>` tag, so these rules are both no-ops.
|
|
do not reverse the expected type and found type for ObligationCauseCo…
…de of IfExpressionWithNoElse
this will fix #102397
|
|
|
|
|
|
|
|
Since 50f662e99ec372a3c9558876d4164e8665859217, there is no CSS or JS
targeting this class.
|
|
Remove `-Ztime`
Because it has a lot of overlap with `-Ztime-passes` but is generally less useful. Plus some related cleanups.
Best reviewed one commit at a time.
r? `@davidtwco`
|
|
Fix `opaque_hidden_inferred_bound` lint ICE
Fixes #102705
|
|
make `compare_const_impl` a query and use it in `instance.rs`
Fixes #88365
the bug in #88365 was caused by some `instance.rs` code using the `PartialEq` impl on `Ty` to check that the type of the associated const in an impl is the same as the type of the associated const in the trait definition. This was wrong for two reasons:
- the check typeck does is that the impl type is a subtype of the trait definition's type (see `mismatched_impl_ty_2.rs` which [was ICEing](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f6d60ebe6745011f0d52ab2bc712025d) before this PR on stable)
- it assumes that if two types are equal then the `PartialEq` impl will reflect that which isnt true for higher ranked types or type level constants when `feature(generic_const_exprs)` is enabled (see `mismatched_impl_ty_3.rs` for higher ranked types which was [ICEing on stable](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d7af131a655ed515b035624626c62c71))
r? `@lcnr`
|
|
|
|
|
|
fmease:rustdoc-render-more-cross-crate-hrtbs-properly, r=GuillaumeGomez
rustdoc: render more cross-crate HRTBs properly
Follow-up to #102439.
Render the `for<>` parameter lists of cross-crate higher-rank trait bounds (in where-clauses and in `impl Trait`).
I've added a new field `bound_params` to `clean::WherePredicate::EqPredicate` (mirroring its sibling variant `BoundPredicate`). However, I had to box the existing fields since `EqPredicate` used to be the largest variant (128 bytes on 64-bit systems) and it would only have gotten bigger).
Not sure if you like that approach. As an alternative, I could pass the uncleaned `ty::Predicate` alongside the cleaned `WherePredicate` to the various re-sugaring methods (similar to what `clean::AutoTraitFinder::param_env_to_generics` does).
I haven't yet added the HTML & JSON rendering code for the newly added `bound_params` field since I am waiting for your opinion. Those two rendering code paths should actually be unreachable in practice given we re-sugar all(?) equality predicates to associated type bindings (and arbitrary equality predicates are not part of the Rust surface language at the time of this writing).
If you agree with storing `bound_params` in `EqPredicate`, I think I can use it to greatly simplify the `clean::auto_trait` module (by also using `simplify::merge_bounds`). Maybe I can do that in any case though.
`@rustbot` label T-rustdoc A-cross-crate-reexports
r? `@GuillaumeGomez`
|
|
|
|
|
|
|
|
Add test for issue 82633
Fixes #82633
r? `@estebank`
The current stderr looks slightly different from [source](https://github.com/rust-lang/rust/pull/83915/files#diff-8c64c576ccaceb816e71d2279a6ee4bf79211bc06f55c46dda3f98a18748ad7a), so I used the latest one from nightly. Do let me know if anything is wrong.
|
|
Suggest `==` to wrong assign expr
Given the following code:
```rust
fn main() {
let x = 3;
let y = 3;
if x == x && y = y {
println!("{}", x);
}
}
```
Current output is:
```
error[E0308]: mismatched types
--> src/main.rs:4:18
|
4 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:4:8
|
4 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
```
This adds a suggestion:
```diff
error[E0308]: mismatched types
--> src/main.rs:6:18
|
6 | if x == x && y = y {
| ^ expected `bool`, found integer
error[E0308]: mismatched types
--> src/main.rs:6:8
|
6 | if x == x && y = y {
| ^^^^^^^^^^^^^^^ expected `bool`, found `()`
|
+ help: you might have meant to compare for equality
+ |
+ 6 | if x == x && y == y {
+ | +
```
And this fixes a part of #97469
|
|
Suggest calling method if fn does not exist
I tried to split this up into two commits, the first where we stash the resolution error until typeck (which causes a bunch of diagnostics changes because the ordering of error messages change), then the second commit is the actual logic that actually implements the suggestion.
I am not in love with the presentation of the suggestion, so I could use some advice for how to format the actual messaging.
r? diagnostics
Fixes #102518
|
|
The test is failing when targeting aarch64 Android. The intent appears
to have been to look for a function attributes comment (or the absence
of one) on the line preceding the function declaration. But this isn't
quite possible with FileCheck and the test as written was looking for a
line with `no_scs` after a line with `scs`, which doesn't appear in the
output. Instead, match on the function attributes comment on the line
following the demangled function name comment.
|
|
This test fails when targeting aarch64 Android. Instead of adding yet
another architecture here (and one that's increasingly more common
as the host), let's replace the growing list of architectures with
ignore-cross-compile.
|
|
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used
`-Ztime-passes` for years but only recently learned about `-Ztime`.
What's the difference? Let's look at the `-Zhelp` output:
```
-Z time=val -- measure time of rustc processes (default: no)
-Z time-passes=val -- measure time of each rustc pass (default: no)
```
The `-Ztime-passes` description is clear, but the `-Ztime` one is less so.
Sounds like it measures the time for the entire process?
No. The real difference is that `-Ztime-passes` prints out info about passes,
and `-Ztime` does the same, but only for a subset of those passes. More
specifically, there is a distinction in the profiling code between a "verbose
generic activity" and an "extra verbose generic activity". `-Ztime-passes`
prints both kinds, while `-Ztime` only prints the first one. (It took me
a close reading of the source code to determine this difference.)
In practice this distinction has low value. Perhaps in the past the "extra
verbose" output was more voluminous, but now that we only print stats for a
pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also,
a lot of the "extra verbose" cases are for individual lint passes, and you need
to also use `-Zno-interleave-lints` to see those anyway.
Therefore, this commit removes `-Ztime` and the associated machinery. One thing
to note is that the existing "extra verbose" activities all have an extra
string argument, so the commit adds the ability to accept an extra argument to
the "verbose" activities.
|
|
Since a7c25b29575c17434406b69773f8c2961af343b3 removed `in-band` from code
headers, the only remaining uses of the `in-band` class are:
https://github.com/rust-lang/rust/blob/02cd79afb8080fce8c8ce35533c54d8ecf8f390e/src/librustdoc/html/render/write_shared.rs#L520-L521
https://github.com/rust-lang/rust/blob/02cd79afb8080fce8c8ce35533c54d8ecf8f390e/src/librustdoc/html/templates/print_item.html#L2-L3
https://github.com/rust-lang/rust/blob/02cd79afb8080fce8c8ce35533c54d8ecf8f390e/src/librustdoc/html/render/context.rs#L637-L638
https://github.com/rust-lang/rust/blob/02cd79afb8080fce8c8ce35533c54d8ecf8f390e/src/librustdoc/html/render/mod.rs#L368-L369
https://github.com/rust-lang/rust/blob/02cd79afb8080fce8c8ce35533c54d8ecf8f390e/src/librustdoc/html/render/mod.rs#L401-L402
https://github.com/rust-lang/rust/blob/02cd79afb8080fce8c8ce35533c54d8ecf8f390e/src/librustdoc/html/static/js/main.js#L525
Since all of these uses are nested below `h1.fqn`, we can get rid of it,
and the support code that was used for when `in-band` was part of item
rendering.
|
|
|
|
IfExpressionWithNoElse
this will fix #102397
|
|
Fix unwind drop glue for if-then scopes
cc `@est31`
Fix #102317
Fix #99852
This PR fixes the drop glue for unwinding from a panic originated in a drop while breaking out for the else block in an `if-then` scope.
MIR validation does not fail for the synchronous versions of the test program, because `StorageDead` statements are skipped over in the unwinding process. It is only becoming a problem when it is inside a generator where `StorageDead` must be kept around.
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #100986 (Stop suggesting adding generic args for turbofish)
- #101061 (panic-on-uninit: adjust checks to 0x01-filling)
- #102440 (Only export `__tls_*` on wasm32-unknown-unknown.)
- #102496 (Suggest `.into()` when all other coercion suggestions fail)
- #102699 (Fix hamburger button color)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fix hamburger button color
Before:
After:
No need to backport it, beta doesn't seem affected.
r? `@notriddle`
|
|
Suggest `.into()` when all other coercion suggestions fail
Also removes some bogus suggestions because we now short-circuit when offering coercion suggestions(instead of, for example, suggesting every one that could possibly apply)
Fixes #102415
|
|
panic-on-uninit: adjust checks to 0x01-filling
Now that `mem::uninitiailized` actually fills memory with `0x01` (https://github.com/rust-lang/rust/pull/99182), we can make it panic in a few less cases without risking a lot more UB -- which hopefully slightly improves compatibility with some old code, and which might increase the chance that we can check inside arrays in the future.
We detect almost all of these with our lint, so authors of such code should still be warned -- but if this happens deep inside a dependency, the panic can be quite interruptive, so it might be better not to do it when there is no risk of LLVM UB. Therefore, adjust the `might_permit_raw_init` logic to care primarily about LLVM UB. To my knowledge, it actually covers all cases of LLVM UB now.
Fixes https://github.com/rust-lang/rust/issues/66151
Cc ``@5225225``
|
|
TaKO8Ki:do-not-suggest-adding-generic-args-for-turbofish, r=compiler-errors
Stop suggesting adding generic args for turbofish
Fixes #100137
|
|
resolve error when attempting to link a universal library on macOS
Previously attempting to link universal libraries into libraries (but not binaries) would produce an error that "File too small to be an archive". This works around this by invoking `lipo -thin` to extract a library for the target platform when passed a univeral library.
Fixes #55235
It's worth acknowledging that this implementation is kind of a horrible hack. Unfortunately I don't know how to do anything better, hopefully this PR will be a jumping off point.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
follow-up fix about 101866 to print the self type.
modified: compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
modified: src/test/ui/error-codes/E0283.stderr
modified: src/test/ui/error-codes/E0790.stderr
modified: src/test/ui/traits/static-method-generic-inference.stderr
modified: src/test/ui/type/issue-101866.stderr
|
|
Rageking8:slightly-improve-no-return-for-returning-function-error, r=compiler-errors
Slightly improve no return for returning function error
Fixes #100607
The rationale is that absolute beginners will be slightly confused as to why certain lines of code in a function does not require a semicolon. (I have actually witness a beginner having this confusion). Hence, a slight rationale is added "to return this value", which signals to the user that after removing said semicolon the value is returned resolving that error.
However, if this is not desirable, I welcome any other suggestions. Thanks.
|
|
|
|
|
