| Age | Commit message (Collapse) | Author | Lines |
|---|
|
adapt assembly/static-relocation-model test for LLVM change
After https://github.com/llvm/llvm-project/commit/f0dd12ec5c0169ba5b4363b62d59511181cf954a LLVM emits `movzbl` instead. Adapted this test case accordingly.
Discovered in our experimental rust + llvm at head ci:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/12104#0182195b-8791-4f88-853c-bb23a1e4b54c
|
|
rustdoc UI fixes
The first commit fixes this bug:
The second one fixes the missing change of border color when the search input is focused.
cc `@jsha`
r? `@notriddle`
|
|
compiletest: Allow using revisions with debuginfo tests.
A small wart that came up in https://github.com/rust-lang/rust/pull/95685#issuecomment-1089184951.
|
|
Diagnostic width span is not added when '0$' is used as width in format strings
When the following code is run rustc does not add diagnostic spans for the width argument. Such spans are necessary for a clippy lint that I am currently writing.
```rust
println!("Hello {1:0$}!", 5, "x");
// ^^
// Should have a span here
```
|
|
r=petrochenkov
better error for bad depth parameter on macro metavar expr
Fixes #99060
|
|
r=spastorino
Use `typeck_results` to avoid duplicate `ast_ty_to_ty` call
Comes with a bunch of improvements in spans :heart_eyes:
|
|
introduce `implied_by` in `#[unstable]` attribute
Requested by the library team [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/better.20support.20for.20partial.20stabilizations/near/285581519).
If part of a feature is stabilized and a new feature is added for the remaining parts, then the `implied_by` meta-item can be added to `#[unstable]` to indicate which now-stable feature was used previously.
```diagnostic
error: the feature `foo` has been partially stabilized since 1.62.0 and is succeeded by the feature `foobar`
--> $DIR/stability-attribute-implies-using-unstable.rs:3:12
|
LL | #![feature(foo)]
| ^^^
|
note: the lint level is defined here
--> $DIR/stability-attribute-implies-using-stable.rs:2:9
|
LL | #![deny(stable_features)]
| ^^^^^^^^^^^^^^^
help: if you are using features which are still unstable, change to using `foobar`
|
LL | #![feature(foobar)]
| ~~~~~~
help: if you are using features which are now stable, remove this line
|
LL - #![feature(foo)]
|
```
When a `#![feature(..)]` attribute still exists for the now-stable attribute, then there this has two effects:
- There will not be an stability error for uses of items from the implied feature which are still unstable (until the `#![feature(..)]` is removed or updated to the new feature).
- There will be an improved diagnostic for the remaining use of the feature attribute for the now-stable feature.
```rust
/// If part of a feature is stabilized and a new feature is added for the remaining parts,
/// then the `implied_by` attribute is used to indicate which now-stable feature previously
/// contained a item.
///
/// ```pseudo-Rust
/// #[unstable(feature = "foo", issue = "...")]
/// fn foo() {}
/// #[unstable(feature = "foo", issue = "...")]
/// fn foobar() {}
/// ```
///
/// ...becomes...
///
/// ```pseudo-Rust
/// #[stable(feature = "foo", since = "1.XX.X")]
/// fn foo() {}
/// #[unstable(feature = "foobar", issue = "...", implied_by = "foo")]
/// fn foobar() {}
/// ```
```
In the Zulip discussion, this was envisioned as `implies` on `#[stable]` but I went with `implied_by` on `#[unstable]` because it means that only the unstable attribute needs to be changed in future, not the new stable attribute, which seems less error-prone. It also isn't particularly feasible for me to detect whether items from the implied feature are used and then only suggest updating _or_ removing the `#![feature(..)]` as appropriate, so I always do both.
There's some new information in the cross-crate metadata as a result of this change, that's a little unfortunate, but without requiring that the `#[unstable]` and `#[stable]` attributes both contain the implication information, it's necessary:
```rust
/// This mapping is necessary unless both the `#[stable]` and `#[unstable]` attributes should
/// specify their implications (both `implies` and `implied_by`). If only one of the two
/// attributes do (as in the current implementation, `implied_by` in `#[unstable]`), then this
/// mapping is necessary for diagnostics. When a "unnecessary feature attribute" error is
/// reported, only the `#[stable]` attribute information is available, so the map is necessary
/// to know that the feature implies another feature. If it were reversed, and the `#[stable]`
/// attribute had an `implies` meta item, then a map would be necessary when avoiding a "use of
/// unstable feature" error for a feature that was implied.
```
I also change some comments to documentation comments in the compiler, add a helper for going from a `Span` to a `Span` for the entire line, and fix a incorrect part of the pre-existing stability attribute diagnostics.
cc `@yaahc`
|
|
Add a check confirming that features referenced in `implied_by` meta
items actually exist.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Improves the diagnostic when a feature attribute is specified
unnecessarily but the feature implies another (i.e. it was partially
stabilized) to refer to the implied feature.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
If part of a feature is stabilized and a new feature is added for the
remaining parts, then the `implied_by` attribute can be used to indicate
which now-stable feature previously contained a item. If the now-stable
feature is still active (if the user has only just updated rustc, for
example) then there will not be an stability error for uses of the item
from the implied feature.
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
Rollup of 7 pull requests
Successful merges:
- #98101 (stdlib support for Apple WatchOS)
- #99345 (Do not allow typeck children items to constrain outer RPITs)
- #99383 (Formalize defining_use_anchor)
- #99436 (Add flag to configure `noalias` on `Box<T>`)
- #99483 (Fix a numerical underflow in tuple wrap suggestion)
- #99485 (Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations)
- #99486 (Refactor: remove a string comparison between types in `check_str_addition`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
After
https://github.com/llvm/llvm-project/commit/f0dd12ec5c0169ba5b4363b62d59511181cf954a,
LLVM emits `movzbl` instead. Adapted this test case accordingly.
Discovered in our experimental rust + llvm at head ci:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/12104#0182195b-8791-4f88-853c-bb23a1e4b54c
|
|
|
|
Stop injecting `#[allow(unused_qualifications)]` in generated `derive` implementations
Currently, the `#[derive]` attribute always injects an `#[allow(unused_qualifications)]` attribute in the generated implementation. This results in an error when a derive is used in combination with `#![forbid(unused_qualifications)]`, because the `forbid` rule by definition cannot be overridden by `allow`.
It appears that the original issue that prompted the inclusion of `#[allow(unused_qualifications)]` (#19102) is no longer present in the current stable release, and the associated [test case](https://github.com/rust-lang/rust/blob/master/src/test/ui/issues/issue-19102.rs) still passes, so the `allow` is simply removed here.
Fixes #71898.
|
|
Fix a numerical underflow in tuple wrap suggestion
Fixes #99482
I'm a clown, I rewrote the arg mismatch algo to use well-typed indices to avoid things like this, but then I added my own indexing bug, lol.
|
|
Add flag to configure `noalias` on `Box<T>`
The aliasing rules of `Box<T>` are still not decided, but currently, `Box<T>` is unique and gets `noalias`. To aid making an informed decision about the future of `Box<T>`, this PR adds a flag `-Zbox-noalias` to configure `noalias` for `Box<T>` (for example, for benchmarking). The same flag already exists for `&mut T` `noalias`, where it was added because it was the problem of various miscompilations in LLVM.
For more information, see rust-lang/unsafe-code-guidelines#326
|
|
Formalize defining_use_anchor
This tackles issue #57961
Introduces new enum called `DefiningAnchor` that replaces `Option<LocalDefId>` of `defining_use_anchor`. Now every use of it is explicit and exhaustively matched, catching errors like one in the linked issue. This is not a perfect fix but it's a step in the right direction.
r? `@oli-obk`
|
|
Do not allow typeck children items to constrain outer RPITs
Fixes #99073 in a simpler and more conservative way than #99079. Simply raise a mismatched types error if we try to constrain an RPIT in an item that isn't the RPIT's parent.
r? `@oli-obk`
|
|
Revert "Rollup merge of #98582 - oli-obk:unconstrained_opaque_type, r…
…=estebank"
This reverts commit 6f8fb911ad504b77549cf3256a09465621beab9d, reversing
changes made to 7210e46dc69a4b197a313d093fe145722c248b7d.
r? `@ghost`
rebase of https://github.com/rust-lang/rust/pull/99368
|
|
When an unexpected meta item is provided to `#[stable]`, the diagnostic
lists "since" and "note" as expected meta-items, however the surrounding
code actually expects "feature" and "since".
Signed-off-by: David Wood <david.wood@huawei.com>
|
|
|
|
|
|
This reverts commit 6f8fb911ad504b77549cf3256a09465621beab9d, reversing
changes made to 7210e46dc69a4b197a313d093fe145722c248b7d.
|
|
|
|
Add regression test for #71547
Closes #71547
r? `@compiler-errors`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Erase regions before comparing signatures of foreign fns.
Fixes https://github.com/rust-lang/rust/issues/99276
The version with explicit lifetimes is probably tracked in another bug, but I could not find it.
|
|
Suggest returning local on "expected `ty`, found `()`" due to expr-less block
Putting this up for _initial_ review. Notably, this doesn't consider if the value has possibly been moved, or whether the type is `Copy`. It also provides a structured suggestion if there's one "preferred" binding that matches the type (i.e. one binding in the block or its parent), otherwise it just points them out if there's fewer than 4 of them.
Fixes #98177
r? `@estebank`
|
|
coerce_forced_unit error
|
|
|
|
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
r=petrochenkov,GuillaumeGomez
Improve the function pointer docs
This is #97842 but for function pointers instead of tuples. The concept is basically the same.
* Reduce duplicate impls; show `fn (T₁, T₂, …, Tₙ)` and include a sentence saying that there exists up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.
https://notriddle.com/notriddle-rustdoc-test/std/primitive.fn.html
|
|
|
|
|
|
|
|
* Reduce duplicate impls; show only the `fn (T)` and include a sentence
saying that there exists up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.
|
|
To aid making an informed decision about the aliasing
rules of box, give users an option to remove `noalias`
from box.
|
|
use `par_for_each_in` in `par_body_owners` and `collect_crate_mono_items`
Using `par_iter` in non-parallel mode will cause the entire process to abort when any iteration panics. So we can use `par_for_each_in` instead to make the error message consistent with parallel mode. This means that the compiler will output more error messages in some cases. This fixes the following ui tests when set `parallel-compiler = true`:
```
[ui] src/test\ui\privacy\privacy2.rs
[ui] src/test\ui\privacy\privacy3.rs
[ui] src/test\ui\type_length_limit.rs
```
This refers to #68171
Updates #75760
|
|
Improve suggestions for `NonZeroT` <- `T` coercion error
Currently, when encountering a type mismatch error with `NonZeroT` and `T` (for example `NonZeroU8` and `u8`) we errorneusly suggest wrapping expression in `NonZeroT`:
```text
error[E0308]: mismatched types
--> ./t.rs:7:35
|
7 | let _: std::num::NonZeroU64 = 1;
| -------------------- ^ expected struct `NonZeroU64`, found integer
| |
| expected due to this
|
help: try wrapping the expression in `std::num::NonZeroU64`
|
7 | let _: std::num::NonZeroU64 = std::num::NonZeroU64(1);
| +++++++++++++++++++++ +
```
I've removed this suggestion and added suggestions to call `new` (for `Option<NonZeroT>` <- `T` case) or `new` and `unwrap` (for `NonZeroT` <- `T` case):
```text
error[E0308]: mismatched types
--> ./t.rs:7:35
|
7 | let _: std::num::NonZeroU64 = 1;
| -------------------- ^ expected struct `NonZeroU64`, found integer
| |
| expected due to this
|
help: Consider calling `NonZeroU64::new`
|
7 | let _: std::num::NonZeroU64 = NonZeroU64::new(1).unwrap();
| ++++++++++++++++ ++++++++++
error[E0308]: mismatched types
--> ./t.rs:8:43
|
8 | let _: Option<std::num::NonZeroU64> = 1;
| ---------------------------- ^ expected enum `Option`, found integer
| |
| expected due to this
|
= note: expected enum `Option<NonZeroU64>`
found type `{integer}`
help: Consider calling `NonZeroU64::new`
|
8 | let _: Option<std::num::NonZeroU64> = NonZeroU64::new(1);
| ++++++++++++++++ +
```
r? `@compiler-errors`
|
|
Revert "Stabilize $$ in Rust 1.63.0"
This mechanically reverts commit 9edaa76adce4de737db54194eb13d6c298827b37, the one commit from #95860.
https://github.com/rust-lang/rust/issues/99035; the behavior of `$$crate` is potentially unexpected and not ready to be stabilized. https://github.com/rust-lang/rust/pull/99193 attempts to forbid `$$crate` without also destabilizing `$$` more generally.
`@rustbot` modify labels +T-compiler +T-lang +P-medium +beta-nominated +relnotes
(applying the labels I think are accurate from the issue and alternative partial revert)
cc `@Mark-Simulacrum`
|
|
use body's param-env when checking if type needs drop
The type comes from the body, so we should be using the body's param-env, as opposed to the ADT's param env, because we know less in the latter compared to the former.
Fixes #99375
|
|
Add E0790 as more specific variant of E0283
Fixes #81701
I think this should be good to go, there are only two things where I am somewhat unsure:
- Is there a better way to get the fully-qualified path for the suggestion? I tried `self.tcx.def_path_str`, but that didn't seem to always give a correct path for the context.
- Should all this be extracted into it's own method or is it fine where it is?
r? `@estebank`
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #97183 (wf-check generators)
- #98320 (Mention first and last macro in backtrace)
- #99335 (Use split_once in FromStr docs)
- #99347 (Use `LocalDefId` in `OpaqueTypeKey`)
- #99392 (Fix debuginfo tests.)
- #99404 (Use span_bug for unexpected field projection type)
- #99410 (Update invalid atomic ordering lint)
- #99434 (Fix `Skip::next` for non-fused inner iterators)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Update invalid atomic ordering lint
The restriction that success ordering must be at least as strong as its
failure ordering in compare-exchange operations was lifted in #98383.
|
|
Fix debuginfo tests.
This is needed for my Ubuntu 22.04 box due to a slight change in gdb
output. The fix is similar to the fix in #95063.
|
|
Mention first and last macro in backtrace
Slight improvement to diagnostic mentioning what macro an error originates from. Not sure if it's worthwhile.
|
|
wf-check generators
fixes #90409
We should not rely on generators being well formed by construction now that they can get used via type alias impl trait (and thus users can choose generic arguments that are invalid). This can cause surprising behaviour if (definitely unsound) transmutes are used, and it's generally saner to just check for well formedness.
|
|
proc_macro/bridge: stop using a remote object handle for proc_macro Ident and Literal
This is the fourth part of https://github.com/rust-lang/rust/pull/86822, split off as requested in https://github.com/rust-lang/rust/pull/86822#pullrequestreview-1008655452. This patch transforms the `Ident` and `Group` types into structs serialized over IPC rather than handles.
Symbol values are interned on both the client and server when deserializing, to avoid unnecessary string copies and keep the size of `TokenTree` down. To do the interning efficiently on the client, the proc-macro crate is given a vendored version of the fxhash hasher, as `SipHash` appeared to cause performance issues. This was done rather than depending on `rustc_hash` as it is unfortunately difficult to depend on crates from within `proc_macro` due to it being built at the same time as `std`.
In addition, a custom arena allocator and symbol store was also added, inspired by those in `rustc_arena` and `rustc_span`. To prevent symbol re-use across multiple invocations of a macro on the same thread, a new range of `Symbol` names are used for each invocation of the macro, and symbols from previous invocations are cleaned-up.
In order to keep `Ident` creation efficient, a special ASCII-only case was added to perform ident validation without using RPC for simple identifiers. Full identifier validation couldn't be easily added, as it would require depending on the `rustc_lexer` and `unicode-normalization` crates from within `proc_macro`. Unicode identifiers are validated and normalized using RPC.
See the individual commit messages for more details on trade-offs and design decisions behind these patches.
|
