Remove `crate_level_only` from `ELIDED_LIFETIMES_IN_PATHS`
As far as I can tell, we provide the right node id to the `ELIDED_LIFETIMES_IN_PATHS` lint:
f8060d282d/compiler/rustc_resolve/src/late.rs (L2015-L2027)
So I've gone ahead and removed the restriction from this lint.
Attribute checking simplifications
remove an unused boolean and then merge two big matches into one
I was reviewing some attributes and realized we don't really check this list against the list of builtin attributes, so we "may" totally be missing some attributes that we should be checking (like the `coroutine` attribute, which you can just apply to random stuff)
```rust
#![feature(coroutines)]
#[coroutine]
struct Foo;
```
just compiles for example. Unless we check that the fallthrough match arm is never reached for builtin attributes, we're just going to keep forgetting to add them here, too. I can do that without the changes in this PR, but it seemed like a nice cleanup
Match LLVM ABI in `extern "C"` functions for `f128` on Windows
As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.
I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.
Tracking issue: #116909
try-job: x86_64-msvc
try-job: x86_64-mingw
Structured suggestion for `extern crate foo` when `foo` isn't resolved in import
When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate.
When encountering `_` in an import, do not suggest `extern crate _;`.
```
error[E0432]: unresolved import `spam`
--> $DIR/import-from-missing-star-3.rs:2:9
|
LL | use spam::*;
| ^^^^ maybe a missing crate `spam`?
|
help: consider importing the `spam` crate
|
LL + extern crate spam;
|
```
When an archive fails to build, print the path
Currently the output on failure is as follows:
Compiling block-buffer v0.10.4
Compiling crypto-common v0.1.6
Compiling digest v0.10.7
Compiling sha2 v0.10.8
Compiling xz2 v0.1.7
error: failed to build archive: No such file or directory
error: could not compile `bootstrap` (lib) due to 1 previous error
Change this to print which file is being constructed, to give some hint about what is going on.
error: failed to build archive at `path/to/output`: No such file or directory
derive(SmartPointer): rewrite bounds in where and generic bounds
Fix#127647
Due to the `Unsize` bounds, we need to commute the bounds on the pointee type to the new self type.
cc ```@Darksonn```
bump-stage0: use IndexMap for determinism
When it used `HashMap`, `bump-stage0` would change `src/stage0` every
time it ran, whereas `IndexMap` will keep insertion order -- matching
the manifest file.
I included an actual bump here mainly to reset the order, but that did
update to a new rustfmt nightly too.
Update to LLVM 19
The LLVM 19.1.0 final release is planned for Sep 3rd. The rustc 1.82 stable release will be on Oct 17th.
The unstable MC/DC coverage support is temporarily broken by this update. It will be restored by https://github.com/rust-lang/rust/pull/126733. The implementation changed substantially in LLVM 19, and there are no plans to support both the LLVM 18 and LLVM 19 implementation at the same time.
Compatibility note for wasm:
> WebAssembly target support for the `multivalue` target feature has changed when upgrading to LLVM 19. Support for generating functions with multiple returns no longer works and `-Ctarget-feature=+multivalue` has a different meaning than it did in LLVM 18 and prior. The WebAssembly target features `multivalue` and `reference-types` are now both enabled by default, but generated code is not affected by default. These features being enabled are encoded in the `target_features` custom section and may affect downstream tooling such as `wasm-opt` consuming the module, but the actual generated WebAssembly will continue to not use either `multivalue` or `reference-types` by default. There is no longer any supported means to generate a module that has a function with multiple returns.
Related changes:
* https://github.com/rust-lang/rust/pull/127605
* https://github.com/rust-lang/rust/pull/127613
* https://github.com/rust-lang/rust/pull/127654
* https://github.com/rust-lang/rust/pull/128141
* https://github.com/llvm/llvm-project/pull/98933
Fixes https://github.com/rust-lang/rust/issues/121444.
Fixes https://github.com/rust-lang/rust/issues/128212.
fix: Errors on method call inferences with elided lifetimes
Fixes#17734
Currently, we are matching non-lifetime(type or const) generic arg to liftime argument position while building substs for method calling when there are elided lifetimes.
This mismatch just make a subst for error lifetime and while this alone is not much a trouble, it also makes the mismatched type or const generic arg cannot be used in its proper place and this makes type inference failure
The pattern-analysis code needs to print patterns, as part of its user-visible
diagnostics. But it never actually tries to print "real" patterns! Instead, it
only ever prints synthetic patterns that it has reconstructed from its own
internal represenations.
We can therefore simultaneously remove two obstacles to changing `thir::Pat`,
by having the pattern-analysis code use its own dedicated type for building
printable patterns, and then making `thir::Pat` not printable at all.
This reverts commit ae0ec731a8.
The original change in #128304 was intended to be a step towards being able to
print `thir::Pat` even after switching to `PatId`.
But because the only patterns that need to be printed are the synthetic ones
created by pattern analysis (for diagnostic purposes only), it makes more sense
to completely separate the printable patterns from the real THIR patterns.
Migrate `rlib-format-packed-bundled-libs-2`, `native-link-modifier-whole-archive` and `no-builtins-attribute` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: test-various
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
This makes it possible for the `unsafe(...)` syntax to only be
valid at the top level, and the `NestedMetaItem`s will automatically
reject `unsafe(...)`.
When it used `HashMap`, `bump-stage0` would change `src/stage0` every
time it ran, whereas `IndexMap` will keep insertion order -- matching
the manifest file.
tidy: Fix quote in error message
I noticed that the backticks around the error code wasn't done properly in this string when I was building Rust 1.80.0 and found it is still this way in nightly. Example:
```
warning: Error code `E0595` needs to have at least one UI test in the `tests/error-codes/` directory`!
warning: Error code E0602`` has a UI test file, but doesn't contain its own error code!
warning: Error code `E0619` needs to have at least one UI test in the `tests/error-codes/` directory`!
```
This commit fixes it to match the other warning strings.
Mark `Parser::eat`/`check` methods as `#[must_use]`
These methods return a `bool`, but we probably should either use these values or explicitly throw them away (e.g. when we just want to unconditionally eat a token if it exists).
I changed a few places from `eat` to `expect`, but otherwise I tried to leave a comment explaining why the `eat` was okay.
This also adds a test for the `pattern_type!` macro, which used to silently accept a missing `is` token.
Detect non-lifetime binder params shadowing item params
We should check that `for<T>` shadows `T` from an item in the same way that `for<'a>` shadows `'a` from an item.
r? ``@petrochenkov`` since you're familiar w the nuances of rib kinds
Matthias Krüger