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
Move layout_of and friends from rustc_middle to rustc_ty_utils
Breaks up the very large module that is `rustc_middle::ty::layout` by fork-lifting some queries into `rustc_ty_utils::{abi, layout}`.
This does set back `rustc_ty_utils` to having untranslatable diagnostics. I'd like to leave this as a separate task.
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`
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.
Cleanup some error code explanations
E0045: Use a stable non-C ABI instead
E0092: Use an atomic intrinsic that actually exists
E0161: Don't use box_syntax
E0579: Format ranges in the rustfmt style
E0622: Use the rustfmt style
E0743: Remove feature gate as it's not needed
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>();
}
```
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>
E0045: Use a stable non-C ABI instead
E0092: Use an atomic intrinsic that actually exists
E0161: Don't use box_syntax
E0579: Format ranges in the rustfmt style
E0622: Use the rustfmt style
E0743: Remove feature gate as it's not needed
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.
It's now only used in one function. Also, the "should we glue the
tokens?" check is only necessary when pushing a `TokenTree::Token`, not
when pushing a `TokenTree::Delimited`.
As part of this, we now do the "should we glue the tokens?" check
immediately, which avoids having look back at the previous token. It
also puts all the logic dealing with token gluing in a single place.
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>
Rollup of 5 pull requests
Successful merges:
- #100451 (Do not panic when a test function returns Result::Err.)
- #102098 (Use fetch_update in sync::Weak::upgrade)
- #102538 (Give `def_span` the same SyntaxContext as `span_with_body`.)
- #102556 (Make `feature(const_btree_len)` implied by `feature(const_btree_new)`)
- #102566 (Add a known-bug test for #102498)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Give `def_span` the same SyntaxContext as `span_with_body`.
https://github.com/rust-lang/rust/issues/102217
I'm not sure how to add a test, since the erroneous span was crafted using a proc macro.
The debug assertion in `def_span` will ensure we have the correct behaviour.
Declare `main` as visibility hidden on targets that default to hidden.
On targets with `default_hidden_visibility` set, which is currrently just WebAssembly, declare the generated `main` function with visibility hidden. This makes it consistent with clang's WebAssembly target, where `main` is just a user function that gets the same visibility as any other user function, which is hidden on WebAssembly unless explicitly overridden.
This will help simplify use cases which in the future may want to automatically wasm-export all visibility-"default" symbols. `main` isn't intended to be wasm-exported, and marking it hidden prevents it from being wasm-exported in that scenario.
Remove `expr_parentheses_needed` from `ParseSess`
Not sure why this method needed to exist on `ParseSess`, but we can achieve the same behavior by just inlining it everywhere.
Fix `format_args` capture for macro expanded format strings
Since #100996 `format_args` capture for macro expanded strings aren't prevented when the span of the expansion points to a string literal, e.g.
```rust
// not a terribly realistic example, but also happens for proc_macros that set
// the span of the output to an input str literal, such as indoc
macro_rules! x {
($e:expr) => { $e }
}
fn main() {
let a = 1;
println!(x!("{a}"));
}
```
The tests didn't catch it as the span of `concat!()` points to the macro invocation
r? `@m-ou-se`
Move lint level source explanation to the bottom
So, uhhhhh
r? `@estebank`
## User-facing change
"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
- = note: `#[warn(unsupported_calling_conventions)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+ = note: `#[warn(unsupported_calling_conventions)]` on by default
```
Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.
## Developer-facing change
`struct_span_lint` and similar methods have a different signature.
Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)`
After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>`
The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.
Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.
## Subtle problem
By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...
I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.
## P.S.
I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
Group together more size assertions.
Also add a few more assertions for some relevant token-related types.
And fix an erroneous comment in `rustc_errors`.
r? `@lqd`
Flush delayed bugs before codegen
Sometimes it can happen that invalid code like a TyKind::Error makes its way through the compiler without triggering any errors (this is always a bug in rustc but bugs do happen sometimes :)). These ICEs will manifest in the backend like as cg_llvm not being able to get the layout of `[type error]`, which makes it hard to debug. By flushing before codegen, we display all the delayed bugs, making it easier to trace it to the root of the problem.
I tried this on #102366 and it showed tons of of delayed bugs and no error in cg_llvm, so it seems to be working.
