| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
Add test for #102605
Fixes #102605
|
|
Only allow ~const bounds for traits with #[const_trait]
r? `@fee1-dead`
|
|
Check generic argument compatibility when projecting assoc ty
Fixes #102114
|
|
|
|
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 using `object` to extract a library for the target platform when passed a univeral library.
Fixes #55235
|
|
|
|
r=davidtwco
Fix rustdoc ICE in invalid_rust_codeblocks lint
The diagnostic message extraction code didn't handle translations yet.
Fixes #102603
Fixes #102631
r? `@davidtwco`
|
|
Lint against nested opaque types that don't satisfy associated type bounds
See the test failures for examples of places where this lint would fire.
r? `@oli-obk`
|
|
Don't ICE when trying to copy unsized value in const prop
When we have a trivially false where-clause predicate like `Self: Sized` where `Self = dyn Trait`, we sometimes don't throw an error during typeck for an illegal operation such as copying an unsized type.
This, unfortunately, cannot be made into an error (at least not without some migration -- see #95611 for example), but we should at least not ICE, since this function will never actually be reachable from main, for example.
r? `@RalfJung` since I think you added these assertions? but feel free to reassign.
Fixes #102553
|
|
Normalize substs before resolving instance in `NoopMethodCall` lint
Fixes #102074
r? types
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #102441 (Suggest unwrap_or_else when a closure is given)
- #102547 (Migrate CSS theme for search results)
- #102567 (Delay evaluating lint primary message until after it would be suppressed)
- #102624 (rustdoc: remove font family CSS on `.rustdoc-toggle summary::before`)
- #102628 (Change the parameter name of From::from to `value`)
- #102637 (Ignore fuchsia on two compiler tests)
- #102639 (Improve spans when splitting multi-char operator tokens for proc macros.)
Failed merges:
- #102496 (Suggest `.into()` when all other coercion suggestions fail)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve spans when splitting multi-char operator tokens for proc macros.
When a two-char (or three-char) operator token is split into single-char operator tokens before being passed to a proc macro, the single-char tokens are given the original span of length two (or three). This PR gives them more accurate spans.
r? `@Aaron1011`
cc `@petrochenkov`
|
|
Ignore fuchsia on two compiler tests
Adding `ignore-fuchsia` to two irrelevant compiler tests
cc. `@djkoloski`
r? `@tmandry`
|
|
Delay evaluating lint primary message until after it would be suppressed
Fixes #102561
Fixes #102572
|
|
r=notriddle,jsha
Migrate CSS theme for search results
Part of https://github.com/rust-lang/rust/pull/98460.
Just like https://github.com/rust-lang/rust/pull/102237, I unified theme to how the `ayu` handles this one: only one color for the background when search results are focused or hovered.
You can test it [here](https://rustdoc.crud.net/imperio/migrate-css-theme-search-result/lib2/index.html?search=coo).
cc `@jsha`
r? `@notriddle`
PS: The repetition in GUI tests is getting out of hand so I opened https://github.com/GuillaumeGomez/browser-UI-test/issues/363 to think about adding possibility to declare functions so we can greatly improve this.
|
|
r=compiler-errors
Suggest unwrap_or_else when a closure is given
Fixes #102320
r? `@compiler-errors`
|
|
errors: rename `typeck.ftl` to `hir_analysis.ftl`
In #102306, `rustc_typeck` was renamed to `rustc_hir_analysis` but the diagnostic resources were not renamed - which is what this pull request changes.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #98218 (Document the conditional existence of `alloc::sync` and `alloc::task`.)
- #99216 (docs: be less harsh in wording for Vec::from_raw_parts)
- #99460 (docs: Improve AsRef / AsMut docs on blanket impls)
- #100470 (Tweak `FpCategory` example order.)
- #101040 (Fix `#[derive(Default)]` on a generic `#[default]` enum adding unnecessary `Default` bounds)
- #101308 (introduce `{char, u8}::is_ascii_octdigit`)
- #102486 (Add diagnostic struct for const eval error in `rustc_middle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
The diagnostic message extraction code didn't handle translations yet.
|
|
danielhenrymantilla:no-bounds-for-default-annotated-derive, r=joshtriplett
Fix `#[derive(Default)]` on a generic `#[default]` enum adding unnecessary `Default` bounds
That is, given something like:
```rs
// #[default] on a generic enum does not add `Default` bounds to the type params.
#[derive(Default)]
enum MyOption<T> {
#[default]
None,
Some(T),
}
```
then `MyOption<T> : Default`_as currently implemented_ only holds when `T : Default`, as reported by ```@5225225``` [over Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/.23.5Bderive.28Default.29.5D.20for.20enums.20with.20fields).
This is contrary to [what the accepted RFC proposes](https://rust-lang.github.io/rfcs/3107-derive-default-enum.html#generated-bounds) (_i.e._, that `T` be allowed not to be itself `Default`), and indeed seems to be a rather unnecessary limitation.
|
|
Fix ICE #101739
Fixes a part of #101739
This cannot cover the following case. It causes `too many args provided` error and obligation does not have references error. I want your advice to solve the following cases as well in this pull request or a follow-up.
```rust
#![crate_type = "lib"]
#![feature(transmutability)]
#![allow(dead_code, incomplete_features, non_camel_case_types)]
mod assert {
use std::mem::BikeshedIntrinsicFrom;
pub fn is_transmutable<
Src,
Dst,
Context,
const ASSUME_ALIGNMENT: bool,
const ASSUME_LIFETIMES: bool,
const ASSUME_VALIDITY: bool,
const ASSUME_VISIBILITY: bool,
>()
where
Dst: BikeshedIntrinsicFrom<
Src,
Context,
ASSUME_ALIGNMENT,
ASSUME_LIFETIMES,
ASSUME_VALIDITY,
ASSUME_VISIBILITY,
>,
{}
}
fn via_const() {
struct Context;
#[repr(C)] struct Src;
#[repr(C)] struct Dst;
const FALSE: bool = false;
assert::is_transmutable::<Src, Dst, Context, FALSE, FALSE, FALSE, FALSE>();
}
```
|
|
Avoid ICE in printing RPITIT type
Fixes #102571
|
|
r=GuillaumeGomez
rustdoc: re-sugar more cross-crate trait bounds
Previously, we would only ever re-sugar cross-crate predicates like `Type: Trait, <Type as Trait>::Name == Rhs` to `Type: Trait<Name = Rhs>` if the `Type` was a generic parameter like `Self` or `T`. With this PR, `Type` can be any type.
Most notably, this means that we now re-sugar predicates involving associated types (where `Type` is of the form `Self::Name`) which are then picked up by the pre-existing logic that re-sugars them into bounds. As a result of that, the associated type `IntoIter` of `std`'s `IntoIterator` trait (re-exported from `core`) is no longer rendered as:
```rust
type IntoIter: Iterator
where
<Self::IntoIter as Iterator>::Item == Self::Item;
```
but as one would expect: `type IntoIter: Iterator<Item = Self::Item>;`.
Cross-crate closure bounds like `F: Fn(i32) -> bool` are now also rendered properly (previously, the return type (`Self::Output`) would not be rendered and we would show the underlying equality predicate).
Fixes #77763.
Fixes #84579.
Fixes #102142.
`@rustbot` label T-rustdoc A-cross-crate-reexports
r? rustdoc
|
|
In #102306, `rustc_typeck` was renamed to `rustc_hir_analysis` but the
diagnostic resources were not renamed - which is what this commit
changes.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
|
|
Fix duplicate usage of `a` article.
This fixes a typo first appearing in #94624 in which test-macro diagnostic uses "a" article twice.
Since I searched the sources for " a a " sequences, I also fixed the same issue in a few files where I found it.
|
|
|
|
|
|
Enable inline stack probes on X86 with LLVM 16
The known problems with x86 inline-asm stack probes have been solved on LLVM main (16), so this flips the switch. Anyone using bleeding-edge LLVM with rustc can start testing this, as I have done locally. We'll get more direct rust-ci when LLVM 16 branches and we start our upgrade, and we can always patch or disable it then if we find new problems.
The previous attempt was #77885, reverted in #84708.
|
|
Get rid of exclude-list for Windows-only tests
Main purpose of this change is to get rid of a quite long (and growing) list of excluded targets, while this test should only be useful on Windows (as far as I understand it). The `// only-windows` header seams to implement exactly what we need here.
I don't know why there are some whitespace changes, but `x.py fmt` and `.git/hooks/pre-push` are happy.
|
|
|
|
|
|
Inspired by <https://old.reddit.com/r/rust/comments/xtiqj8/why_is_this_functional_version_faster_than_my_for/iqqy37b/>.
|
|
|
|
This fixes a typo first appearing in #94624
in which test-macro diagnostic uses "a" article twice.
Since I searched sources for " a a " sequences,
I also fixed the same issue in a few source files where I found it.
Signed-off-by: Petr Portnov <gh@progrm-jarvis.ru>
|
|
Add a known-bug test for #102498
Self-explanatory
|
|
r=Mark-Simulacrum
Do not panic when a test function returns Result::Err.
Rust's test library allows test functions to return a `Result`, so that the test is deemed to have failed if the function returns a `Result::Err` variant. Currently, this works by having `Result` implement the `Termination` trait and asserting in assert_test_result that `Termination::report()` indicates successful completion. This turns a `Result::Err` into a panic, which is caught and unwound in the test library.
This approach is problematic in certain environments where one wishes to save on both binary size and compute resources when running tests by:
* Compiling all code with `--panic=abort` to avoid having to generate unwinding tables, and
* Running most tests in-process to avoid the overhead of spawning new processes.
This change removes the intermediate panic step and passes a `Result::Err` directly through to the test runner.
To do this, it modifies `assert_test_result` to return a `Result<(), String>` where the `Err` variant holds what was previously the panic message. It changes the types in the `TestFn` enum to return `Result<(), String>`.
This tries to minimise the changes to benchmark tests, so it calls `unwrap()` on the `Result` returned by `assert_test_result`, effectively keeping the same behaviour as before.
Some questions for reviewers:
* Does the change to the return types in the enum `TestFn` constitute a breaking change for the library API? Namely, the enum definition is public but the test library indicates that "Currently, not much of this is meant for users" and most of the library API appears to be marked unstable.
* Is there a way to test this change, i.e., to test that no panic occurs if a test returns `Result::Err`?
* Is there a shorter, more idiomatic way to fold `Result<Result<T,E>,E>` into a `Result<T,E>` than the `fold_err` function I added?
|
|
instead of suggesting calling it
|
