Pick one possible lifetime in case there are multiple choices
In case a lifetime variable is created, but doesn't have an obvious lifetime in the list of named lifetimes that it should be inferred to, just pick the first one for the diagnostic.
This happens e.g. in
```rust
fn foo<'a, 'b>(a: Struct<'a>, b: Struct<'b>) -> impl Trait<'a, 'b> {
if bar() { a } else { b }
}
```
where we get a lifetime variable that combines the lifetimes of `a` and `b` creating a lifetime that is the intersection of both. Right now the type system cannot express this and thus we get an error, but that error also can't express this.
I can also create an entirely new diagnostic that mentions all involved lifetimes, so it would actually mention `'a` and `'b` instead of just `'b`.
Rebase resume argument projections during state transform
When remapping a resume argument with projections rebase them on top of
the new base.
The case where resume argument has projections is unusual, but might
arise with box syntax where the assignment is performed directly into
the box without an intermediate temporary.
Fixes#85635.
Do not suggest importing inaccessible items
Fixes#88472. For this example:
```rust
mod a {
struct Foo;
}
mod b {
type Bar = Foo;
}
```
rustc currently emits:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
help: consider importing this struct
|
6 | use a::Foo;
|
```
this is incorrect, as applying this suggestion leads to
```
error[E0603]: struct `Foo` is private
--> test.rs:6:12
|
6 | use a::Foo;
| ^^^ private struct
|
note: the struct `Foo` is defined here
--> test.rs:2:5
|
2 | struct Foo;
| ^^^^^^^^^^^
```
With my changes, I get:
```
error[E0412]: cannot find type `Foo` in this scope
--> test.rs:6:16
|
6 | type Bar = Foo;
| ^^^ not found in this scope
|
= note: this struct exists but is inaccessible:
a::Foo
```
As for the wildcard mentioned in #88472, I would argue that the warning is actually correct, since the import _is_ unused. I think the real issue is the wrong suggestion, which I have fixed here.
bootstrap: Update comment in config.library.toml.
Downloading LLVM from CI works for all platforms now.
All other templates in this directory already have the proper comment. Seems this one was neglected.
CTFE: tweak aggregate rvalue handling
I have not looked at this code in ages... I think Miri does not even hit it, since (most?) aggregate rvalues are lowered somewhere in the MIR pipeline, but CTFE does hit it.
So this adds some extra sanity assertions, and removes a ZST special case -- ZST should only be special cased fairly late (when the actual memory access happens); e.g. `!` is a ZST and we still want `copy_op` to be called for it since it will perform validation (and raise UB, since `!` is never valid).
fix(lint): don't suggest refutable patterns to "fix" irrefutable bind
In function arguments and let bindings, do not suggest changing `C` to `Foo::C` unless `C` is the only variant of `Foo`, because it won't work.
The general warning is still kept, because code like this is confusing.
Fixes#88730
p.s. `src/test/ui/lint/lint-uppercase-variables.rs` already tests the one-variant case.
Suggest similarly named associated items in trait impls
Fix#85942
Previously, the compiler didn't suggest similarly named associated items unlike we do in many situations. This patch adds such diagnostics for associated functions, types, and constants.
Fix ICE when `start` lang item has wrong generics
In my previous pr #87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates. This fixes that by updating the requirement to be exactly one generic type.
The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it. I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations. Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.
Fixes#79559, fixes#73584, fixes#83117 (all duplicates)
Relevant to #9307
r? ````@cjgillot````
Move encode_metadata out of CrateStore.
`rustc_metadata` is already accessible by all client crates. It does not need to be called trough a trait object.
2229: Consume IfLet expr
When using the IfLet guard feature, we can ICE when attempting to resolve PlaceBuilders.
For pattern matching, we currently don't consume the IfLet expression when "visiting" the arms leading us to not "read" all variables and hence not being able to resolve them.
r? `@nikomatsakis`
Closes https://github.com/rust-lang/rust/issues/88118
Avoid spurious "previous iteration of loop" errors
Only follow backwards edges during `get_moved_indexes` if the move path is definitely initialized at loop entry. Otherwise, the error occurred prior to the loop, so we ignore the backwards edges to avoid generating misleading "value moved here, in previous iteration of loop" errors.
This patch also slightly improves the analysis of inits, including `NonPanicPathOnly` initializations (which are ignored by `drop_flag_effects::for_location_inits`). This is required for the definite initialization analysis, but may also help find certain skipped reinits in rare cases.
Patch passes all non-ignored src/test/ui testcases.
Fixes#72649.
Constify ?-operator for Result and Option
Try to make `?`-operator usable in `const fn` with `Result` and `Option`, see #74935 . Note that the try-operator itself was constified in #87237.
TODO
* [x] Add tests for const T -> T conversions
* [x] cleanup commits
* [x] Remove `#![allow(incomplete_features)]`
* [?] Await decision in #86808 - I'm not sure
* [x] Await support for parsing `~const` in bootstrapping compiler
* [x] Tracking issue(s)? - #88674
Don't anonymize bound region names during typeck
Once this anonymization has performed, we have no
way of recovering the original names during NLL
borrow checking. Keeping the original names allows
error messages in full NLL mode to contain the original
bound region names.
As a result, the typeck results may contain types that
differ only in the names used for their bound regions. However,
anonimization of bound regions does not guarantee that
all distinct types are unqual (e.g. not subtypes of each other).
For example, `for<'a> fn(&'a u32, &'a u32)` and
`for<'b, 'c> fn(&'b u32, &'c u32)` are subtypes of each other,
as explained here:
63cc2bb3d0/compiler/rustc_infer/src/infer/nll_relate/mod.rs (L682-L690)
Therefore, any code handling types with higher-ranked regions already
needs to handle the case where two distinct `Ty`s are 'actually'
equal.
Update cargo
5 commits in 0121d66aa2ef5ffa9735f86c2b56f5fdc5a837a6..d56b42c549dbb7e7d0f712c51b39400260d114d4
2021-09-22 16:08:27 +0000 to 2021-09-27 13:44:18 +0000
- Allow `cargo update --precise` with metadata. (rust-lang/cargo#9945)
- Support path_in_vcs as part of cargo_vcs_metadata (rust-lang/cargo#9866)
- Doc about InstallTracker files and `install.root` (rust-lang/cargo#9948)
- Add some clarity on the license/license-file warning. (rust-lang/cargo#9941)
- Fix the problem that help cannot be displayed properly (rust-lang/cargo#9933)
rustdoc: Remove lazy_static dependency
The macro was used in only one place and there are equivalents in the std, so it seemed weird to keep it around...
I think running a perf check would be a good idea though, just in case.
r? ``@jyn514``
PassWrapper: handle function rename from upstream D36850
thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and
gained the ability to propagate noRecurse and noUnwind function
attributes. I ran codegen tests with it both on and off, as the upstream
patch uses it in both modes, and the tests pass both ways. Given that,
it seemed reasonable to go ahead and let the propagation be enabled in
rustc, and see what happens. See https://reviews.llvm.org/D36850 for
more examples of how the new version of the function gets used.
r? ``@nikic`` cc ``@nagisa``
Improve help for recursion limit errors
- Tweak help message and suggested limit (handle `0` case).
- Add test for #75602 (it was already fixed, maybe can be resolved too).
Fixes#76424
Fix generics where bounds order
Fixes#88809.
Like said on the above issue, the issue is that we were expecting `Symbol` comparisons to be string-based but they are integer-based (because `Symbol` is an integer), messing up the bounds order. To fix it, I simply stored into a `FxIndexMap` instead.
r? ``@jyn514``
Remove ignore-tidy-undocumented-unsafe from core::slice::sort
Write down the missing safety arguments to be able to remove `ignore-tidy-undocumented-unsafe` from `core::slice::sort`.
Helps with #66219
``@rustbot`` label C-cleanup T-libs
Fix union keyword highlighting in rustdoc HTML sources
I followed this logic: if I find an ident "union", I check if it followed by another ident or not. If it's the case, then I consider this is a keyword because it's declaring a union type.
To do so I created a new Iterator which allows to peek the next items without moving the current iterator position.
This is part of https://github.com/rust-lang/rust/issues/85016. If the fix makes sense, I'll extend it to other weak keywords (the issue only mentions they exist but https://doc.rust-lang.org/nightly/reference/keywords.html#weak-keywords only talks about `dyn` and `'static` so not sure if there is anything else to be done?).
cc `@notriddle` (you're one of the last ones who worked on this part of rustdoc so here you go 😉 )
r? `@jyn514`
Use larger span for adjustment THIR expressions
Currently, we use a relatively 'small' span for THIR
expressions generated by an 'adjustment' (e.g. an autoderef,
autoborrow, unsizing). As a result, if a borrow generated
by an adustment ends up causing a borrowcheck error, for example:
```rust
let mut my_var = String::new();
let my_ref = &my_var
my_var.push('a');
my_ref;
```
then the span for the mutable borrow may end up referring
to only the base expression (e.g. `my_var`), rather than
the method call which triggered the mutable borrow
(e.g. `my_var.push('a')`)
Due to a quirk of the MIR borrowck implementation,
this doesn't always get exposed in migration mode,
but it does in many cases.
This commit makes THIR building consistently use 'larger'
spans for adjustment expressions. These spans are recoded
when we first create the adjustment during typecheck. For
example, an autoref adjustment triggered by a method call
will record the span of the entire method call.
The intent of this change it make it clearer to users
when it's the specific way in which a variable is
used (for example, in a method call) that produdes
a borrowcheck error. For example, an error message
claiming that a 'mutable borrow occurs here' might
be confusing if it just points at a usage of a variable
(e.g. `my_var`), when no `&mut` is in sight. Pointing
at the entire expression should help to emphasize
that the method call itself is responsible for
the mutable borrow.
In several cases, this makes the `#![feature(nll)]` diagnostic
output match up exactly with the default (migration mode) output.
As a result, several `.nll.stderr` files end up getting removed
entirely.
Fix Windows LLVM issue.
GitHub image 20210928.2 added LLVM 12.0.1 to the stock image. However, the `lldb` executable doesn't work, it fails with:
> C:/Program Files/LLVM/bin/lldb.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
We probably don't want to start testing LLDB on windows anyways (at least not without intent).
The hacky solution for now is to just delete the system LLVM.
Restructure std::rt
These changes should reduce binary size slightly while at the same slightly improving performance of startup, thread spawning and `std:🧵:current()`. I haven't verified if the compiler is able to optimize some of these cases already, but at least for some others the compiler is unable to do these optimizations as they slightly change behavior in cases where program startup would crash anyway by omitting a backtrace and panic location.
I can remove 6f6bb16 if preferred.
In function arguments and let bindings, do not suggest changing `C` to `Foo::C`
unless `C` is the only variant of `Foo`, because it won't work.
The general warning is still kept, because code like this is confusing.
Fixes#88730
