| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=compiler-errors
Forbid usage of `hir` `Infer` const/ty variants in ambiguous contexts
The feature `generic_arg_infer` allows providing `_` as an argument to const generics in order to infer them. This introduces a syntactic ambiguity as to whether generic arguments are type or const arguments. In order to get around this we introduced a fourth `GenericArg` variant, `Infer` used to represent `_` as an argument to generic parameters when we don't know if its a type or a const argument.
This made hir visitors that care about `TyKind::Infer` or `ConstArgKind::Infer` very error prone as checking for `TyKind::Infer`s in `visit_ty` would find *some* type infer arguments but not *all* of them as they would sometimes be lowered to `GenericArg::Infer` instead.
Additionally the `visit_infer` method would previously only visit `GenericArg::Infer` not *all* infers (e.g. `TyKind::Infer`), this made it very easy to override `visit_infer` and expect it to visit all infers when in reality it would only visit *some* infers.
---
This PR aims to fix those issues by making the `TyKind` and `ConstArgKind` types generic over whether the infer types/consts are represented by `Ty/ConstArgKind::Infer` or out of line (e.g. by a `GenericArg::Infer` or accessible by overiding `visit_infer`). We then make HIR Visitors convert all const args and types to the versions where infer vars are stored out of line and call `visit_infer` in cases where a `Ty`/`Const` would previously have had a `Ty/ConstArgKind::Infer` variant:
API Summary
```rust
enum AmbigArg {}
enum Ty/ConstArgKind<Unambig = ()> {
...
Infer(Unambig),
}
impl Ty/ConstArg {
fn try_as_ambig_ty/ct(self) -> Option<Ty/ConstArg<AmbigArg>>;
}
impl Ty/ConstArg<AmbigArg> {
fn as_unambig_ty/ct(self) -> Ty/ConstArg;
}
enum InferKind {
Ty(Ty),
Const(ConstArg),
Ambig(InferArg),
}
trait Visitor {
...
fn visit_ty/const_arg(&mut self, Ty/ConstArg<AmbigArg>) -> Self::Result;
fn visit_infer(&mut self, id: HirId, sp: Span, kind: InferKind) -> Self::Result;
}
// blanket impl'd, not meant to be overriden
trait VisitorExt {
fn visit_ty/const_arg_unambig(&mut self, Ty/ConstArg) -> Self::Result;
}
fn walk_unambig_ty/const_arg(&mut V, Ty/ConstArg) -> Self::Result;
fn walk_ty/const_arg(&mut V, Ty/ConstArg<AmbigArg>) -> Self::Result;
```
The end result is that `visit_infer` visits *all* infer args and is also the *only* way to visit an infer arg, `visit_ty` and `visit_const_arg` can now no longer encounter a `Ty/ConstArgKind::Infer`. Representing this in the type system means that it is now very difficult to mess things up, either accessing `TyKind::Infer` "just works" and you won't miss *some* type infers- or it doesn't work and you have to look at `visit_infer` or some `GenericArg::Infer` which forces you to think about the full complexity involved.
Unfortunately there is no lint right now about explicitly matching on uninhabited variants, I can't find the context for why this is the case :woman_shrugging:
I'm not convinced the framing of un/ambig ty/consts is necessarily the right one but I'm not sure what would be better. I somewhat like calling them full/partial types based on the fact that `Ty<Partial>`/`Ty<Full>` directly specifies how many of the type kinds are actually represented compared to `Ty<Ambig>` which which leaves that to the reader to figure out based on the logical consequences of it the type being in an ambiguous position.
---
tool changes have been modified in their own commits for easier reviewing by anyone getting cc'd from subtree changes. I also attempted to split out "bug fixes arising from the refactoring" into their own commit so they arent lumped in with a big general refactor commit
Fixes #112110
|
|
r=compiler-errors
For E0223, suggest associated functions that are similar to the path, even if the base type has multiple inherent impl blocks.
Currently, the "help: there is an associated function with a similar name `from_utf8`" suggestion for `String::from::utf8` is only given if `String` has exactly one inherent `impl` item. This PR makes the suggestion be emitted even if the base type has multiple inherent `impl` items.
Example:
```rust
struct Foo;
impl Foo {
fn bar_baz() {}
}
impl Foo {} // load-bearing
fn main() {
Foo::bar::baz;
}
```
Nightly/stable output:
```rust
error[E0223]: ambiguous associated type
--> f.rs:7:5
|
7 | Foo::bar::baz;
| ^^^^^^^^
|
help: if there were a trait named `Example` with associated type `bar` implemented for `Foo`, you could use the fully-qualified path
|
7 | <Foo as Example>::bar::baz;
| ~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0223`.
```
Output with this PR, or without the load-bearing empty impl on nightly/stable:
```rust
error[E0223]: ambiguous associated type
--> f.rs:7:5
|
7 | Foo::bar::baz;
| ^^^^^^^^
|
help: there is an associated function with a similar name: `bar_baz`
|
7 | Foo::bar_baz;
| ~~~~~~~
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0223`.
```
Ideally, this suggestion would also work for non-ADT types like ~~`str::char::indices`~~ (edit: latest commit makes this work with primitives) or `<dyn Any>::downcast::mut_unchecked`, but that seemed to be a harder change.
`@rustbot` label +A-diagnostics
|
|
rustdoc-json: Rename `Path::name` to `path`, and give it the path again.
Closes: #135600.
Reverts #134880 (Effectively, but not actually, as the `FORMAT_VERSION` needs to be bumped, changed docs/tests). CC `@AS1100K.`
Also CC `@obi1kenobi` `@LukeMathWalker`
Still needs before being merge-ready:
- [x] Tests for cross-crate paths
- [x] (Maybe) Document what the field does.
- [x] Decide if the field rename is good (https://github.com/rust-lang/rust/pull/135799#issuecomment-2605937831)
- [ ] Squash commits.
r? `@GuillaumeGomez`
|
|
|
|
Get rid of RunCompiler
The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
|
|
Implement `ByteStr` and `ByteString` types
Approved ACP: https://github.com/rust-lang/libs-team/issues/502
Tracking issue: https://github.com/rust-lang/rust/issues/134915
These types represent human-readable strings that are conventionally,
but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using
escape sequences, and the `Display` impl uses the Unicode replacement
character.
This is a minimal implementation of these types and associated trait
impls. It does not add any helper methods to other types such as `[u8]`
or `Vec<u8>`.
I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`,
when those would be the second implementation for a type (counting the
`T` impl), to avoid potential inference failures. We can attempt to add
more impls later in standalone commits, and run them through crater.
In addition to the `bstr` feature, I've added a `bstr_internals` feature
for APIs provided by `core` for use by `alloc` but not currently
intended for stabilization.
This API and its implementation are based *heavily* on the `bstr` crate
by Andrew Gallant (`@BurntSushi).`
r? `@BurntSushi`
|
|
It has become nothing other than a wrapper around run_compiler.
|
|
|
|
|
|
|
|
|
|
|
|
tests: Port `jobserver-error` to rmake.rs
Part of #121876.
This PR ports `tests/run-make/jobserver-error` to rmake.rs, and is basically #128789 slightly adjusted.
The complexity involved here is mostly how to get `/dev/null/` piping to fd 3 working with std `Command`, whereas with a shell this is much easier (as is evident with the `Makefile` version).
Supersedes #128789.
This PR is co-authored with `@Oneirical` and `@coolreader18.`
try-job: aarch64-gnu
try-job: i686-gnu-1
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-llvm-18-1
|
|
Add test for checking used glibc symbols
This test checks that we do not use too new glibc symbols in the compiler on x64 GNU Linux, in order not to break our [glibc promises](https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html).
One thing that isn't solved in the PR yet is to make sure that this test will only run on `dist` CI, more specifically on the `dist-x86_64-linux` runner, in the opt-dist post-optimization tests (it can fail elsewhere, that doesn't matter). Any suggestions on how to do that are welcome.
Fixes: https://github.com/rust-lang/rust/issues/134037
r? `@jieyouxu`
|
|
Rollup of 9 pull requests
Successful merges:
- #132983 (Edit dangling pointers )
- #135409 (Fix ICE-133117: multiple never-pattern arm doesn't have false_edge_start_block)
- #135557 (Point at invalid utf-8 span on user's source code)
- #135596 (Properly note when query stack is being cut off)
- #135794 (Detect missing fields with default values and suggest `..`)
- #135814 (ci: use ghcr buildkit image)
- #135826 (Misc. `rustc_resolve` cleanups)
- #135837 (Remove test panic from File::open)
- #135856 (Library: Finalize dyn compatibility renaming)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Point at invalid utf-8 span on user's source code
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: byte `193` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix #76869.
|
|
Closes https://github.com/rust-lang/rust/issues/135600
Effectivly reverts https://github.com/rust-lang/rust/pull/134880
|
|
Update the `wasm-component-ld` tool
This commit updates the `wasm-component-ld` tool from 0.5.11 to 0.5.12. This pulls in a fix for the binary adapters that are included with this tool for an issue described in bytecodealliance/wasmtime#10058. Some other dependencies have additionally been updated in the meantime of `wasm-component-ld` but there should otherwise be no major changes.
|
|
|
|
|
|
Co-authored-by: Noa <coolreader18@gmail.com>
Co-authored-by: Oneirical <manchot@videotron.ca>
|
|
Co-authored-by: Noa <coolreader18@gmail.com>
Co-authored-by: Oneirical <manchot@videotron.ca>
|
|
Rollup of 8 pull requests
Successful merges:
- #132232 (CI: build FreeBSD artifacts on FreeBSD 13.4)
- #135706 (Move `supertrait_def_ids` into the elaborate module like all other fns)
- #135750 (Add an example of using `carrying_mul_add` to write wider multiplication)
- #135793 (Ignore `mermaid.min.js`)
- #135810 (Add Kobzol on vacation)
- #135821 (fix OsString::from_encoded_bytes_unchecked description)
- #135824 (tests: delete `cat-and-grep-sanity-check`)
- #135833 (Add fixme and test for issue #135289)
Failed merges:
- #135816 (Use `structurally_normalize` instead of manual `normalizes-to` goals in alias relate errors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: `[193]` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix #76869.
|
|
This commit updates the `wasm-component-ld` tool from 0.5.11 to 0.5.12.
This pulls in a fix for the binary adapters that are included with this
tool for an issue described in bytecodealliance/wasmtime#10058. Some
other dependencies have additionally been updated in the meantime of
`wasm-component-ld` but there should otherwise be no major changes.
|
|
tests: delete `cat-and-grep-sanity-check`
Part of #121876.
All remaining `Makefile`s have open PRs that do not rely on platform `cat` or `grep` or the `cat-and-grep` script.
|
|
Move `supertrait_def_ids` into the elaborate module like all other fns
It's strange that this is the only elaborate-like fn on tcx.
r? lcnr
|
|
bump compiler and tools to windows 0.59, bootstrap to 0.57
This bumps compiler and tools to windows 0.59 (temporary dupes version, as `sysinfo` still depend on <= 0.57).
Bootstrap bumps only to 0.57 (the same sysinfo dep).
This additionally resolves my comment https://github.com/rust-lang/rust/pull/130874#issuecomment-2393562071
Will work on it in follow up pr: There still some sus imports for `rustc_driver.dll` like ws2_32 or RoOriginateErrorW, but i will look at them later.
|
|
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
|
|
|
|
|
|
|
|
|
|
All remaining `Makefile`s have open PRs that do not rely on platform
`cat` or `grep`.
|
|
|
|
|
|
Subtree update of `rust-analyzer`
r? ``@ghost``
|
|
Partial progress on #132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase
Part of #132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro
- Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro.
- Skipped `.md` files and test files to avoid unnecessary changes.
|
|
extern "rust-intrinsic" blocks
|
|
Properly record meaningful imports as re-exports in symbol index
|
|
feat: Add the ability to jump from `into` to `from` definitions
|
|
Extract variable assist triggers less eagerly
|
|
osiewicz/drop-outgoing-messages-on-background-thread
lsp-server: Drop outgoing messages on background thread
|
|
fix: Fix a bug where enum variants were not considered properly in type ns resolution
|
|
|
|
|
|
|
|
|
|
|
|
|
