| Age | Commit message (Collapse) | Author | Lines |
|---|
|
track cycle participants per root
The search graph may have multiple roots, e.g. in
```
A :- B
B :- A, C
C :- D
D :- C
```
we first encounter the `A -> B -> A` cycle which causes `A` to be a root. We then later encounter the `C -> D -> C` cycle as a nested goal of `B`. This cycle is completely separate and `C` will get moved to the global cache. This previously caused us to use `[B, D]` as the `cycle_participants` for `C` and `[]` for `A`.
split off from #125167 as I would like to merge this change separately and will rebase that PR on top of this one. There is no test for this issue and I don't quite know how to write one. It is probably worth it to generalize the search graph to enable us to write unit tests for it.
r? `@compiler-errors`
|
|
hir pretty: fix block indent
before:
```rust
fn main() {
{
{
::std::io::_print(format_arguments::new_const(&["Hello, world!\n"]));
};
}
}
```
after:
```rust
fn main() {
{
{
::std::io::_print(format_arguments::new_const(&["Hello, world!\n"]));
};
}
}
```
AST pretty does the same.
|
|
Note for E0599 if shadowed bindings has the method.
implement #123558
Use a visitor to find earlier shadowed bingings which has the method.
r? ``@estebank``
|
|
Remove libc from MSVC targets
``@ChrisDenton`` started working on a project to remove libc from Windows MSVC targets. I'm completing that work here.
The primary change is to cfg out the dependency in `library/`. And then there's a lot of test patching. Happy to separate this more if people want.
|
|
|
|
Update `unexpected_cfgs` lint for Cargo new `check-cfg` config
This PR updates the diagnostics output of the `unexpected_cfgs` lint for Cargo new `check-cfg` config.
It's a simple and cost-less alternative to the build-script `cargo::rustc-check-cfg` instruction.
```toml
[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(foo, values("bar"))'] }
```
This PR also adds a Cargo specific section regarding check-cfg and Cargo inside rustc's book (motivation is described inside the file, but mainly check-cfg is a rustc feature not a Cargo one, Cargo only enabled the feature, it does not own it; T-cargo even considers the `check-cfg` lint config to be an implementation detail).
This PR also updates the links to refer to that sub-page when using Cargo from rustc.
As well as updating the lint doc to refer to the check-cfg docs.
~**Not to be merged before https://github.com/rust-lang/cargo/pull/13913 reaches master!**~ (EDIT: merged in https://github.com/rust-lang/rust/pull/125237)
`@rustbot` label +F-check-cfg
r? `@fmease` *(feel free to roll)*
Fixes https://github.com/rust-lang/rust/issues/124800
cc `@epage` `@weihanglo`
|
|
|
|
GuillaumeGomez:migrate-rustdoc-examples-whitespaces, r=jieyouxu
Migrate `run-make/rustdoc-scrape-examples-whitespace` to `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
r=pnkfelix
Add an experimental feature gate for global registration
See #125119 for the tracking issue.
|
|
add some codegen tests for issue 120493
I forgot to add these in https://github.com/rust-lang/rust/pull/123878.
|
|
Remove `Rvalue::CheckedBinaryOp`
Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996>
cc `@RalfJung`
While it's a draft,
r? ghost
|
|
coverage: Memoize and simplify counter expressions
When creating coverage counter expressions as part of coverage instrumentation, we often end up creating obviously-redundant expressions like `c1 + (c0 - c1)`, which is equivalent to just `c0`.
To avoid doing so, this PR checks when we would create an expression matching one of 5 patterns, and uses the simplified form instead:
- `(a - b) + b` → `a`.
- `(a + b) - b` → `a`.
- `(a + b) - a` → `b`.
- `a + (b - a)` → `b`.
- `a - (a - b)` → `b`.
Of all the different ways to combine 3 operands and 2 operators, these are the patterns that allow simplification.
(Some of those patterns currently don't occur in practice, but are included anyway for completeness, to avoid having to add them later as branch coverage and MC/DC coverage support expands.)
---
This PR also adds memoization for newly-created (or newly-simplified) counter expressions, to avoid creating duplicates.
This currently makes no difference to the final mappings, but is expected to be useful for MC/DC coverage of match expressions, as proposed by https://github.com/rust-lang/rust/pull/124278#issuecomment-2106754753.
|
|
Check whether the next_node is else-less if in get_return_block
Fix #124819
|
|
Suggest setting lifetime in borrowck error involving types with elided lifetimes
```
error: lifetime may not live long enough
--> $DIR/ex3-both-anon-regions-both-are-structs-2.rs:7:5
|
LL | fn foo(mut x: Ref, y: Ref) {
| ----- - has type `Ref<'_, '1>`
| |
| has type `Ref<'_, '2>`
LL | x.b = y.b;
| ^^^^^^^^^ assignment requires that `'1` must outlive `'2`
|
help: consider introducing a named lifetime parameter
|
LL | fn foo<'a>(mut x: Ref<'a, 'a>, y: Ref<'a, 'a>) {
| ++++ ++++++++ ++++++++
```
As can be seen above, it currently doesn't try to compare the `ty::Ty` lifetimes that diverged vs the `hir::Ty` to correctly suggest the following
```
help: consider introducing a named lifetime parameter
|
LL | fn foo<'a>(mut x: Ref<'_, 'a>, y: Ref<'_, 'a>) {
| ++++ ++++++++ ++++++++
```
but I believe this to still be an improvement over the status quo.
Fix #40990.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix `tests/debuginfo/strings-and-strs`.
It fails on my machine because it embeds pointer addresses in the expected output.
This commit replaces the addresses with `0x[...]`.
r? ```@Mark-Simulacrum```
|
|
rustdoc: Don't strip items with inherited visibility in `AliasedNonLocalStripper`
Enum variants return `None` in `Item::visibility`, which fails the comparison to `Some(Visibility::Public)`. This means that all enums in type aliases are being stripped, leading to this in the `rustc_middle` docs:
<img width="474" alt="image" src="https://github.com/rust-lang/rust/assets/3674314/83704d94-a571-4c28-acbd-ca51c4efd46e">
This regressed in https://github.com/rust-lang/rust/pull/124939#discussion_r1606130566.
This switches the `AliasedNonLocalStripper` to not strip items with `None` as their visibility.
|
|
implement #123558
|
|
|
|
|
|
|
|
defrost `RUST_MIN_STACK=ice rustc hello.rs`
I didn't think too hard about testing my previous PR rust-lang/rust#122847 which makes our stack overflow handler assist people in discovering the `RUST_MIN_STACK` variable (which apparently is surprisingly useful for Really Big codebases). After it was merged, some useful comments left in a drive-by review led me to discover I had added an ICE. This reworks the code a bit to explain the rationale, remove the ICE that I introduced, and properly test one of the diagnostics.
|
|
fix suggestion in E0373 for !Unpin coroutines
Coroutines can be prefixed with the `static` keyword to make them
`!Unpin`.
However, given the following function:
```rust
fn check() -> impl Sized {
let x = 0;
#[coroutine]
static || {
yield;
x
}
}
```
We currently suggest prefixing `move` before `static`, which is
syntactically incorrect:
```
error[E0373]: coroutine may outlive the current function, but it borrows
...
--> src/main.rs:6:5
|
6 | static || {
| ^^^^^^^^^ may outlive borrowed value `x`
7 | yield;
8 | x
| - `x` is borrowed here
|
note: coroutine is returned here
--> src/main.rs:6:5
|
6 | / static || {
7 | | yield;
8 | | x
9 | | }
| |_____^
help: to force the coroutine to take ownership of `x` (and any other
referenced variables), use the `move` keyword
| // this is syntactically incorrect, it should be `static move ||`
6 | move static || {
| ++++
```
This PR suggests adding `move` after `static` for these coroutines.
I also added a UI test for this case.
|
|
r=compiler-errors
Never type unsafe lint improvements
- Move linting code to a separate method
- Remove mentions of `core::convert::absurd` (#124311 was rejected)
- Make the lint into FCW
The last thing is a bit weird though. On one hand it should be `EditionSemanticsChange(2024)`, but on the other hand it shouldn't, because we also plan to break it on all editions some time later. _Also_, it's weird that we don't have `FutureReleaseSemanticsChangeReportInDeps`, IMO "this might cause UB in a future release" is important enough to be reported in deps...
IMO we ought to have three enums instead of [`FutureIncompatibilityReason`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_lint_defs/enum.FutureIncompatibilityReason.html#):
```rust
enum IncompatibilityWhen {
FutureRelease,
Edition(Edition),
}
enum IncompatibilyWhat {
Error,
SemanticChange,
}
enum IncompatibilityReportInDeps {
No,
Yes,
}
```
Tracking:
- https://github.com/rust-lang/rust/issues/123748
|
|
It fails on my machine because it embeds pointer addresses in the
expected output.
This commit replaces the addresses with `0x[...]`.
|
|
|
|
An earlier commit included the change for a suggestion here.
Unfortunately, it also used unwrap instead of dying properly.
Roll out the ~~rice paper~~ EarlyDiagCtxt before we do anything that
might leave a mess.
|
|
|
|
|
|
|
|
chore: Remove repeated words (extension of #124924)
When I saw #124924 I thought "Hey, I'm sure that there are far more than just two typos of this nature in the codebase". So here's some more typo-fixing.
Some found with regex, some found with a spellchecker. Every single one manually reviewed by me (along with hundreds of false negatives by the tools)
|
|
|
|
|
|
|
|
GuillaumeGomez:migrate-rustdoc-scrape-examples-test, r=jieyouxu
Migrate `run-make/rustdoc-scrape-examples-test` to new `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? ``@jieyouxu``
|
|
crashes: add more
r? ``@jieyouxu``
|
|
r=compiler-errors,estebank
Actually use the `#[do_not_recommend]` attribute if present
This change tweaks the error message generation to actually use the `#[do_not_recommend]` attribute if present by just skipping the marked trait impl in favour of the parent impl. It also adds a compile test for this behaviour. Without this change the test would output the following error:
```
error[E0277]: the trait bound `&str: Expression` is not satisfied
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
|
= help: the following other types implement trait `Expression`:
Bound<T>
SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
|
LL | impl<T, ST> AsExpression<ST> for T
| ^^^^^^^^^^^^^^^^ ^
LL | where
LL | T: Expression<SqlType = ST>,
| ------------------------ unsatisfied trait bound introduced here
```
Note how that mentions `&str: Expression` before and now mentions `&str: AsExpression<Integer>` instead which is much more helpful for users.
Open points for further changes before stabilization:
* We likely want to move the attribute to the `#[diagnostic]` namespace to relax the guarantees given?
* How does it interact with the new trait solver?
r? `@estebank`
|
|
|
|
This change tweaks the error message generation to actually use the
`#[do_not_recommend]` attribute if present by just skipping the marked
trait impl in favour of the parent impl. It also adds a compile test for
this behaviour. Without this change the test would output the following
error:
```
error[E0277]: the trait bound `&str: Expression` is not satisfied
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:53:15
|
LL | SelectInt.check("bar");
| ^^^^^ the trait `Expression` is not implemented for `&str`, which is required by `&str: AsExpression<Integer>`
|
= help: the following other types implement trait `Expression`:
Bound<T>
SelectInt
note: required for `&str` to implement `AsExpression<Integer>`
--> /home/weiznich/Documents/rust/rust/tests/ui/diagnostic_namespace/do_not_recommend.rs:26:13
|
LL | impl<T, ST> AsExpression<ST> for T
| ^^^^^^^^^^^^^^^^ ^
LL | where
LL | T: Expression<SqlType = ST>,
| ------------------------ unsatisfied trait bound introduced here
```
Note how that mentions `&str: Expression` before and now mentions `&str:
AsExpression<Integer>` instead which is much more helpful for users.
Open points for further changes before stabilization:
* We likely want to move the attribute to the `#[diagnostic]` namespace
to relax the guarantees given?
* How does it interact with the new trait solver?
|
|
lldb-formatters: Use StdSliceSyntheticProvider for &str
&str has associated summary provider which correctly displays string values in debugger, but while working on https://github.com/rust-lang/rust/pull/124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging
However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value
I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
44 let plain_str = "Hello";
45 let str_in_struct = Foo { inner: "Hello" };
46 let str_in_tuple = ("Hello", "World");
-> 47 zzz(); // #break
48 }
49
50 fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
vec = size=5 {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
(&str) plain_str = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
(strings_and_strs::Foo) str_in_struct = {
inner = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
}
((&str, &str)) str_in_tuple = {
0 = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
1 = "World" {
data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
}
```
After this PR it would look the following way:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
44 let plain_str = "Hello";
45 let str_in_struct = Foo { inner: "Hello" };
46 let str_in_tuple = ("Hello", "World");
-> 47 zzz(); // #break
48 }
49
50 fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
vec = size=5 {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
(&str) plain_str = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
(strings_and_strs::Foo) str_in_struct = {
inner = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
((&str, &str)) str_in_tuple = {
0 = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
1 = "World" {
[0] = 'W'
[1] = 'o'
[2] = 'r'
[3] = 'l'
[4] = 'd'
}
}
```
|
|
|
