Remove LintBuffer from Session
This moves the `LintBuffer` from `Session` into the `Resolver`, where it is used until lowering is done and then consumed by early lint passes. This also happily removes the failure mode of buffering lints too late where it would have previously lead to ICEs; it is statically no longer possible to do so.
I suspect that with a bit more work a similar move could be done for the lint buffer inside `ParseSess`, but this PR doesn't touch it (in part to keep itself small).
The last commit is the "interesting" commit -- the ones before it don't work (though they compile) as they sort of prepare the various crates for the lint buffer to be passed in rather than accessed through Session.
Reduce amount of errors given unclosed delimiter
When in a file with a non-terminated item, catch the error and consume
the block instead of trying to recover it on a more granular way in order to
reduce the amount of unrelated errors that would be fixed after adding
the missing closing brace. Also point out the possible location of the
missing closing brace.
Fix#63690.
Move help popup generation code
The first commit is just a small cleanup.
The idea behind this PR is to reduce a bit more the generated HTML files by moving the duplicated code into one place instead.
r? @kinnison
Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI
This PR fixes interactions between Rust panics and foreign (mainly C++) exceptions.
C++ exceptions (and other FFI exceptions) can now safely unwind through Rust code:
- The FFI function causing the unwind must be marked with `#[unwind(allowed)]`. If this is not the case then LLVM may optimize landing pads away with the assumption that they are unreachable.
- Drop code will be executed as the exception unwinds through the stack, as with a Rust panic.
- `catch_unwind` will *not* catch the exception, instead the exception will silently continue unwinding past it.
Rust panics can now safely unwind through C++ code:
- C++ destructors will be called as the stack unwinds.
- The Rust panic can only be caught with `catch (...)`, after which it can be either rethrown or discarded.
- C++ cannot name the type of the Rust exception object used for unwinding, which means that it can't be caught explicitly or have its contents inspected.
Tests have been added to ensure all of the above works correctly.
Some notes about non-C++ exceptions:
- `pthread_cancel` and `pthread_exit` use unwinding on glibc. This has the same behavior as a C++ exception: destructors are run but it cannot be caught by `catch_unwind`.
- `longjmp` on Windows is implemented using unwinding. Destructors are run on MSVC, but not on MinGW. In both cases the unwind cannot be caught by `catch_unwind`.
- As with C++ exceptions, you need to mark the relevant FFI functions with `#[unwind(allowed)]`, otherwise LLVM will optimize out the destructors since they seem unreachable.
I haven't updated any of the documentation, so officially unwinding through FFI is still UB. However this is a step towards making it well-defined.
Fixes#65441
cc @gnzlbg
r? @alexcrichton
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Fixes#56277
Remove a loop which runs exactly once
Though the code seems to work properly, it is worth removing the loop entirely in order to not confuse the reader.
r? @estebank
The concrete type that will be too big is target dependent. Avoid
matching it in error annotation to make test work correctly across
different targets.
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
When both error patterns and error annotations are present in an ui
test, only error patterns are validated against the output.
Replace the error pattern with an error annotation to avoid silently
ignoring the other error annotation.
Partially revert the early feature-gatings added in #65742.
The intent here is to address #65860 ASAP (in time for beta, ideally), while leaving as much of #65742 around as possible, to make it easier to re-enable later.
Therefore, I've only kept the parts of the revert that re-add the old (i.e. non-early) feature-gating checks that were removed in #65742, and the test reverts.
I've disabled the new early feature-gating checks from #65742 entirely for now, but it would be easy to put them behind a `-Z` flag, or turn them into warnings, which would allow us to keep tests for both the early and late versions of the checks - assuming that's desirable.
cc @nikomatsakis @Mark-Simulacrum @Centril
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
Rollup of 16 pull requests
Successful merges:
- #65112 (Add lint and tests for unnecessary parens around types)
- #65470 (Don't hide ICEs from previous incremental compiles)
- #65471 (Add long error explanation for E0578)
- #65857 (rustdoc: Resolve module-level doc references more locally)
- #65902 (Make ItemContext available for better diagnositcs)
- #65914 (Use structured suggestion for unnecessary bounds in type aliases)
- #65946 (Make `promote_consts` emit the errors when required promotion fails)
- #65960 (doc: reword iter module example and mention other methods)
- #65963 (update submodules to rust-lang)
- #65972 (Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets)
- #65977 (Fix incorrect diagnostics for expected type in E0271 with an associated type)
- #65995 (Add error code E0743 for "C-variadic has been used on a non-foreign function")
- #65997 (Fix outdated rustdoc of Once::init_locking function)
- #66002 (Stabilize float_to_from_bytes feature)
- #66005 (vxWorks: remove code related unix socket)
- #66018 (Revert PR 64324: dylibs export generics again (for now))
Failed merges:
r? @ghost
Revert PR 64324: dylibs export generics again (for now)
As discussed on PR #65781, this is a targeted attempt to undo the main semantic change from PR #64324, by putting `dylib` back in the set of crate types that export generic symbols.
The main reason to do this is that PR #64324 had unanticipated side-effects that caused bugs like #64872, and in the opinion of @alexcrichton and myself, the impact of #64872 is worse than #64319.
In other words, it is better for us, in the short term, to reopen#64319 as currently unfixed for now than to introduce new bugs like #64872.
Fix#64872Reopen#64319
Fix incorrect diagnostics for expected type in E0271 with an associated type
With code like the following code:
```rust
#[derive(Debug)]
struct Data {}
fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
for item in iterator {
println!("{:?}", item)
}
}
fn main() {
let v = vec![Data {}];
do_stuff(v.into_iter());
}
```
the diagnostic (in nightly & stable) wrongly complains about the expected type:
```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
--> src/main.rs:15:5
|
5 | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
| -------- --------------- required by this bound in `do_stuff`
...
15 | do_stuff(v.into_iter());
| ^^^^^^^^ expected struct `Data`, found &Data
|
= note: expected type `Data`
found type `&Data`
```
This PR fixes this issue by flipping the expected/actual values where appropriate, so it looks like this:
```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
--> main.rs:15:5
|
5 | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
| -------- --------------- required by this bound in `do_stuff`
...
15 | do_stuff(v.into_iter());
| ^^^^^^^^ expected &Data, found struct `Data`
|
= note: expected type `&Data`
found type `Data`
```
This improves the output of a lot of existing tests (check out `associated-types-binding-to-type-defined-in-supertrait`!).
The only change which I wasn't too sure about is in the test `associated-types-overridden-binding-2`, but I think it's an improvement and the underlying problem is with handling of `trait_alias`.
Fix#57226, fix#64760, fix#58092.
Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets
If `__LITTLE_ENDIAN__` is missing, libunwind assumes big endian
and reads unwinding instructions wrong on ARM EHABI.
Fix#65765
Technical background in referenced bug.
I didn't run any automated tests, just built a simple panicking program using the fixed toolchain and panicking started to work. Tried with `catch_unwind()` and that seems to work now too. libunwind's log seems ok now, I can paste it if needed.
update submodules to rust-lang
These are the repositories I've moved from rust-lang-nursery to
rust-lang, so we should update the submodules too.
I have not tested that this builds at all, so please make sure CI is green!
Make `promote_consts` emit the errors when required promotion fails
A very minimal version of #65942.
This will cause a generic "argument X is required to be a constant" message for `simd_shuffle` LLVM intrinsics instead of the [custom one](caa1f8d7b3/src/librustc_mir/transform/qualify_consts.rs (L1616)). It may be possible to remove this special-casing altogether after rust-lang/stdarch#825.
r? @eddyb
rustdoc: Resolve module-level doc references more locally
Module level docs should resolve intra-doc links as locally as
possible. As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.
I'm hoping that this fixes#55364 though right now I'm not sure it's the right fix.
r? @GuillaumeGomez
