Remove the `ty` field from type system `Const`s
Fixes#125556Fixes#122908
Part of the work on `adt_const_params`/`generic_const_param_types`/`min_generic_const_exprs`/generally making the compiler nicer. cc rust-lang/project-const-generics#44
Please review commit-by-commit otherwise I wasted a lot of time not just squashing this into a giant mess (and also it'll be SO much nicer because theres a lot of fluff changes mixed in with other more careful changes if looking via File Changes
---
Why do this?
- The `ty` field keeps causing ICEs and weird behaviour due to it either being treated as "part of the const" or it being forgotten about leading to ICEs.
- As we move forward with `adt_const_params` and a potential `min_generic_const_exprs` it's going to become more complex to actually lower the correct `Ty<'tcx>`
- It muddles the idea behind how we check `Const` arguments have the correct type. By having the `ty` field it may seem like we ought to be relating it when we relate two types, or that its generally important information about the `Const`.
- Brings the compiler more in line with `a-mir-formality` as that also tracks the type of type system `Const`s via `ConstArgHasType` bounds in the env instead of on the `Const` itself.
- A lot of stuff is a lot nicer when you dont have to pass around the type of a const lol. Everywhere we construct `Const` is now significantly nicer 😅
See #125671's description for some more information about the `ty` field
---
General summary of changes in this PR:
- Add `Ty` to `ConstKind::Value` as otherwise there is no way to implement `ConstArgHasType` to ensure that const arguments are correctly typed for the parameter when we stop creating anon consts for all const args. It's also just incredibly difficult/annoying to thread the correct `Ty` around to a bunch of ctfe functions otherwise.
- Fully implement `ConstArgHasType` in both the old and new solver. Since it now has no reliance on the `ty` field it serves its originally intended purpose of being able to act as a double check that trait vs impls have correctly typed const parameters. It also will now be able to be responsible for checking types of const arguments to parameters under `min_generic_const_exprs`.
- Add `Ty` to `mir::Const::Ty`. I dont have a great understanding of why mir constants are setup like this to be honest. Regardless they need to be able to determine the type of the const and the easiest way to make this happen was to simply store the `Ty` along side the `ty::Const`. Maybe we can do better here in the future but I'd have to spend way more time looking at everywhere we use `mir::Const`.
- rustdoc has its own `Const` which also has a `ty` field. It was relatively easy to remove this.
---
r? `@lcnr` `@compiler-errors`
Rollup of 9 pull requests
Successful merges:
- #124840 (resolve: mark it undetermined if single import is not has any bindings)
- #125622 (Winnow private method candidates instead of assuming any candidate of the right name will apply)
- #125648 (Remove unused(?) `~/rustsrc` folder from docker script)
- #125672 (Add more ABI test cases to miri (RFC 3391))
- #125800 (Fix `mut` static task queue in SGX target)
- #125871 (Orphanck[old solver]: Consider opaque types to never cover type parameters)
- #125893 (Handle all GVN binops in a single place.)
- #126008 (Port `tests/run-make-fulldeps/issue-19371` to ui-fulldeps)
- #126032 (Update description of the `IsTerminal` example)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 10 pull requests
Successful merges:
- #124746 (`rustc --explain E0582` additional example)
- #125407 (Detect when user is trying to create a lending `Iterator` and give a custom explanation)
- #125505 (Add intra-doc-links to rustc_middle crate-level docs.)
- #125792 (Don't drop `Unsize` candidate in intercrate mode)
- #125819 (Various `HirTyLowerer` cleanups)
- #125861 (rustc_codegen_ssa: fix `get_rpath_relative_to_output` panic when lib only contains file name)
- #125911 (delete bootstrap build before switching to bumped rustc)
- #125921 (coverage: Carve out hole spans in a separate early pass)
- #125940 (std::unix::fs::get_path: using fcntl codepath for netbsd instead.)
- #126022 (set `has_unconstrained_ty_var` when generalizing aliases in bivariant contexts)
r? `@ghost`
`@rustbot` modify labels: rollup
Port `tests/run-make-fulldeps/issue-19371` to ui-fulldeps
This test can run as an ordinary `tests/ui-fulldeps` test, with the help of some additional header variable substitutions to supply a sysroot and linker.
---
Unlike #125973, this test appears to be testing something vaguely useful and breakable, which is why I didn't just delete it.
Remove unused(?) `~/rustsrc` folder from docker script
Every time I run a docker image, the script creates an empty `~/rustsrc` folder. It doesn't seem to be referenced anywhere else, so I'd like to remove it.
Incidentally, this also documents DIST_TRY_BUILD as I fail to find it from a simple search any time I look for it to eg enable tests on try builds.
Winnow private method candidates instead of assuming any candidate of the right name will apply
partially reverts https://github.com/rust-lang/rust/pull/60721
My original motivation was just to avoid the `delay_span_bug` (by attempting to thread the `ErrorGuaranteed` through to here). But then I realized that the error message is wrong. It refers to the `Foo<A>::foo` instead of `Foo<B>::foo`. This is almost invisible, because both functions are the same, but on different lines, so `-Zui-testing` makes it so the test is the same no matter which of these two functions is referenced.
But there's a much more obvious bug: If `Foo<B>` does not have a `foo` method at all, but `Foo<A>` has a private `foo` method, then we'll refer to that one. This has now been fixed, and we report a normal `method not found` error.
The way this is done is by creating a list of all possible private functions (just like we create a list of the public functions that can actually be called), and then winnowing it by analyzing where bounds and `Self` types to see if any of the found methods can actually apply (again, just like with the list of public functions).
I wonder if there is room for doing the same thing with unstable functions instead of running all of method resolution twice.
r? ``@compiler-errors`` for method resolution stuff
delete bootstrap build before switching to bumped rustc
Technically, wiping bootstrap builds can increase the build time. But in practice, trying to manually resolve post-bump issues and even accidentally removing the entire build directory will result in a much greater loss of time. After all, the bootstrap build process is not a particularly lengthy operation.
Workaround for #125578
Update cargo
9 commits in 7a6fad0984d28c8330974636972aa296b67c4513..34a6a87d8a2330d8c9d578f927489689328a652d
2024-05-31 22:26:03 +0000 to 2024-06-04 15:31:01 +0000
- Silence the warning about forgetting the vendoring (rust-lang/cargo#13886)
- fix(vendor): Ensure sort happens for vendor (rust-lang/cargo#14004)
- fix(add): Avoid escaping double-quotes by using string literals (rust-lang/cargo#14006)
- refactor(source): Split `RecursivePathSource` out of `PathSource` (rust-lang/cargo#13993)
- doc: Add README for resolver-tests (rust-lang/cargo#13977)
- Allows the default git/gitoxide configuration to be obtained from the ENV and config (rust-lang/cargo#13687)
- refactor: Transition direct assertions from cargo-test-support to snapbox (rust-lang/cargo#13980)
- Fix: Skip deserialization of unrelated fields with overlapping name (rust-lang/cargo#14000)
- chore(deps): update alpine docker tag to v3.20 (rust-lang/cargo#13996)
r? ghost
Rollup of 12 pull requests
Successful merges:
- #123168 (Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude)
- #125273 (bootstrap: implement new feature `bootstrap-self-test`)
- #125683 (Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format)
- #125815 (`rustc_parse` top-level cleanups)
- #125903 (rustc_span: Inline some hot functions)
- #125906 (Remove a bunch of redundant args from `report_method_error`)
- #125920 (Allow static mut definitions with #[linkage])
- #125982 (Make deleting on LinkedList aware of the allocator)
- #125995 (Use inline const blocks to create arrays of `MaybeUninit`.)
- #125996 (Closures are recursively reachable)
- #126003 (Add a co-maintainer for the two ARMv4T targets)
- #126004 (Add another test for hidden types capturing lifetimes that outlive but arent mentioned in substs)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a co-maintainer for the two ARMv4T targets
This adds a second maintainer to the `armv4t-none-eabi` and `thumbv4t-none-eabi` targets, a necessary step on the path to Tier 2
`rustc_parse` top-level cleanups
A bunch of improvements in and around `compiler/rustc_parse/src/lib.rs`. Many of the changes streamline the API in that file from this (12 functions and one macro):
```
name args return type
---- ---- -----------
panictry_buffer! Result<T, Vec<Diag>> T
pub parse_crate_from_file path PResult<Crate>
pub parse_crate_attrs_from_file path PResult<AttrVec>
pub parse_crate_from_source_str name,src PResult<Crate>
pub parse_crate_attrs_from_source_str name,src PResult<AttrVec>
pub new_parser_from_source_str name,src Parser
pub maybe_new_parser_from_source_str name,src Result<Parser, Vec<Diag>>
pub new_parser_from_file path,error_sp Parser
maybe_source_file_to_parser srcfile Result<Parser, Vec<Diag>>
pub parse_stream_from_source_str name,src,override_sp TokenStream
pub source_file_to_stream srcfile,override_sp TokenStream
maybe_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>>
pub stream_to_parser stream,subparser_name Parser
```
to this:
```
name args return type
---- ---- -----------
unwrap_or_emit_fatal Result<T, Vec<Diag>> T
pub new_parser_from_source_str name,src Result<Parser, Vec<Diag>>
pub new_parser_from_file path,error_sp Result<Parser, Vec<Diag>>
new_parser_from_source_file srcfile Result<Parser, Vec<Diag>>
pub source_str_to_stream name,src,override_sp Result<TokenStream, Vec<Diag>>
source_file_to_stream srcfile,override_sp Result<TokenStream, Vec<Diag>>
```
I found the old API quite confusing, with lots of similar-sounding function names and no clear structure. I think the new API is much better.
r? `@spastorino`
Rewrite `suspicious-library`, `resolve-rename` and `incr-prev-body-beyond-eof` `run-make` tests in `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Some oddly specific ignore flags in `incr-prev-body-beyond-eof`:
```rs
// ignore-none
// ignore-nvptx64-nvidia-cuda
```
it could be interesting to run a try job, but it seems there is no nvidia-cuda in the CI settings (`jobs.yml`).
try-job: armhf-gnu
bootstrap: implement new feature `bootstrap-self-test`
Some of the bootstrap logics should be ignored during unit tests because they either make the tests take longer or cause them to fail. Therefore we need to be able to exclude them from the bootstrap when it's called by unit tests. This change introduces a new feature called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows us to keep the logic separate between compiler builds and bootstrap tests without needing messy workarounds (like checking if target names match those in the unit tests).
Also, resolves https://github.com/rust-lang/rust/issues/122090 (without having to create separate modules)
The `Input::File` and `Input::Text` cases should be very similar.
However, currently the `Input::File` case uses `catch_unwind` because,
until recently (#125815) there was a fallible version of
`new_parser_from_source_str` but only an infallible version of
`new_parser_from_file`. This difference wasn't fundamental, just an
overlooked gap in the API of `rustc_parse`.
Both of those operations are now fallible, so the `Input::File` and
`Input::Text` cases can made more similar, with no need for
`catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to
`Vec<Diag>`.
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
Lexing converts source text into a token stream. Parsing converts a
token stream into AST fragments. This commit renames several lexing
operations that have "parse" in the name. I think these names have been
subtly confusing me for years.
This is just a `s/parse/lex/` on function names, with one exception:
`parse_stream_from_source_str` becomes `source_str_to_stream`, to make
it consistent with the existing `source_file_to_stream`. The commit also
moves that function's location in the file to be just above
`source_file_to_stream`.
The commit also cleans up a few comments along the way.
Update books
## rust-lang/book
6 commits in 85442a608426d3667f1c9458ad457b241a36b569..5228bfac8267ad24659a81b92ec5417976b5edbc
2024-05-29 20:55:49 UTC to 2024-05-27 17:22:03 UTC
- Fix typo in ch10-03 (rust-lang/book#3539)
- Backport changes to ch 9 and 10 (rust-lang/book#3946)
- infra: correctly support preprocessors for nostarch (rust-lang/book#3944)
- Use `<kbd>` instead of `<span class="keystroke">` (rust-lang/book#3945)
- infra: Fix clippy warning in remove_markup (rust-lang/book#3943)
- fix: ch10-03 - misleading use of expect on .split (rust-lang/book#3939)
## rust-lang/edition-guide
2 commits in 0c68e90acaae5a611f8f5098a3c2980de9845ab2..bbaabbe088e21a81a0d9ae6757705020d5d7b416
2024-05-24 19:07:18 UTC to 2024-05-21 22:40:52 UTC
- 2024: Document reserving `gen` keyword (rust-lang/edition-guide#300)
- 2024: Document cargo changes (rust-lang/edition-guide#301)
## rust-embedded/book
1 commits in dd962bb82865a5284f2404e5234f1e3222b9c022..b10c6acaf0f43481f6600e95d4b5013446e29f7a
2024-05-31 08:51:50 UTC to 2024-05-31 08:51:50 UTC
- Add some explanations as to why exception re-entrancy may still be an issue in a multicore-environment. (rust-embedded/book#367)
## rust-lang/reference
6 commits in e356977fceaa8591c762312d8d446769166d4b3e..6019b76f5b28938565b251bbba0bf5cc5c43d863
2024-06-03 15:58:57 UTC to 2024-05-25 18:35:54 UTC
- Add Apple `target_abi` values to the example values (rust-lang/reference#1507)
- this needs a space (rust-lang/reference#1506)
- Mention Variadics With No Fixed Parameter (rust-lang/reference#1494)
- Add "scopes" chapter. (rust-lang/reference#1040)
- update patterns.md for const pattern RFC (rust-lang/reference#1456)
- document guarantee about evaluation of associated consts and const blocks (rust-lang/reference#1497)
## rust-lang/rust-by-example
3 commits in 20482893d1a502df72f76762c97aed88854cdf81..4840dca06cadf48b305d3ce0aeafde7f80933f80
2024-05-28 13:56:12 UTC to 2024-05-27 11:51:10 UTC
- Update mdbook-i18n-helpers to 0.3.3 (rust-lang/rust-by-example#1857)
- Fix CI failure (rust-lang/rust-by-example#1856)
- Add precision on From/Into asymmetry to from_into.md (rust-lang/rust-by-example#1855)
## rust-lang/rustc-dev-guide
4 commits in b6d4a4940bab85cc91eec70cc2e3096dd48da62d..6a7374bd87cbac0f8be4fd4877d8186d9c313985
2024-05-31 00:27:28 UTC to 2024-05-21 09:56:12 UTC
- Flesh out the "representing types" chapter (rust-lang/rustc-dev-guide#1985)
- sync the stage0 filename (rust-lang/rustc-dev-guide#1979)
- Add Rust for Linux notification group entry (rust-lang/rustc-dev-guide#1984)
- fix some typos (rust-lang/rustc-dev-guide#1983)
Handle no values cfgs with `--print=check-cfg`
This PR fix a bug with `--print=check-cfg`, where no values cfgs where not printed since we only printed cfgs that had at least one values.
The representation I choose is `CFG=`, since it doesn't correspond to any valid config, it also IMO nicely complements the `values()` (to indicate no values). Representing the absence of value by the absence of the value.
So for `cfg(feature, values())` we would print `feature=`.
I also added the missing tracking issue number in the doc.
r? ```@petrochenkov```
Align `Term` methods with `GenericArg` methods, add `Term::expect_*`
* `Term::ty` -> `Term::as_type`.
* `Term::ct` -> `Term::as_const`.
* Adds `Term::expect_type` and `Term::expect_const`, and uses them in favor of `.ty().unwrap()`, etc.
I could also shorten these to `as_ty` and then do `GenericArg::as_ty` as well, but I do think the `as_` is important to signal that this is a conversion method, and not a getter, like `Const::ty` is.
r? types
ARM Target Docs Update
Updates the ARM target docs, drawing more attention to the `arm-none-eabi` target group by placing all targets *within* that group as a sub-list in the Table of Contents.
Also updates the `armv4t-none-eabi` page (maintainer signoff: I'm that target's maintainer) to clarify that the page covers the arm version and the thumb version of the target, but that the target group page has the full info because there's nothing really specific to say for those targets.
Add tracking issue and unstable book page for `"vectorcall"` ABI
Originally added in 2015 by #30567, the Windows `"vectorcall"` ABI didn't have a tracking issue until now.
Tracking issue: #124485
Some of the bootstrap logics should be ignored during unit tests because they either
make the tests take longer or cause them to fail. Therefore we need to be able to exclude
them from the bootstrap when it's called by unit tests. This change introduces a new feature
called `bootstrap-self-test`, which is enabled on bootstrap unit tests by default. This allows
us to keep the logic separate between compiler builds and bootstrap tests without needing messy
workarounds (like checking if target names match those in the unit tests).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Make `WHERE_CLAUSES_OBJECT_SAFETY` a regular object safety violation
#### The issue
In #50781, we have known about unsound `where` clauses in function arguments:
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible;
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
// `where` clause satisfied for the object, meaning that the function now *looks* callable.
impl Impossible for dyn Foo {}
fn main() {
let x: &dyn Foo = &&();
x.impossible();
}
```
... which currently segfaults at runtime because we try to call a method in the vtable that doesn't exist. :(
#### What did u change
This PR removes the `WHERE_CLAUSES_OBJECT_SAFETY` lint and instead makes it a regular object safety violation. I choose to make this into a hard error immediately rather than a `deny` because of the time that has passed since this lint was authored, and the single (1) regression (see below).
That means that it's OK to mention `where Self: Trait` where clauses in your trait, but making such a trait into a `dyn Trait` object will report an object safety violation just like `where Self: Sized`, etc.
```rust
trait Impossible {}
trait Foo {
fn impossible(&self)
where
Self: Impossible; // <~ This definition is valid, just not object-safe.
}
impl Foo for &() {
fn impossible(&self)
where
Self: Impossible,
{}
}
fn main() {
let x: &dyn Foo = &&(); // <~ THIS is where we emit an error.
}
```
#### Regressions
From a recent crater run, there's only one crate that relies on this behavior: https://github.com/rust-lang/rust/pull/124305#issuecomment-2122381740. The crate looks unmaintained and there seems to be no dependents.
#### Further
We may later choose to relax this (e.g. when the where clause is implied by the supertraits of the trait or something), but this is not something I propose to do in this FCP.
For example, given:
```
trait Tr {
fn f(&self) where Self: Blanket;
}
impl<T: ?Sized> Blanket for T {}
```
Proving that some placeholder `S` implements `S: Blanket` would be sufficient to prove that the same (blanket) impl applies for both `Concerete: Blanket` and `dyn Trait: Blanket`.
Repeating here that I don't think we need to implement this behavior right now.
----
r? lcnr
Show files produced by `--emit foo` in json artifact notifications
Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`.
Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477
Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: https://github.com/hintron/computer-enhance/issues/35
This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files.
Most users won't notice this behavior, to be affected by it all of the following must hold:
- user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything)
- user must specify both `--emit xxx` and `--json artifacts`
- user must refuse to handle unknown artifact types
- user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit #88829 / #89149
The flag propagates cargo configs to `rustc-perf --cargo-config`,
which is particularly useful when the environment is air-gapped,
and you want to use the default set of training crates vendored
in the rustc-src tarball.
