David Wood [Mon, 11 Jul 2022 17:46:24 +0000 (18:46 +0100)]
macros: support adding warnings to diags
Both diagnostic and subdiagnostic derives were missing the ability to
add warnings to diagnostics - this is made more difficult by the `warn`
attribute already existing, so this name being unavailable for the
derives to use. `#[warn_]` is used instead, which requires
special-casing so that `{span_,}warn` is called instead of
`{span_,}warn_`.
David Wood [Mon, 11 Jul 2022 16:15:31 +0000 (17:15 +0100)]
macros: support `MultiSpan` in diag derives
Add support for `MultiSpan` with any of the attributes that work on a
`Span` - requires that diagnostic logic generated for these attributes
are emitted in the by-move block rather than the by-ref block that they
would normally have been generated in.
David Wood [Mon, 11 Jul 2022 15:28:38 +0000 (16:28 +0100)]
errors: impl `IntoDiagnosticArg` for `char`
Implements `IntoDiagnosticArg` for `char` using its `Debug`
implementation and introduces a macro for those types which just
delegate the implementation to `ToString`.
Auto merge of #99278 - Dylan-DPC:rollup-fcln6st, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #88991 (Add Nintendo Switch as tier 3 target)
- #98869 (Remove some usages of `guess_head_span`)
- #99119 (Refactor: remove a string matching about methods)
- #99209 (Correctly handle crate level page on docs.rs as well)
- #99246 (Update RLS)
Rollup merge of #99209 - GuillaumeGomez:crate-level-sidebar, r=jsha
Correctly handle crate level page on docs.rs as well
Fixes #99121.
On docs.rs, they move the `class` attribute into a child which still has `rustdoc`. So instead of using the `<body>`, we can simply use this one directly.
This is the first step towards working on incrementally adding support for the Nintendo Switch. After this lands `@leo60228` and I will work on ensuring further work is cleared from a legal perspective before continuing on to work on an allocator and porting libstd.
The plan is to keep these changes small and incremental enough so as to not cause unneeded burden on reviewers by submitting a single large patch, as was felt to be the case last attempt at upstreaming (#74567).
All this specific patch does is add the target itself without and std support, which has been tested on-device and is working as expected.
Auto merge of #99013 - RalfJung:dont-poison-my-places, r=oli-obk
interpret: get rid of MemPlaceMeta::Poison
This is achieved by refactoring the projection code (`{mplace,place,operand}_{downcast,field,index,...}`) so that we no longer need to call `assert_mem_place` in the operand handling.
Auto merge of #99267 - Dylan-DPC:rollup-d8l7y1o, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #99113 (Simplify [a]rc code a little)
- #99131 (Add label for generic arg (+ APIT) and RPIT callables in `label_fn_like`)
- #99237 (removed unused CSS and unused HTML IDs)
- #99239 (Add myself to the set of people notified when MIR changes.)
- #99241 (Remove comment referring to constness.rs)
- #99257 (Add regression test for #89436)
Rollup merge of #99257 - Manishearth:regression, r=jackh726
Add regression test for #89436
I never got around to adding such a test.
In general I think the `yoke` crate has a bunch of interesting testcases that exercise various edges of the algorithms here, it would be nice if we could simply depend on the crate and add some tests that exercise it, but I don't think that's possible. Do you or `@eddyb` think there's any use trying to upstream a bunch of common yoke minimal working example code to the testsuite and having a ton of yoke tests?
Auto merge of #96544 - m-ysk:feature/issue-96358, r=cjgillot
Stop keeping metadata in memory before writing it to disk
Fixes #96358
I created this PR according with the instruction given in the issue except for the following points:
- While the issue says "Write metadata into the temporary file in `encode_and_write_metadata` even if `!need_metadata_file`", I could not do that. That is because though I tried to do that and run `x.py test`, I got a lot of test failures as follows.
fix dwarf debuginfo being used in addition to CodeView on windows
Tackles the debuginfo size increase regression on windows to [unblock clippy](https://github.com/rust-lang/rust/issues/99143#issuecomment-1184638573) -- introduced by the DWARF5 support in #98350 cc `@pcwalton.`
Auto merge of #99242 - Dylan-DPC:rollup-34bqdh8, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #98072 (Add provider API to error trait)
- #98580 (Emit warning when named arguments are used positionally in format)
- #99000 (Move abstract const to middle)
- #99192 (Fix spans for asm diagnostics)
- #99222 (Better error message for generic_const_exprs inference failure)
- #99236 (solaris: unbreak build on native platform)
Rollup merge of #99222 - atsuzaki:generic_const_err, r=lcnr
Better error message for generic_const_exprs inference failure
Fixes #90531
This code:
```rs
#![feature(generic_const_exprs)]
fn foo<const N: usize>(_arr: [u64; N + 1]) where [u64; N + 1]: {}
fn main() {
let arr = [5; 5];
foo(arr);
}
```
Will now emit the following error:
```rs
warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes
--> test.rs:1:12
|
1 | #![feature(generic_const_exprs)]
| ^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(incomplete_features)]` on by default
= note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information
error[E0284]: type annotations needed
--> test.rs:8:7
|
8 | foo(arr);
| ^^^ cannot infer the value of the const parameter `N` declared on the function `foo`
|
note: required by a bound in `foo`
--> test.rs:3:56
|
3 | fn foo<const N: usize>(_arr: [u64; N + 1]) where [u64; N + 1]: {}
| ^^^^^ required by this bound in `foo`
help: consider specifying the generic argument
|
8 | foo::<N>(arr);
| +++++
error: aborting due to previous error; 1 warning emitted
```
cc: `@lcnr` thanks a lot again for the help on this
Rollup merge of #99000 - JulianKnodt:allow_resolve_no_substs, r=lcnr
Move abstract const to middle
Moves AbstractConst (and all associated methods) to rustc middle for use in `rustc_infer`.
This allows for const resolution in infer to use abstract consts to walk consts and check if
they are resolvable.
This attempts to resolve the issue where `Foo<{ concrete const }, generic T>` is incorrectly marked as conflicting, and is independent from the other issue where nested abstract consts must be resolved.
Rollup merge of #98580 - PrestonFrom:issue_98466, r=estebank
Emit warning when named arguments are used positionally in format
Addresses Issue 98466 by emitting an error if a named argument
is used like a position argument (i.e. the name is not used in
the string to be formatted).
Auto merge of #95956 - yaahc:stable-in-unstable, r=cjgillot
Support unstable moves via stable in unstable items
part of https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/moving.20items.20to.20core.20unstably and a blocker of https://github.com/rust-lang/rust/pull/90328.
The libs-api team needs the ability to move an already stable item to a new location unstably, in this case for Error in core. Otherwise these changes are insta-stable making them much harder to merge.
This PR attempts to solve the problem by checking the stability of path segments as well as the last item in the path itself, which is currently the only thing checked.
Auto merge of #99231 - Dylan-DPC:rollup-0tl8c0o, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #97720 (Always create elided lifetime parameters for functions)
- #98315 (Stabilize `core::ffi:c_*` and rexport in `std::ffi`)
- #98705 (Implement `for<>` lifetime binder for closures)
- #99126 (remove allow(rustc::potential_query_instability) in rustc_span)
- #99139 (Give a better error when `x dist` fails for an optional tool)
Rollup merge of #99139 - jyn514:dist-tool-help, r=Mark-Simulacrum
Give a better error when `x dist` fails for an optional tool
Before:
```
thread 'main' panicked at 'Unable to build RLS', dist.rs:42:9
```
After:
```
thread 'main' panicked at 'Unable to build submodule tool RLS (use `missing-tools = true` to ignore this failure)
note: not all tools are available on all nightlies
help: see https://forge.rust-lang.org/infra/toolstate.html for more information', dist.rs:43:9
```
Closes https://github.com/rust-lang/rust/issues/85683 by explaining better why the error is expected.
Rollup merge of #98315 - joshtriplett:stabilize-core-ffi-c, r=Mark-Simulacrum
Stabilize `core::ffi:c_*` and rexport in `std::ffi`
This only stabilizes the base types, not the non-zero variants, since
those have their own separate tracking issue and have not gone through
FCP to stabilize.
Rollup merge of #97720 - cjgillot:all-fresh, r=petrochenkov
Always create elided lifetime parameters for functions
Anonymous and elided lifetimes in functions are sometimes (async fns) --and sometimes not (regular fns)-- desugared to implicit generic parameters.
This difference of treatment makes it some downstream analyses more complicated to handle. This step is a pre-requisite to perform lifetime elision resolution on AST.
There is currently an inconsistency in the treatment of argument-position impl-trait for functions and async fns:
```rust
trait Foo<'a> {}
fn foo(t: impl Foo<'_>) {} //~ ERROR missing lifetime specifier
async fn async_foo(t: impl Foo<'_>) {} //~ OK
fn bar(t: impl Iterator<Item = &'_ u8>) {} //~ ERROR missing lifetime specifier
async fn async_bar(t: impl Iterator<Item = &'_ u8>) {} //~ OK
```
The current implementation reports "missing lifetime specifier" on `foo`, but **accepts it** in `async_foo`.
This PR **proposes to accept** the anonymous lifetime in both cases as an extra generic lifetime parameter.
This change would be insta-stable, so let's ping t-lang.
Anonymous lifetimes in GAT bindings keep being forbidden:
```rust
fn foo(t: impl Foo<Assoc<'_> = Bar<'_>>) {}
^^ ^^
forbidden ok
```
I started a discussion here: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Anonymous.20lifetimes.20in.20universal.20impl-trait/near/284968606
Auto merge of #99225 - ehuss:update-cargo, r=ehuss
Update cargo
7 commits in b1dd22e668af5279e13a071ad4b17435bd6bfa4c..8827baaa781b37872134c1ba692a6f0aeb37890e
2022-07-09 14:48:50 +0000 to 2022-07-14 02:56:51 +0000
- Add a test for regressions in selecting the correct workspace root (rust-lang/cargo#10862)
- clarify profile used for 'cargo install --debug' (rust-lang/cargo#10861)
- servers should use 404 (rust-lang/cargo#10860)
- test(add): Ensure comments are preserved (rust-lang/cargo#10849)
- Fix nested workspace resolution (rust-lang/cargo#10846)
- Small tweaks to the future-incompat docs. (rust-lang/cargo#10856)
- Fixed extra period typo (rust-lang/cargo#10847)
Josh Triplett [Mon, 20 Jun 2022 20:59:58 +0000 (13:59 -0700)]
Stabilize `core::ffi:c_*` and rexport in `std::ffi`
This only stabilizes the base types, not the non-zero variants, since
those have their own separate tracking issue and have not gone through
FCP to stabilize.
Auto merge of #98754 - jyn514:non-trivial-drop, r=compiler-errors
Fix drop-tracking ICE when a struct containing a field with a significant drop is used across an await
Previously, drop-tracking would incorrectly assume the struct would be dropped immediately, which was not true.
Fixes #98476. Also fixes https://github.com/rust-lang/rust/issues/98477, I think because the parent HIR node for type variables is the whole function instead of the expression where the variable is used.
Auto merge of #97995 - RalfJung:union-more-nodrop, r=Mark-Simulacrum
allow unions with mutable references and tuples of allowed types
We currently allow shared references in unions, but not mutable references. That seems somewhat inconsistent. So let's allow all references, and while we are at it, let's make sure the set of allowed types is closed under tuples.
This will need T-lang FCP (at least).
Then remove the `tagged_unions` feature, since we do not plan to stabilize any more of it.
Closes https://github.com/rust-lang/rust/issues/55149
projects / rust.git / log