This commit adds new methods that combine sequences of existing
formatting methods.
- `Formatter::debug_{tuple,struct}_field[12345]_finish`, equivalent to a
`Formatter::debug_{tuple,struct}` + N x `Debug{Tuple,Struct}::field` +
`Debug{Tuple,Struct}::finish` call sequence.
- `Formatter::debug_{tuple,struct}_fields_finish` is similar, but can
handle any number of fields by using arrays.
These new methods are all marked as `doc(hidden)` and unstable. They are
intended for the compiler's own use.
Special-casing up to 5 fields gives significantly better performance
results than always using arrays (as was tried in #95637).
The commit also changes the `Debug` deriving code to use these new methods. For
example, where the old `Debug` code for a struct with two fields would be like
this:
```
fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
match *self {
Self {
f1: ref __self_0_0,
f2: ref __self_0_1,
} => {
let debug_trait_builder = &mut ::core::fmt::Formatter::debug_struct(f, "S2");
let _ = ::core::fmt::DebugStruct::field(debug_trait_builder, "f1", &&(*__self_0_0));
let _ = ::core::fmt::DebugStruct::field(debug_trait_builder, "f2", &&(*__self_0_1));
::core::fmt::DebugStruct::finish(debug_trait_builder)
}
}
}
```
the new code is like this:
```
fn fmt(&self, f: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
match *self {
Self {
f1: ref __self_0_0,
f2: ref __self_0_1,
} => ::core::fmt::Formatter::debug_struct_field2_finish(
f,
"S2",
"f1",
&&(*__self_0_0),
"f2",
&&(*__self_0_1),
),
}
}
```
This shrinks the code produced for `Debug` instances
considerably, reducing compile times and binary sizes.
Co-authored-by: Scott McMurray <scottmcm@users.noreply.github.com>
implement `iter_projections` function on `PlaceRef`
this makes the api more flexible. the original function now calls the PlaceRef
version to avoid duplicating the code.
Update no_default_libraries handling for emscripten target
```@sbc100``` says:
> `-sDEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]` is almost certainly wrong/out-of-date. This setting defaults to the empty list anyway these days so its redundant. Also we now support `-nodefaultlibs` so you can use that, as with other toolchains.
https://github.com/rust-lang/rust/issues/98303#issuecomment-1162163684
Migrate two diagnostics from the `rustc_builtin_macros` crate
Migrate two diagnostics to use the struct derive and be translatable.
r? ```@davidtwco```
Provide a `PathSegment.res` in more cases
I find that in many cases, the `res` associated with a `PathSegment` is `Res::Err` even though the path was fully resolved. A few diagnostics use this `res` and their error messages suffer because of the lack of resolved segment.
This fixes it a bit, but it's obviously not complete and I'm not exactly sure if it's correct.
Greatly improve error reporting for futures and generators in `note_obligation_cause_code`
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
Helps with https://github.com/rust-lang/rust/issues/97332.
r? ``@estebank`` cc ``@eholk`` ``@compiler-errors``
In fc357039f9 `#[main]` was removed and replaced with `#[rustc_main]`.
In some place the rename was forgotten, which makes the current code
confusing, because at first glance it seems that `#[main]` is still
around. Perform the renames also in these places.
Older llvm has the pre-C++17 restriction on success and failure memory
ordering, requiring the former to be at least as strong as the latter.
So, for llvm 12, this upgrades the success ordering to a stronger one if
necessary.
Create elided lifetime parameters for function-like types
Split from https://github.com/rust-lang/rust/pull/97720
This PR refactor lifetime generic parameters in bare function types and parenthesized traits to introduce the additional required lifetimes as fresh parameters in a `for<>` bound.
This PR does the same to lifetimes appearing in closure signatures, and as-if introducing `for<>` bounds on closures (without the associated change in semantics).
r? `@petrochenkov`
Point at return expression for RPIT-related error
Certainly this needs some diagnostic refining, but I wanted to show that it was possible first and foremost. Not sure if this is the right approach. Open to feedback.
Fixes#80583
use `def_ident_span` , `body_owner_def_id` instead of `in_progress_typeck_results`, `guess_head_span`
use `body_id.owner` directly
add description to label
This comment is out dated and misleading, the arm is about TAITs
r? ```@oli-obk```
```@oli-obk``` unsure if you want to add a different comment of some sort.
```@bors``` rollup=always
Remove the unused-`#[doc(hidden)]` logic from the `unused_attributes` lint
Fixes#96890.
It was found out that `#[doc(hidden)]` on trait impl items does indeed have an effect on the generated documentation (see the linked issue). In my opinion and the one of [others](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60/near/281846219), rustdoc's output is actually a bit flawed in that regard but that should be tracked in a new issue I suppose (I will open an issue for that in the near future).
The check was introduced in #96008 which is marked to be part of version `1.62` (current `beta`). As far as I understand, this means that **this PR needs to be backported** to `beta` to fix#96890 on time. Correct me if I am wrong.
CC `@dtolnay` (in case you would like to agree or disagree with my decision to fully remove this check)
`@rustbot` label A-lint T-compiler T-rustdoc
r? `@rust-lang/compiler`
lub: don't bail out due to empty binders
allows for the following to compile. The equivalent code using `struct Wrapper<'upper>(fn(&'upper ());` already compiles on stable.
```rust
let _: fn(&'upper ()) = match v {
true => lt_in_fn::<'a>(),
false => lt_in_fn::<'b>(),
};
```
see https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7034a677190110941223cafac6632f70 for a complete example
r? ```@rust-lang/types```
#91318 introduced a trait for infallible folders distinct from the fallible version. For some reason (completely unfathomable to me now that I look at it with fresh eyes), the infallible trait was a supertrait of the fallible one: that is, all fallible folders were required to also be infallible. Moreover the `Error` associated type was defined on the infallible trait! It's so absurd that it has me questioning whether I was entirely sane.
This trait reverses the hierarchy, so that the fallible trait is a supertrait of the infallible one: all infallible folders are required to also be fallible (which is a trivial blanket implementation). This of course makes much more sense! It also enables the `Error` associated type to sit on the fallible trait, where it sensibly belongs.
There is one downside however: folders expose a `tcx` accessor method. Since the blanket fallible implementation for infallible folders only has access to a generic `F: TypeFolder`, we need that trait to expose such an accessor to which we can delegate. Alternatively it's possible to extract that accessor into a separate `HasTcx` trait (or similar) that would then be a supertrait of both the fallible and infallible folder traits: this would ensure that there's only one unambiguous `tcx` method, at the cost of a little additional boilerplate. If desired, I can submit that as a separate PR.
r? @jackh726
Remove the source archive functionality of ArchiveWriter
We now build archives through strictly additive means rather than taking an existing archive and potentially substracting parts. This is simpler and makes it easier to swap out the archive writer in https://github.com/rust-lang/rust/pull/97485.
`try_fold_unevaluated` for infallible folders
#97447 added folding of unevaluated constants, but did not include an override of the default (fallible) operation in the blanket impl of `FallibleTypeFolder` for infallible folders. Here we provide that missing override.
r? ```@nnethercote```
Fix erroneous span for borrowck error
I am not confident that this is the correct fix, but it does the job. Open to suggestions for a real fix instead.
Fixes#97997
The issue is that we pass a [dummy location](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_middle/mir/visit.rs.html#302) when type-checking the ["required consts"](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.required_consts) that are needed by the MIR body during borrowck. This means that when we fail to evaluate the constant, we use the span of `bb0[0]`, instead of the actual span of the constant.
There are quite a few other places that use `START_BLOCK.start_location()`, `Location::START`, etc. when calling for a random/unspecified `Location` value. This is because, unlike (for example) `Span`, we don't have a dummy/miscellaneous value to use instead. I would appreciate guidance (either in this PR, or a follow-up) on what needs to be done to clean this up in general.
Add proper tracing spans to rustc_trait_selection::traits::error_reporting
While I was trying to figure out #97704 I did some of this to make the logs more legible, so I figured I'd do the whole module and open a PR with it. afaict this is an ongoing process in the compiler from the log->tracing transition? but lmk if there was a reason for the more verbose forms of logging as they are.
Also, for some of the functions with only one log in them, I put the function name as a message for that log instead of `#[instrument]`-ing the whole function with a span? but maybe the latter would actually be preferable, I'm not actually sure.
Remove dereferencing of Box from codegen
Through #94043, #94414, #94873, and #95328, I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However, these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains.
Hopefully, this is the end of the Box<T, A> ICEs.
Mention formatting macros when encountering `ArgumentV1` method in const
Also open to just closing this if it's overkill. There are a lot of other distracting error messages around, so maybe it's not worth fixing just this one.
Fixes#93665
Don't omit comma when suggesting wildcard arm after macro expr
* Also adds `Span::eq_ctxt` to consolidate the various usages of `span.ctxt() == other.ctxt()`
* Also fixes an unhygenic usage of spans which caused the suggestion to render weirdly when we had one arm match in a macro
* Also always suggests a comma (i.e. even after a block) if we're rendering a wildcard arm in a single-line match (looks prettier 🌹)
Fixes#94866
Drop magic value 3 from code
Magic value 3 is used to create state for a yield point. It is in fact
the number of reserved variants.
Lift RESERVED_VARIANTS out to module scope and use it instead.
#97447 added folding of unevaluated constants, but did not include an override of the default (fallible) operation in the blanket impl of `FallibleTypeFolder` for infallible folders. Here we provide that missing override.
r? @nnethercote
Include ForeignItem when visiting types for WF check
Addresses Issue 95665 by including `hir::Node::ForeignItem` as a valid
type to visit in `diagnostic_hir_wf_check`.
Fixes#95665
Magic value 3 is used to create state for a yield point. It is in fact
the number of reserved variants.
Lift RESERVED_VARIANTS out to module scope and use it instead.
Fix pretty printing of empty bound lists in where-clause
Repro:
```rust
macro_rules! assert_item_stringify {
($item:item $expected:literal) => {
assert_eq!(stringify!($item), $expected);
};
}
fn main() {
assert_item_stringify! {
fn f<'a, T>() where 'a:, T: {}
"fn f<'a, T>() where 'a:, T: {}"
}
}
```
Previously this assertion would fail because rustc renders the where-clause as `where 'a, T` which is invalid syntax.
This PR makes the above assertion pass.
This bug also affects `-Zunpretty=expanded`. The intention is for that to emit syntactically valid code, but the buggy output is not valid Rust syntax.
```console
$ rustc <(echo "fn f<'a, T>() where 'a:, T: {}") -Zunpretty=expanded
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
fn f<'a, T>() where 'a, T {}
```
```console
$ rustc <(echo "fn f<'a, T>() where 'a:, T: {}") -Zunpretty=expanded | rustc -
error: expected `:`, found `,`
--> <anon>:7:23
|
7 | fn f<'a, T>() where 'a, T {}
| ^ expected `:`
```
Make missing argument placeholder more obvious that it's a placeholder
Use `/* ty */` instead of `{ty}`, since people might be misled into thinking that this is valid syntax, and not just a diagnostic placeholder.
Fixes#96880
Both functions do some modifying of streams using `make_mut`:
- `push` sometimes glues the first token of the next stream to the last
token of the first stream.
- `build` appends tokens to the first stream.
By doing all of this in the one place, things are simpler. The first
stream can be modified in both ways (if necessary) in the one place, and
any next stream with the first token removed doesn't need to be stored.
Fix `SourceScope` for `if let` bindings.
Fixes#97799.
I'm not sure how to test this properly, is there any way to observe the difference in behavior apart from `ui` tests? I'm worried that they would be overlooked in the case of a regression.
It's a weird function: it lets you modify the token stream in the middle
of iteration. There is only one call site, and it is only used for the
rare `ProceduralMasquerade` legacy case.
Make debug_triple depend on target json file content rather than file path
This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.
This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``
