Remove `Path::is_ident`.
It checks that a path has a single segment that matches the given symbol, and that there are zero generic arguments. It has a single use.
We also have `impl PartialEq<Symbol> for Path` which does exactly the same thing *except* it doesn't check for zero generic arguments, which seems like an oversight. It has numerous uses.
This commit removes `Path::is_ident`, adds a test for zero generic arguments to `PartialEq<Symbol> for Path`, and changes the single use of `is_ident` to instead use `==`.
r? `@wesleywiser`
Remove pre-expansion AST stats.
They're very little value, because they only measure the top-level `main.rs` or `lib.rs` file. (Other `.rs` files don't get read and parsed until expansion occurs.)
I saw an example recently where the pre-expansion AST was 3KB in size and the post-expansion AST was 66MB.
I kept the "POST EXPANSION" in the output header, I think that's useful information to avoid possible confusion about when the measurement happens.
r? `@davidtwco`
Use the informative error as the main const eval error message
r? `@RalfJung`
I only did the minimal changes necessary to the const eval error machinery. I'd prefer not to mix test changes with refactorings 😆
Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`
Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all).
Removed:
- `conv_from_spec_abi` replaced by `AbiMap::canonize_abi`
- `adjust_abi` replaced by same
- `Conv::PreserveAll` as unused
- `Conv::Cold` as unused
- `enum Conv` replaced by `enum CanonAbi`
target-spec.json changes:
- If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g.
```json
"entry-abi": "C",
"entry-abi": "win64",
"entry-abi": "aapcs",
```
Merge `compiler-builtins` as a Josh subtree
Use the Josh [1] utility to add `compiler-builtins` as a subtree, which
will allow us to stop using crates.io for updates. This is intended to
help resolve some problems when unstable features change and require
code changes in `compiler-builtins`, which sometimes gets trapped in a
bootstrap cycle.
This was done using `josh-filter` built from the r24.10.04 tag:
git fetch https://github.com/rust-lang/compiler-builtins.git 233434412fe7eced8f1ddbfeddabef1d55e493bd
josh-filter ":prefix=library/compiler-builtins" FETCH_HEAD
git merge --allow-unrelated FILTERED_HEAD
The HEAD in the `compiler-builtins` repository is 233434412f ("fix an if
statement that can be collapsed").
[1]: https://github.com/josh-project/josh
This adds an `iter!` macro that can be used to create movable
generators.
This also adds a yield_expr feature so the `yield` keyword can be used
within iter! macro bodies. This was needed because several unstable
features each need `yield` expressions, so this allows us to stabilize
them separately from any individual feature.
Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Co-authored-by: Travis Cross <tc@traviscross.com>
Deconstruct values in the THIR visitor
I continue to add deconstruction for task rust-lang/rust#141849
The changes concern a more complex part of the task `compiler/rustc_hir/src/intravisit.rs`
r? `@nnethercote`
Deconstruct values in the THIR visitor
Hi! I am a beginner rust developer.
I'm trying to solve your problem rust-lang/rust#141849
I see that 2 files need to be corrected, so I’m starting with a simpler step, `compiler/rustc_middle/src/thir/visit.rs`
r? `@krikera`
fix(#141141): When expanding `PartialEq`, check equality of scalar types first.
Fixesrust-lang/rust#141141.
Now, `cs_eq` function of `partial_eq.rs` compares [scalar types](https://doc.rust-lang.org/rust-by-example/primitives.html#scalar-types) first.
- Add `is_scalar` field to `FieldInfo`.
- Add `is_scalar` method to `TyKind`.
- Pass `FieldInfo` via `CsFold::Combine` and refactor code relying on it.
- Implement `TryFrom<&str>` and `TryFrom<Symbol>` for FloatTy.
- Implement `TryFrom<&str>` and `TryFrom<Symbol>` for IntTy.
- Implement `TryFrom<&str>` and `TryFrom<Symbol>` for UintTy.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#141554 (Improve documentation for codegen options)
- rust-lang/rust#141817 (rustc_llvm: add Windows system libs only when cross-compiling from Wi…)
- rust-lang/rust#141843 (Add `visit_id` to ast `Visitor`)
- rust-lang/rust#141881 (Subtree update of `rust-analyzer`)
- rust-lang/rust#141898 ([rustdoc-json] Implement PartialOrd and Ord for rustdoc_types::Id)
- rust-lang/rust#141921 (Disable f64 minimum/maximum tests for arm 32)
- rust-lang/rust#141930 (Enable triagebot `[concern]` functionality)
- rust-lang/rust#141936 (Decouple "reporting in deps" from `FutureIncompatibilityReason`)
- rust-lang/rust#141949 (move `test-float-parse` tool into `src/tools` dir)
r? `@ghost`
`@rustbot` modify labels: rollup
Decouple "reporting in deps" from `FutureIncompatibilityReason`
The reason should just be it -- the reason. It never felt right to me that it was also responsible for whatever we include the warning in cargo's reports.
It gets especially unruly if you want to add non-`FutureReleaseError*` warnings which are included in the reports.
I just added a field to `FutureIncompatibleInfo` to control whatever the diagnostic is included in the cargo's reports.
Add `visit_id` to ast `Visitor`
This helps with efforts to deduplicate the `MutVisitor` and the `Visitor` code. All users of `Visitor`'s methods that have extra `NodeId` as parameters really just want to visit the id on its own.
Also includes some methods deduplicated and cleaned up as a result of this change.
r? oli-obk
It checks that a path has a single segment that matches the given
symbol, and that there are zero generic arguments. It has a single use.
We also have `impl PartialEq<Symbol> for Path` which does exactly the
same thing *except* it doesn't check for zero generic arguments, which
seems like an oversight. It has numerous uses.
This commit removes `Path::is_ident`, adds a test for zero generic
arguments to `PartialEq<Symbol> for Path`, and changes the single use of
`is_ident` to instead use `==`.
Fix borrowck mentioning a name from an external macro we (deliberately) don't save
Most of the info is already in the title 🤷Closesrust-lang/rust#141764
Don't declare variables in `ExprKind::Let` in invalid positions
Handle `let` expressions in invalid positions specially during resolve in order to avoid making destructuring-assignment expressions that reference (invalid) variables that have not yet been delcared yet.
See further explanation in test and comment in the source.
Fixesrust-lang/rust#141844
Async drop - type instead of async drop fn, fixes#140484Fixes: rust-lang/rust#140484Fixes: rust-lang/rust#140500
Fixes ICE, when type is provided in AsyncDrop trait instead of `async fn drop()`.
Fixes ICE, when async drop fn has wrong signature.
They're very little value, because they only measure the top-level
`main.rs` or `lib.rs` file. (Other `.rs` files don't get read and parsed
until expansion occurs.)
I saw an example recently where the pre-expansion AST was 3KB in size
and the post-expansion AST was 66MB.
I kept the "POST EXPANSION" in the output header, I think that's useful
information to avoid possible confusion about when the measurement
happens.
Warn when gold was used as the linker
gold has been deprecated recently and is known to behave incorrectly around Rust programs, including miscompiling `#[used(linker)]`. Tell people to switch to a different linker instead.
closesrust-lang/rust#141748
r? bjorn3
`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res`
results, one per namespace (type, value, or macro). `lower_import_res`
takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the
`SmallVec`. This is pretty weird. The input `PerNS` makes it clear which
`Res` belongs to which namespace, but the `SmallVec` throws that
information away.
And code that operates on the `SmallVec` tends to use iteration (or even
just grabbing the first entry!) without knowing which namespace the
`Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible
type to use here, because it can contain any number of elements (even
though it's optimized for 3 in this case).
This commit changes `UsePath` so it also contains a
`PerNS<Option<Res<HirId>>>`. This type preserves more information and is
more self-documenting. The commit also changes a lot of the use sites to
access the result for a particular namespace. E.g. if you're looking up
a trait, it will be in the `Res` for the type namespace if it's present;
it's silly to look in the `Res` for the value namespace or macro
namespace. Overall I find the new code much easier to understand.
However, some use sites still iterate. These now use `present_items`
because that filters out the `None` results.
Also, `redundant_pub_crate.rs` gets a bigger change. A
`UseKind:ListStem` item gets no `Res` results, which means the old `all`
call in `is_not_macro_export` would succeed (because `all` succeeds on
an empty iterator) and the `ListStem` would be ignored. This is what we
want, but was more by luck than design. The new code detects `ListStem`
explicitly. The commit generalizes the name of that function
accordingly.
Finally, the commit also removes the `use_path` arena, because
`PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be
allocated in the arena shared by all `Copy` types.
Optionally don't steal the THIR
The THIR being stolen is a recurrent pain for authors of rustc drivers. This makes it optional, so that the `thir_body` query can still be used after analysis of the crate has completed.
allow macro_use as first segment
Fixesrust-lang/rust#140255
This issue may raise a question: It's reasonable an external crate name or import target be legally named `macro_use`?
