Originally, this was kinda half-allowed. There were some primitive
checks in place that looked at the span to see whether the input was
likely a literal. These "source literal" checks are needed because the
spans created during `format_args` parsing only make sense when it is
indeed a literal that was written in the source code directly.
This is orthogonal to the restriction that the first argument must be a
"direct literal", not being exanpanded from macros. This restriction was
imposed by [RFC 2795] on the basis of being too confusing. But this was
only concerned with the argument of the invocation being a literal, not
whether it was a source literal (maybe in spirit it meant it being a
source literal, this is not clear to me).
Since the original check only really cared about source literals (which
is good enough to deny the `format_args!(concat!())` example), macros
expanding to `format_args` invocations were able to use implicit
captures if they spanned the string in a way that lead back to a source
string.
The "source literal" checks were not strict enough and caused ICEs in
certain cases (see # 106191 (the space is intended to avoid spammy
backreferences)). So I tightened it up in # 106195 to really only work
if it's a direct source literal.
This caused the `indoc` crate to break. `indoc` transformed the source
literal by removing whitespace, which made it not a "source literal"
anymore (which is required to fix the ICE). But since `indoc` spanned
the literal in ways that made the old check think that it's a literal,
it was able to use implicit captures (which is useful and nice for the
users of `indoc`).
This commit properly seperates the previously introduced concepts of
"source literal" and "direct literal" and therefore allows `indoc`
invocations, which don't create "source literals" to use implicit
captures again.
[RFC 2795]: https://rust-lang.github.io/rfcs/2795-format-args-implicit-identifiers.html#macro-hygiene
Remove `identity_future` indirection
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]`annotation.
Fixes https://github.com/rust-lang/rust/issues/104826.
Gracefully handle `#[target_feature]` on statics
The was careful around not calling `fn_sig` on not-functions but well, it wasn't careful enough. This commit makes it a little more careful and also adds tests for a bunch more item kinds.
I was sadly not able to fully bless the test locally because I'm on an aarch64 machine but I hope some manual editing made it work 😅Fix#109079
The was careful around not calling `fn_sig` on not-functions but well,
it wasn't careful enough. This commit makes it a little more careful and
also adds tests for a bunch more item kinds.
Remove `box_syntax`
r? `@Nilstrieb`
This removes the feature `box_syntax`, which allows the use of `box <expr>` to create a Box, and finalises removing use of the feature from the compiler. `box_patterns` (allowing the use of `box <pat>` in a pattern) is unaffected.
It also removes `ast::ExprKind::Box` - the only way to create a 'box' expression now is with the rustc-internal `#[rustc_box]` attribute.
As a temporary measure to help users move away, `box <expr>` now parses the inner expression, and emits a `MachineApplicable` lint to replace it with `Box::new`
Closes#49733
Strengthen state tracking in const-prop
Some/many of the changes are replicated between both the const-prop lint and the const-prop optimization.
Behaviour changes:
- const-prop opt does not give a span to propagated values. This was useless as that span's primary purpose is to diagnose evaluation failure in codegen.
- we remove the `OnlyPropagateInto` mode. It was only used for function arguments, which are better modeled by a write before entry.
- the tracking of assignments and discriminants make clearer that we do nothing in `NoPropagation` mode or on indirect places.
Rollup of 8 pull requests
Successful merges:
- #108651 (Forbid the use of `#[target_feature]` on `main`)
- #109009 (rustdoc: use restricted Damerau-Levenshtein distance for search)
- #109026 (Introduce `Rc::into_inner`, as a parallel to `Arc::into_inner`)
- #109029 (Gate usages of `dyn*` and const closures in macros)
- #109031 (Rename `config.toml.example` to `config.example.toml`)
- #109032 (Use `TyCtxt::trait_solver_next` in some places)
- #109047 (typo)
- #109052 (Add eslint check for rustdoc-gui tester)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Gate usages of `dyn*` and const closures in macros
We silently accepted `dyn*` and const closures in macros as long as they didn't expand to anything containing these experimental features, unlike other gated features such as `for<'a>` binders on closures, etc. Let's not do that, to make sure nobody begins relying on this.
Check that a query has not completed and is not executing before starting it
This fixes a race in the query system where we only checked if the query was currently executing, but not if it was already completed, causing queries to re-execute.
r? `@cjgillot`
Ensure value is on the on-disk cache before returning from `ensure()`.
The current logic for `ensure()` a query just checks that the node is green in the dependency graph.
However, a lot of places use `ensure()` to prevent the query from being called later. This is the case before stealing a query result.
If the query is actually green but the value is not available in the on-disk cache, `ensure` would return, but a subsequent call to the full query would run the code, and attempt to read from a stolen value.
This PR conforms the query system to the usage by checking whether the queried value is loadable from disk before returning.
Sadly, I can't manage to craft a proper test...
Should fix all instances of "attempted to read from stolen value".
Rollup of 9 pull requests
Successful merges:
- #108726 (tidy: enforce comment blocks to have an even number of backticks)
- #108797 (Allow binary files to go through the `FileLoader`)
- #108841 (Add suggestion to diagnostic when user has array but trait wants slice. (rebased))
- #108984 (bootstrap: document tidy)
- #109013 (Give proper error message when tcx wasn't passed to decoder)
- #109017 (remove duplicated calls to sort_string)
- #109018 (Expand on the allocator comment in `rustc-main`)
- #109028 (Add eslint checks for rustdoc-js tester)
- #109034 (Commit some tests for the new solver + lazy norm)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Give proper error message when tcx wasn't passed to decoder
I hit this yesterday and found it very confusing, even though the solution to the problem is very simple.
Add suggestion to diagnostic when user has array but trait wants slice. (rebased)
Rebase of #91314, except for change to multipart suggestion
Resolves#90528
r? ``@compiler-errors`` since you requested the multipart suggestion
Allow binary files to go through the `FileLoader`
I'd like for `include_bytes!` to go through the `FileLoader` in an out-of-tree `rustc_driver` wrapper, and I can't find a reason it's not already done. It seems like most folks providing a custom `FileLoader` would want this too, so I added it.
I can solve my problem in other ways if there's a strong reason not to do it, but it seems simple and harmless.
tidy: enforce comment blocks to have an even number of backticks
After PR #108694, most unmatched backticks in `compiler/` comments have been eliminated. This PR adds a tidy lint to ensure no new unmatched backticks are added, and either addresses the lint in the remaining instances it found, or allows it.
Very often, backtick containing sections wrap around lines, for example:
```Rust
// This function takes a tuple `(Vec<String>,
// Box<[u8]>)` and transforms it into `Vec<u8>`.
```
The lint is implemented to work on top of blocks, counting each line with a `//` into a block, and counting if there are an odd or even number of backticks in the entire block, instead of looking at just a single line.
Avoid unnecessary hashing
I noticed some stable hashing being done in a non-incremental build. It turns out that some of this is necessary to compute the crate hash, but some of it is not. Removing the unnecessary hashing is a perf win.
r? `@cjgillot`
Simplify message paths
This makes it easier to open the messages file. Right now I have to first click on the `locales` dir to open it, and then on the `en-US.ftl` file. `Cargo.toml` and `build.rs` files are also in the top level, and I think there should not be more than one file, so a directory isn't really needed. The [chosen strategy for pontoon adoption](https://rust-lang.zulipchat.com/#narrow/stream/336883-i18n/topic/pontoon.20and.20next.20steps) is out of tree. Even if this descision is changed in the future, the `messages.ftl` approach is also compatible with non-english translations living in-tree, as long as the non-english translations don't live in the `compiler/rustc_foo/` directories but in different ones. That would also be helpful for grepability purposes.
The commit was the result of automated changes:
```
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
```
r? `@davidtwco`
I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`.
Turned out to be a more general problem as `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist.
This PR lowers `ptr::read(p)` to `copy *p` in MIR, which fortuitiously also improves the IR we give to LLVM for things like `mem::replace`.
This makes it easier to open the messages file while developing on features.
The commit was the result of automatted changes:
for p in compiler/rustc_*; do mv $p/locales/en-US.ftl $p/messages.ftl; rmdir $p/locales; done
for p in compiler/rustc_*; do sed -i "s#\.\./locales/en-US.ftl#../messages.ftl#" $p/src/lib.rs; done
Move dep graph methods to DepGraphData to avoid branches and `unwrap`s
This moves methods from `DepGraph` to `DepGraphData` which makes the code a bit cleaner since the dep graph is unconditionally available. It also changes `try_execute_query` to only branch on dep graph availability once, removing unnecessary branches and `unwrap`s.
This is based on https://github.com/rust-lang/rust/pull/108134 and https://github.com/rust-lang/rust/pull/108167.
Performance impact of just the last commit:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7354s</td><td align="right">1.7242s</td><td align="right"> -0.64%</td></tr><tr><td>🟣 <b>clap</b>:check:initial</td><td align="right">2.0813s</td><td align="right">2.0687s</td><td align="right"> -0.61%</td></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.4554s</td><td align="right">0.4550s</td><td align="right"> -0.09%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2528s</td><td align="right">0.2521s</td><td align="right"> -0.27%</td></tr><tr><td>🟣 <b>hyper</b>:check:initial</td><td align="right">0.3222s</td><td align="right">0.3214s</td><td align="right"> -0.25%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1339s</td><td align="right">0.1333s</td><td align="right"> -0.38%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9484s</td><td align="right">0.9455s</td><td align="right"> -0.30%</td></tr><tr><td>🟣 <b>regex</b>:check:initial</td><td align="right">1.1805s</td><td align="right">1.1727s</td><td align="right"> -0.66%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.3305s</td><td align="right">0.3307s</td><td align="right"> 0.08%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5453s</td><td align="right">1.5374s</td><td align="right"> -0.51%</td></tr><tr><td>🟣 <b>syn</b>:check:initial</td><td align="right">1.9230s</td><td align="right">1.9206s</td><td align="right"> -0.12%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.6340s</td><td align="right">0.6333s</td><td align="right"> -0.11%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">5.8623s</td><td align="right">5.8536s</td><td align="right"> -0.15%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:initial</td><td align="right">7.2873s</td><td align="right">7.2786s</td><td align="right"> -0.12%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:unchanged</td><td align="right">1.8378s</td><td align="right">1.8478s</td><td align="right"> 0.54%</td></tr><tr><td>Total</td><td align="right">26.5300s</td><td align="right">26.4750s</td><td align="right"> -0.21%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9976s</td><td align="right"> -0.24%</td></tr></table>
r? `@cjgillot`
Rollup of 9 pull requests
Successful merges:
- #104363 (Make `unused_allocation` lint against `Box::new` too)
- #106633 (Stabilize `nonzero_min_max`)
- #106844 (allow negative numeric literals in `concat!`)
- #108071 (Implement goal caching with the new solver)
- #108542 (Force parentheses around `match` expression in binary expression)
- #108690 (Place size limits on query keys and values)
- #108708 (Prevent overflow through Arc::downgrade)
- #108739 (Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time)
- #108806 (Querify register_tools and post-expansion early lints)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Querify register_tools and post-expansion early lints
The 2 extra queries correspond to code that happen before and after macro expansion, and don't need the resolver to exist.
Prevent the `start_bx` basic block in codegen from having two `Builder`s at the same time
Here, at the same time, there are two `start_llbb` builder, this should be unexpected.
Place size limits on query keys and values
This just prevents these from growing accidentally too large. I'm not sure if there's an easy way to also print the actual size too.
Implement goal caching with the new solver
Maybe it's wrong, idk. Opening mostly for first impressions before I go to sleep.
r? ``@lcnr,`` cc ``@cjgillot``
allow negative numeric literals in `concat!`
Fixes#106837
While *technically* negative numeric literals are implemented as unary operations, users can reasonably expect that negative literals are treated the same as positive literals.
Make `unused_allocation` lint against `Box::new` too
Previously it only linted against `box` syntax, which likely won't ever be stabilized, which is pretty useless. Even now I'm not sure if it's a meaningful lint, but it's at least something 🤷
This means that code like the following will be linted against:
```rust
Box::new([1, 2, 3]).len();
f(&Box::new(1)); // where f : &i32 -> ()
```
The lint works by checking if a `Box::new` (or `box`) expression has an a borrow adjustment, meaning that the code that first stores the box in a variable won't be linted against:
```rust
let boxed = Box::new([1, 2, 3]); // no lint
boxed.len();
```
Before, it said "global_allocator does nothing". Now it gives you
suggestions for what to do if you want to change the global allocator
(which is likely the main reason you'd be reading the comment).
Directly construct Inherited in typeck.
Using `InheritedBuilder` + a closure does not seem necessary any more.
+ a few opportunistic simplifications to typeck entry point.
Honor current target when checking conditional compilation values
This is fixed by simply using the currently registered target in the current session. We need to use it because of target json that are not by design included in the rustc list of targets.
Fixes https://github.com/rust-lang/rust/issues/108941
Add note when matching token with nonterminal
The current error message is _really_ confusing. The implementation is slightly hacky, but not that much more hacky than all this nonterminal stuff..
r? ``@petrochenkov``
Rollup of 9 pull requests
Successful merges:
- #106921 (Add documentation about the memory layout of `Cell`)
- #108828 (Emit alias-eq when equating numeric var and projection)
- #108834 (Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type)
- #108900 (fix(lexer): print whitespace warning for \x0c)
- #108930 (feat: implement better error for manual impl of `Fn*` traits)
- #108937 (improve readability of winnowing)
- #108947 (Don't even try to combine consts with incompatible types)
- #108976 (Update triagebot rust-analyzer team mention)
- #108983 (Forbid `#[target_feature]` on safe default implementations)
Failed merges:
- #108950 (Directly construct Inherited in typeck.)
r? `@ghost`
`@rustbot` modify labels: rollup
Add more license annotations
This PR updates the `.reuse/dep5` file to include more accurate licensing data for everything in the repository (*excluding* submodules and dependencies). Some decisions were made in this PR:
* The standard copyright attribution for files maintained by us is "The Rust Project Developers (see https://thanks.rust-lang.org)", to avoid having to maintain an in-tree `AUTHORS` file.
* For files that have specific licensing terms, we added the terms to the `.reuse/dep5` rather than adding SPDX comments in the files themselves.
* REUSE picks up any comment/text line with `Copyright` on it, so I had to sprinkle around `REUSE-IgnoreStart` and `REUSE-IgnoreEnd` comments.
The rendered `COPYRIGHT` file is available at https://gist.github.com/pietroalbini/efb81103f69596d39758114f3f6a8688.
r? `@pnkfelix`
Remove an extraneous include
SymbolWrapper.cpp doesn't use std::optional or llvm::Optional, so this patch removes the extraneous include. Note that llvm/ADT/Optional.h has been deprecated upstream. This patch ensures that SymbolWrapper.cpp continues to compile even after the upcoming removal of Optional.h.
Add `--no-undefined-version` link flag and fix associated breakage
LLVM upstream sets `--no-undefined-version` by default in lld: https://reviews.llvm.org/D135402.
Due to a bug in how version scripts are generated, this breaks the `dylib` output type for most crates. See https://github.com/rust-lang/rust/issues/105967#issuecomment-1428671533 for details.
This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches `rustc` to not attempt to export `__rust_*` allocator symbols when they weren't generated.
Fixes#105967
Stabilize movbe target feature
Almost all "old" x86 target features are stable. As far as I can tell, these are the last two unstable features in the `x86-64-v2` or `x86-64-v3` microarchitecture levels, so I'm not sure if it was an oversight or if they're still unstable for a reason (see #106323 for `f16c`).
Note that this only stabilizes the target features, and not the intrinsics.
cc ```@Amanieu```
r? ```@rust-lang/lang```
Relax ordering rules for `asm!` operands
The `asm!` and `global_asm!` macros require their operands to appear strictly in the following order:
- Template strings
- Positional operands
- Named operands
- Explicit register operands
- `clobber_abi`
- `options`
This is overly strict and can be inconvienent when building complex `asm!` statements with macros. This PR relaxes the ordering requirements as follows:
- Template strings must still come before all other operands.
- Positional operands must still come before named and explicit register operands.
- Named and explicit register operands can be freely mixed.
- `options` and `clobber_abi` can appear in any position after the template strings.
r? ```````@joshtriplett```````
Don't even try to combine consts with incompatible types
~I left a more detailed explanation for why this fixes this issue in the UI test, but in general, we should not try to unify const infer vars and rigid consts if they have incompatible types. That's because we don't want something like a `ConstArgHasType` predicate to suddenly go from passing to failing, or vice versa, due to a shallow resolve.~
1. Use the `type_of` for a parameter in `try_eval_lit_or_param`, instead of the "expected" type from a `WithOptConstParam` def id.
2. Don't combine consts that have incompatible types.
Fixes#108781
feat: implement better error for manual impl of `Fn*` traits
Fixes#39259
cc `@estebank` (you gave me some advice in the linked issue, would you like to review?)
Do not ICE when we have fn pointer `Fn` obligations with bound vars in the self type
We never supported solving `for<'a> fn(&'a ()): Fn(&'a ())` -- I tried to add that support in #104929, but iirc `@lcnr` wanted to support this more generally by eagerly instantiating trait predicate binders with placeholders. That never happened due to blockers in the old solver, but we probably shouldn't ICE in any case.
On the bright side, this passes on the new solver :^)
Emit alias-eq when equating numeric var and projection
This doesn't fix everything having to do with projections and infer vars, but it does fix a common case I saw in HIR typeck.
r? `@lcnr`
Rollup of 9 pull requests
Successful merges:
- #108879 (Unconstrained terms should account for infer vars being equated)
- #108936 (Rustdoc: don't hide anonymous reexport)
- #108940 (Add myself to compiler reviewers list)
- #108945 (Make some report and emit errors take DefIds instead of BodyIds)
- #108946 (Document the resulting values produced when using `From<bool>` on floats)
- #108956 (Make ptr::from_ref and ptr::from_mut in #106116 const.)
- #108960 (Remove `body_def_id` from `Inherited`)
- #108963 (only call git on git checkouts during bootstrap)
- #108964 (Fix the docs for pointer method with_metadata_of)
Failed merges:
- #108950 (Directly construct Inherited in typeck.)
r? `@ghost`
`@rustbot` modify labels: rollup
Introduce a no-op `PlaceMention` statement for `let _ =`.
Fixes https://github.com/rust-lang/rust/issues/54003
Fixes https://github.com/rust-lang/rust/issues/80059
Split from https://github.com/rust-lang/rust/pull/101500
This PR introduces a new `PlaceMention` statement dedicated to matches that neither introduce bindings nor ascribe types. Without this, all traces of the match would vanish from MIR, making it impossible to diagnose unsafety or use in #101500.
This allows to mark `let _ = <unsafe union access or dereference>` as requiring an unsafe block.
Nominating for lang team, as this introduces an extra error.
Remove `body_def_id` from `Inherited`
We can just use the body id from the obligation cause.
Follow-up to #108945, only my commit is relevant.
r? `@cjgillot` cc `@spastorino`
Unconstrained terms should account for infer vars being equated
Follow-up from the canonicalization PR, wanted to break this one out so I can approve the other PR.
r? `@lcnr`
This is fixed by simply using the currently registered target in the
current session. We need to use it because of target json that are not
by design included in the rustc list of targets.
feat/refactor: improve errors in case of ident with number at start
Improve parser code when we parse a integer (or float) literal but expect an identifier. We emit an error message saying that identifiers can't begin with numbers. This PR just improves that code and expands it to all identifiers. Note that I haven't implemented error recovery (this didn't exist before anyway), I might do that in a follow up PR.
Rollup of 8 pull requests
Successful merges:
- #108754 (Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous)
- #108759 (1.41.1 supported 32-bit Apple targets)
- #108839 (Canonicalize root var when making response from new solver)
- #108856 (Remove DropAndReplace terminator)
- #108882 (Tweak E0740)
- #108898 (Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap)
- #108911 (Improve rustdoc-gui/tester.js code a bit)
- #108916 (Remove an unused return value in `rustc_hir_typeck`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not consider `&mut *x` as mutating `x` in `CopyProp`
This PR removes an unfortunate overly cautious case from the current implementation.
Found by https://github.com/rust-lang/rust/pull/105274 cc `@saethlin`
Canonicalize root var when making response from new solver
During trait solving, if we equate two inference variables `?0` and `?1` but don't equate them with any rigid types, then `InferCtxt::probe_ty_var` will return `Err` for both of these. The canonicalizer code will then canonicalize the variables independently(!), and the response will not reflect the fact that these two variables have been made equal.
This hinders inference and I also don't think it's sound? I haven't thought too much about it past that, so let's talk about it.
r? ``@lcnr``
Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous
Fixes#108721
The problem here is that when we're checking `is_sized_raw` during codegen on some type that has a lot of opaques in it, something emits several nested obligations that are individually ambiguous, but when processed together in a loop then apply modulo regions. Since the `evaluate_predicates_recursively` inner loop doesn't process predicates until they stop changing, we return `EvaluatedToAmbig`, which makes the sized check return false incorrectly. See:
f15f0ea739/compiler/rustc_trait_selection/src/traits/select/mod.rs (L596-L606)
... Compared to the analogous loop in the new solver:
f15f0ea739/compiler/rustc_trait_selection/src/solve/mod.rs (L481-L512)
To fix this, if we get ambiguous during `pred_known_to_hold_modulo_regions`, just retry the obligation in a fulfillment context.
--
Unfortunately... I don't have a test for this. I've only tested this locally. Pending minimization :/
r? types
Rename `MapInPlace` as `FlatMapInPlace`.
After removing the `map_in_place` method, which isn't much use because modifying every element in a collection such as a `Vec` can be done trivially with iteration.
r? ``@lqd``
Suppress copy impl error when post-normalized type references errors
Suppress spurious errors from the `Copy` impl validity check when fields have bad types *post*-normalization, instead of just pre-normalization.
----
The const-generics test regressed recently due to #107965, cc `````@BoxyUwU.`````
* I think it's because `[_; 0u32]: Copy` now fails to hold because a nested obligation `ConstArgHasType(0u32, usize)` fails.
* It's interesting that `[const_error]` shows up in the type only after normalization, though, but I'm pretty sure that it's due to the evaluate call that happens when normalizing unevaluated consts.
StableMIR: Proof-of-concept implementation + test
This PR is part of the [project Stable MIR](https://github.com/rust-lang/project-stable-mir). The PR deletes old re-exports from rustc_smir and introduces a proof-of-concept implementation for APIs to retrieve crate information.
The implementation follows the [design described here](https://hackmd.io/XhnYHKKuR6-LChhobvlT-g?view), but instead of using separate crates for the implementation, it uses separate modules inside `rustc_smir`.
The API introduced at this point should be seen just as an example on how we are planning to structure the communication between tools and the compiler.
I have not explored yet what should be the right granularity, the best starting point for users, neither the best way to implement it.
r? ``````@oli-obk``````
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
always resolve to universal regions if possible
`RegionConstraintCollector::opportunistic_resolve_var`, which is used in canonicalization and projection logic, doesn't resolve the region var to an equal universal region. So if we have equated `'static == '1 == '2`, it doesn't resolve `'1` or `'2` to `'static`. Now it does!
Addresses review comment https://github.com/rust-lang/rust/pull/107376#discussion_r1093233687.
r? `@lcnr`
In case a variable is unified with two universal regions from different
universes, use the one with the lower universe as it has a higher chance
of being compatible with the variable.
SymbolWrapper.cpp doesn't use std::optional or llvm::Optional, so this
patch removes the extraneous include. Note that llvm/ADT/Optional.h
has been deprecated upstream. This patch ensures that
SymbolWrapper.cpp continues to compile even after the upcoming removal
of Optional.h.
Do not implement HashStable for HashSet (MCP 533)
This PR removes all occurrences of `HashSet` in query results, replacing it either with `FxIndexSet` or with `UnordSet`, and then removes the `HashStable` implementation of `HashSet`. This is part of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533), that is, removing the `HashStable` implementations of all collection types with unstable iteration order.
The changes are mostly mechanical. The only place where additional sorting is happening is in Miri's override implementation of the `exported_symbols` query.
After removing the `map_in_place` method, which isn't much use because
modifying every element in a collection such as a `Vec` can be done
trivially with iteration.
The crate hash is needed:
- if debug assertions are enabled, or
- if incr. comp. is enabled, or
- if metadata is being generated, or
- if `-C instrumentation-coverage` is enabled.
This commit avoids computing the crate hash when these conditions are
all false, such as when doing a release build of a binary crate.
It uses `Option` to store the hashes when needed, rather than
computing them on demand, because some of them are needed in multiple
places and computing them on demand would make compilation slower.
The commit also removes `Owner::hash_without_bodies`. There is no
benefit to pre-computing that one, it can just be done in the normal
fashion.
Account for binders correctly when adding default RPITIT method assumption
As of #108203, we install extra projection predicates into the param-env of a default trait method when it has return-position `impl Trait` (or is async).
The implementation didn't account for the fact that it's walking into and out of binders, so we just need to shift all the debruijn indices accordingly when constructing the projection predicates.
Fixes#108579
r? types
Make `rustc_query_system` take `QueryConfig` by instance.
This allows for easy switching between virtual tables and specialized instances for queries. It also has the benefit of less turbofish. `QueryStorage` has also been merged with `QueryCache`.
Split out from https://github.com/rust-lang/rust/pull/107937.
r? `@cjgillot`
feat: impl better help for `.poll()` not found on `impl Future`
Partially address #108572
I'd like to also address suggestions for generalized `Self` parameters as well. That'll be a separate PR.
Add `round_ties_even` to `f32` and `f64`
Tracking issue: #96710
Redux of #82273. See also #55107
Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this.
Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`). Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight.
Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
Remove `allow(potential_query_instability)` from `borrowck`
cc #84447
Replace uses of `FxHash*` with `FxIndex*`. One `#[allow]` for a HashMap in an external crate but the output is sorted afterwards.
fix multiple issues when promoting type-test subject
Multiple interdependent fixes. See linked issues for a short description of each.
When Promoting a type-test `T: 'a` from within the closure back to its parent function, there are a couple pre-existing bugs and limitations. They were exposed by the recent changes to opaque types because the type-test subject (`T`) is no longer a simple ParamTy.
Commit 1:
Fixes#108635Fixes#107426
Commit 2:
Fixes#108639
Commit 3:
Fixes#107516
Rollup of 8 pull requests
Successful merges:
- #107801 (const_eval: `implies_by` in `rustc_const_unstable`)
- #108750 (Fix `ObligationCtxt::sub`)
- #108780 (Add regression tests for issue 70919)
- #108786 (Check for free regions in MIR validation)
- #108790 (Do not ICE when interpreting a cast between non-monomorphic types)
- #108803 (Do not ICE when failing to normalize in ConstProp.)
- #108807 (Emit the suspicious_auto_trait_impls for negative impls as well)
- #108812 (Add regression test for #98444)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Do not ICE when failing to normalize in ConstProp.
There is no reason to delay a bug there, as we bubble up the failure as TooGeneric.
Fixes https://github.com/rust-lang/rust/issues/97728
Check for free regions in MIR validation
This turns https://github.com/rust-lang/rust/issues/108720 into a MIR validation failure that will reproduce without debug-assertions enabled.
```
error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:296 ~ futures_util[3805]::future::future::remote_handle::{impl#3}::poll), const_param_did: None }) (after pass ScalarReplacementOfAggregates) at bb0[0]:
Free regions in optimized runtime-post-cleanup MIR
--> /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.26/src/future/future/remote_handle.rs:96:13
|
96 | let this = self.project();
| ^^^^
```
const_eval: `implies_by` in `rustc_const_unstable`
Fixes#107605.
Extend support for `implies_by` (from `#[stable]` and `#[unstable]`) to `#[rustc_const_stable]` and `#[rustc_const_unstable]`.
cc ``@steffahn``
Allow using `bool` instead of `Option<()>` in diagnostics
~~Disallow the unit type for `#[help]`, `#[note]` etc, instead using `bool` to express optional annotations without a span which I believe is more intuitive.~~
~~Test output ordering has changed in a few places, where a field was of type `()` and the annotation has been moved to the struct itself. If any of these changes are an issue, this can be restricted to allowing specifically `()`, and not `Option<()>`~~
~~Actual changes here: https://github.com/rust-lang/rust/pull/108402/files#diff-815b1d8debfc564112bd51093791d7c3f2ee288a37a8f5c0e89c11d1f609b4c0~~
Allows using `bool` in derive diagnostics to indicate an optional subdiagnostic without a span, where previously `Option<()>` had to be used
`@rustbot` label +A-diagnostics
rustc_middle: Remove trait `DefIdTree`
This trait was a way to generalize over both `TyCtxt` and `Resolver`, but now `Resolver` has access to `TyCtxt`, so this trait is no longer necessary.
Desugaring of drop and replace at MIR build
This commit desugars the drop and replace deriving from an
assignment at MIR build, avoiding the construction of the
`DropAndReplace` terminator (which will be removed in a following PR).
In order to retain the same error messages for replaces a new
`DesugaringKind::Replace` variant is introduced.
The changes in the borrowck are also useful for future work in moving drop elaboration
before borrowck, as no `DropAndReplace` would be present there anymore.
Notes on test diffs:
* `tests/ui/borrowck/issue-58776-borrowck-scans-children`: the assignment deriving from the desugaring kills the borrow.
* `tests/ui/async-await/async-fn-size-uninit-locals.rs`, `tests/mir-opt/issue_41110.test.ElaborateDrops.after.mir`, `tests/mir-opt/issue_41888.main.ElaborateDrops.after.mir`: drop elaboration generates (or reads from) a useless drop flag due to an issue with the dataflow analysis. Will be fixed independently by https://github.com/rust-lang/rust/pull/106430.
See https://github.com/rust-lang/rust/pull/104488 for more context
Make compressed rmeta contain compressed data length after header
Fixes#90056, which is caused by link.exe introducing padding to the `.rustc` section, since it assumes this will have no effect besides allowing it to possibly use the extra space in future links.
Fuchsia is in the process of implementing the RISC-V support. This
change implements the minimal Rust compiler support. The support for
building runtime libraries will be implemented in follow up changes
once Fuchsia SDK has the RISC-V support.
Don't call `temporary_scope` twice.
`mirror_expr_inner` calls `temporary_scope`. It then calls `make_mirror_unadjusted` which makes an identical call to `temporary_scope`.
This commit changes the `mirror_expr_inner` to get the `temp_lifetime` out of the expression produced by `make_mirror_unadjusted`, similar to how it currently gets the type.
r? `@cjgillot`
rustc_expand: make proc-macro derive error translatable
kept this tiny so as to point to it as an example in rustc-dev-guide
`@rustbot` label +A-translation
Remove `NormalizationError::ConstantKind`
No longer in use by `TryNormalizeAfterErasingRegionsFolder` (as of #102355 / e8150fa60c it seems). It's making `LayoutError`, etc. kinda large -- that was noticed by `@zoxc.`
Use `Option::as_slice` where applicable
After #105871 introduced `Option::as_slice`, this PR uses it within the compiler. I found it interesting that all cases where `as_slice` could be used were done with different code before; so it seems the new API also has the benefit of being "the obvious solution" where before there was a mix of options, none clearly better than the rest.
Label opaque type for 'captures lifetime' error message
Providing more information may help make this somewhat opaque (lol) error message a bit clearer.
Fix another ICE in `point_at_expr_source_of_inferred_type`
Types coming from method probes must only be investigated *structurally*, since they often contain escaping infer variables from generalization and autoderef. We already have a hack in this PR that erases variables from types, so just use that.
Fixes#108664
The note attached to this error is pretty bad:
```
here the type of `primes` is inferred to be `[_]`
```
But that's unrelated to the PR.
---
Side-note: This is a pretty easy to trigger beta regression, so I've nominated it. Alternatively, I'm slightly inclined to remove this code altogether until it can be reformulated to be more accurate and less ICEy.
Remove legacy PM leftovers
This drops two leftovers of legacy PM usage:
* We don't need to initialize passes anymore.
* The pass listing was still using legacy PM passes. Replace it with the corresponding new PM listing.
Deny capturing late-bound non-lifetime param in anon const
Introduce a new AnonConstBoundary so we can detect when we capture a late-bound non-lifetime param with `non_lifetime_binders` enabled.
In the future, we could technically do something like introduce an early-bound parameter on the anon const, and stick the late-bound param in its substs (kinda like how we turn late-bound lifetimes in opaques into early-bound ones). But for now, just deny it so we don't ICE.
Fixes#108191
This commit desugars the drop and replace deriving from an
assignment at MIR build, avoiding the construction of the
DropAndReplace terminator (which will be removed in a followign PR)
In order to retain the same error messages for replaces a new
DesugaringKind::Replace variant is introduced.
`mirror_expr_inner` calls `temporary_scope`. It then calls
`make_mirror_unadjusted` which makes an identical call to
`temporary_scope`.
This commit changes the `mirror_expr_inner` to get the `temp_lifetime`
out of the expression produced by `make_mirror_unadjusted`, similar to
how it currently gets the type.
Feed queries on impl side for RPITITs when using lower_impl_trait_in_trait_to_assoc_ty
I've added a test for traits that were already working and what I think is probably the last bit of infrastructure work needed.
In following PRs I'm going to start adding things TDD style, tests and code that make it work.
r? `@compiler-errors`
Make `ExprKind` the first field in `thir::Expr`
This makes its `Debug` impl print it first which is useful, as it's the most important part when looking at an expr.
Explain compile-time vs run-time difference in env!() error message
This PR is clarifying error message of `env!()` based on this user question: https://users.rust-lang.org/t/environment-variable-out-dir-is-undefined/90067
It makes it clear that `env!()` is for env variables defined at compile-time. There's special-case help text for common Cargo build script variables.
I've also rearranged the code to avoid allocating error message on the happy path when the env var is defined.
Point error span at Some constructor argument when trait resolution fails
This is a follow up to #108254 and #106477 which extends error span refinement to handle a case which I mistakenly believed was handled in #106477. The goal is to refine the error span depicted below:
```rs
trait Fancy {}
impl <T> Fancy for Option<T> where T: Iterator {}
fn want_fancy<F>(f: F) where F: Fancy {}
fn example() {
want_fancy(Some(5));
// (BEFORE) ^^^^^^^ `{integer}` is not an iterator
// (AFTER) ^ `{integer}` is not an iterator
}
```
I had used a (slightly more complex) example as an illustrative example in #108254 , but hadn't actually turned it into a test, because I had (incorrectly) believed at the time it was covered by existing behavior. It turns out that `Some` is slightly "special" in that it resolves differently from the other `enum` constructors I had tried, and therefore this test was actually broken.
I've now updated the tests to include this example, and fixed the code to correctly resolve the `Some` constructor so that the span of the error is reduced.
Support allocations with non-Box<[u8]> bytes
This is prep work for allowing miri to support passing pointers to C code, which will require `Allocation`s to be correctly aligned. Currently, it just makes `Allocation` generic and plumbs the necessary changes through the right places.
The follow-up to this will be adding a type in the miri interpreter which correctly aligns the bytes, using that for the Miri engine, then allowing Miri to pass pointers into these allocations to C calls.
Based off of #100467, credit to ```@emarteca``` for the code
Revert stabilization of `#![feature(target_feature_11)]`
This reverts #99767 due to the presence of bugs #108645 and #108646.
cc `@joshtriplett`
cc tracking issue #69098
r? `@ghost`
Highlight whole expression for E0599
Fixes#108603
This adds a secondary label to highlight the whole expression leading to the error. It also prevents empty labels being recognised as 'unexpected' by compiletest - otherwise, tests with NOTE annotations would pick up empty labels.
`@rustbot` label +A-diagnostics
Restrict `#[rustc_box]` to `Box::new` calls
Currently, `#[rustc_box]` can be applied to any call expression with a single argument. This PR only allows it to be applied to calls to `Box::new`
Rollup of 7 pull requests
Successful merges:
- #108143 (rustdoc: search by macro when query ends with `!`)
- #108394 (Make `x doc --open` work on every book)
- #108427 (Recover from for-else and while-else)
- #108462 (Fix `VecDeque::append` capacity overflow for ZSTs)
- #108568 (Make associated_item_def_ids for traits use an unstable option to also return associated types for RPITITs)
- #108604 (Add regression test for #107280)
- #108605 (Add regression test for #105821)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Name LLVM anonymous constants by a hash of their contents
This makes the names stable between different versions of a crate unlike the `AllocId` naming, making LLVM IR comparisons with `llvm-diff` more practical.
Fix a race in the query system
This fixes an issue where in between the `job` removal and `complete` call the query neither has a job nor a result, allowing another thread to start executing it again.
r? ``@cjgillot``
Only look for param in item's generics if it actually comes from generics
Record whether a `hir::GenericParam` comes from an item's generics, or from a `for<...>` binder. Then, only look for the param in `object_lifetime_default` if it actually comes from the item's generics.
Fixes#108177
Stabilize `#![feature(target_feature_11)]`
## Stabilization report
### Summary
Allows for safe functions to be marked with `#[target_feature]` attributes.
Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits.
However, calling them from other `#[target_feature]` functions with a superset of features is safe.
```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}
fn foo() {
// Calling `avx2` here is unsafe, as we must ensure
// that AVX is available first.
unsafe {
avx2();
}
}
#[target_feature(enable = "avx2")]
fn bar() {
// Calling `avx2` here is safe.
avx2();
}
```
### Test cases
Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](b67ba9ba20/src/test/ui/rfcs/rfc-2396-target_feature-11/).
### Edge cases
- https://github.com/rust-lang/rust/issues/73631
Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.
```rust
#[target_feature(enable = "avx2")]
fn qux() {
let my_closure = || avx2(); // this call to `avx2` is safe
let f: fn() = my_closure;
}
```
This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives.
### Documentation
- Reference: https://github.com/rust-lang/reference/pull/1181
---
cc tracking issue #69098
r? `@ghost`
Avoid invoking typeck from borrowck
This PR attempts to reduce direct dependencies between typeck and MIR-related queries. The goal is to have all the information transit either through THIR or through dedicated queries that avoid depending on the whole `TypeckResults`.
In a first commit, we store the type information that MIR building requires into THIR. This avoids edges between mir_built and typeck.
In the second and third commit, we wrap informations around closures (upvars, kind origin and user-provided signature) to avoid borrowck depending on typeck information.
There should be a single remaining borrowck -> typeck edge in the good path, due to inline consts.
Rollup of 8 pull requests
Successful merges:
- #104265 (Move IpAddr, SocketAddr and V4+V6 related types to `core`)
- #107110 ([stdio][windows] Use MBTWC and WCTMB)
- #108308 (Allow building serde and serde_derive in parallel)
- #108363 (Move the unused extern crate check back to the resolver.)
- #108519 (Bages for easy access links to Rust community)
- #108522 (Commit some new solver tests)
- #108523 (Avoid `&str` to `String` conversions)
- #108533 (diagnostics: avoid querying `associated_item` in the resolver)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Move THIR printing to rustc_mir_build.
https://github.com/rust-lang/rust/pull/107451 increased the compilation time of `rustc_middle` by 10% = 3s.
As https://github.com/rust-lang/rust/pull/107006 adds quite a lot of code to rustc_middle, I suspect it to be the cause.
This PR moves the THIR printing code to `rustc_mir_build`, where the query provider lives, in order to benefit from higher parallelism when compiling rustc.
MIR-Validate StorageLive.
`StorageLive` statements on a local which already has storage is banned by miri.
This check is easy enough, and can detect bugs in MIR opts.
Unify validity checks into a single query
Previously, there were two queries to check whether a type allows the 0x01 or zeroed bitpattern.
I am planning on adding a further initness to check in #100423, truly uninit for MaybeUninit, which would make this three queries. This seems overkill for such a small feature, so this PR unifies them into one.
I am not entirely happy with the naming and key type and open for improvements.
r? oli-obk
Don't project specializable RPITIT projection
This effective rejects specialization + RPITIT/AFIT (usages of `impl Trait` in traits) because the implementation is significantly complicated over making regular "default" trait method bodies work.
I have another PR that experimentally fixes all this, but the code may not be worth investing in.
Emit the enum discriminant separately for the Encodable macro
This changes the `Encodable` proc macro to first emit the discriminant with a separate `match` statement, then emit the fields. LLVM can optimize down the first `match` to just a read of the enum discriminant. This avoids generating a `emit_usize` call per variant and enums with no fields now optimize down to just a single `emit_usize` call.
The no variant case is special cased to avoid warnings about unreachable code.
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.4676s</td><td align="right">0.4640s</td><td align="right"> -0.78%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1348s</td><td align="right">0.1338s</td><td align="right"> -0.75%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.3370s</td><td align="right">0.3352s</td><td align="right"> -0.54%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.6326s</td><td align="right">0.6281s</td><td align="right"> -0.71%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:unchanged</td><td align="right">1.8561s</td><td align="right">1.8589s</td><td align="right"> 0.15%</td></tr><tr><td>Total</td><td align="right">3.4282s</td><td align="right">3.4200s</td><td align="right"> -0.24%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9947s</td><td align="right"> -0.53%</td></tr></table>
Upgrade to ena-0.14.1.
It avoids some inlining within its `inlined_probe_value` function, which seems to result in better codegen for the very large `process_obligations` function within rustc. It might also help with reducing the bimodal perf results we see for the `keccak` and `cranelift-codegen-0.82.1` benchmarks.
r? `@ghost`
Remove `from` lang item
It was probably a leftover from the old `?` desugaring but anyways, it's unused now except for clippy, which can just use a diagnostics item.
statically guarantee that current error codes are documented
Closes#61137 (that's right!)
Pretty simple refactor (often just a change from `Result<Option<&str>>` to `Result<&str>`)
r? `@GuillaumeGomez` (could you specially look at 53044158eff0d64673a6100f701c57b484232aca? I believe you wrote that in the first place, just want to make sure you're happy with the change)
rustc_infer: Consolidate obligation elaboration de-duplication
# Explanation
The obligations `Elaborator` is doing de-duplication of obligations in 3 different locations. 1 off which has a comment.
This PR consolidates the functionality and comment to a single function.
Replace parse_[sth]_expr with parse_expr_[sth] function names
This resolves an inconsistency in naming style for functions on the parser, where:
* functions parsing specific kinds of items are named `parse_item_[sth]` and
* functions parsing specific kinds of *expressions* are named `parse_[sth]_expr`
favoring the style used by functions for items. There are multiple advantages of that style:
* functions of both categories are collected in the same place in the [rustdoc output](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_parse/parser/struct.Parser.html).
* it helps with autocompletion, as you can narrow down your search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things come first, then it gets more specific, i.e. `std::collections::hash_map::Entry`.
The disadvantage is that it doesn't "read like a sentence" any more. But I think the advantages weigh more greatly.
This change was mostly application of this command:
```
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
```
Plus very minor fixes outside of `rustc_parse`, and an invocation of `x fmt`.
Add `ErrorGuaranteed` to `hir::{Expr,Ty}Kind::Err` variants
First step in making the `Err` variants of `ExprKind` and `TyKind` require an `ErrorGuaranteed` during parsing. Making the corresponding AST versions require `ErrorGuaranteed` is a bit harder, whereas it was pretty easy to do this for HIR, so let's do that first.
The only weird thing about this PR is that `ErrorGuaranteed` is moved to `rustc_span`. This is *certainly* not the right place to put it, but `rustc_hir` cannot depend on `rustc_error` because the latter already depends on the former. Should I just pull out some of the error machinery from `rustc_error` into an even more minimal crate that `rustc_hir` can depend on? Advice would be appreciated.
Treat `str` as containing `[u8]` for auto trait purposes
Wanted to gauge ``@rust-lang/lang`` and ``@rust-lang/types`` teams' thoughts on treating `str` as "containing" a `[u8]` slice for auto-trait purposes.
``@dtolnay`` brought this up in https://github.com/rust-lang/rust/issues/13231#issuecomment-1399386472 as a blocker for future `str` type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that `str` type librarification (#107939), but this probably should be considered in the mean time regardless of that PR.
r? types for the impl, though this definitely needs an FCP.
Rollup of 8 pull requests
Successful merges:
- #107062 (Do some cleanup of doc/index.md)
- #107890 (Lint against `Iterator::map` receiving a callable that returns `()`)
- #108431 (Add regression test for #107918)
- #108432 (test: drop unused deps)
- #108436 (make "proc macro panicked" translatable)
- #108444 (docs/test: add UI test and docs for `E0476`)
- #108449 (Do not lint ineffective unstable trait impl for unresolved trait)
- #108456 (Complete migrating `ast_passes` to derive diagnostics)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
docs/test: add UI test and docs for `E0476`
Final undocumented error code. Not entirely sure about wording in the docs.
Part of https://github.com/rust-lang/rust/issues/61137.
r? ```@compiler-errors```
cc ```@compiler-errors```
Implement -Zlink-directives=yes/no
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives.
This is another way to address issue # #70093, which is currently addressed by `-Zlink-native-libraries` (implemented in #70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used.
Being able to control this on a crate-by-crate basis should make it much easier to apply when needed.
I'm not sure if we need both mechanisms, but we can decide that later.
cc `@pcwalton` `@cramertj`
[breaking change] Remove a rustdoc back compat warning
This warning was introduced in https://github.com/rust-lang/rust/pull/62855 for users who use `rustdoc` directly on proc macro crates (instead of using `cargo doc`) without passing `--crate-type proc-macro` (which `cargo doc` passed automatically).
Wrap missing provider message correctly
Fixes#108429
```
error: internal compiler error: compiler/rustc_middle/src/ty/query.rs:441:1: `tcx.trigger_delay_span_bug(DefId(0:3 ~ test[78c5]::main))` is not supported for local crate;
hint: Queries can be either made to the local crate, or the external crate. This error means you tried to use it for one that's not supported.
If that's not the case, trigger_delay_span_bug was likely never assigned to a provider function.
thread 'rustc' panicked at 'Box<dyn Any>', /home/ec2-user/rust3/compiler/rustc_errors/src/lib.rs:1651:9
stack backtrace:
0: 0x7f51870926d7 - std::backtrace_rs::backtrace::libunwind::trace::hb0876bb39e7adf0d
at /home/ec2-user/rust3/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
1: 0x7f51870926d7 - std::backtrace_rs::backtrace::trace_unsynchronized::h1bcab1313827007b
at /home/ec2-user/rust3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x7f5187077e07 - std::sys_common::backtrace::_print_fmt::h262d2a62279fa102
at /home/ec2-user/rust3/library/std/src/sys_common/backtrace.rs:65:5
```
Remove dead unwinds before drop elaboration
As a part of drop elaboration, we identify dead unwinds, i.e., unwind
edges on a drop terminators which are known to be unreachable, because
there is no need to drop anything.
Previously, the data flow framework was informed about the dead unwinds,
and it assumed those edges are absent from MIR. Unfortunately, the data
flow framework wasn't consistent in maintaining this assumption.
In particular, if a block was reachable only through a dead unwind edge,
its state was propagated to other blocks still. This became an issue in
the context of change removes DropAndReplace terminator, since it
introduces initialization into cleanup blocks.
To avoid this issue, remove unreachable unwind edges before the drop
elaboration, and elaborate only blocks that remain reachable.
cc `@Zeegomo`
diagnostics: remove inconsistent English article "this" from E0107
Consider [`tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`][issue-102768.stderr], the error message where it gives additional notes about where the associated type is defined, and how the dead code lint doesn't have an article, like in [`tests/ui/lint/dead-code/issue-85255.stderr`][issue-85255.stderr]. They don't have articles, so it seems unnecessary to have one here.
[issue-102768.stderr]: 07c993eba8/tests/ui/const-generics/generic_const_exprs/issue-102768.stderr
[issue-85255.stderr]: 07c993eba8/tests/ui/lint/dead-code/issue-85255.stderr
parser: provide better suggestions and errors on closures with braces missing
We currently provide wrong suggestions and unhelpful errors on closure bodies with braces missing.
For example, given the following code:
```rust
fn main() {
let _x = Box::new(|x|x+1;);
}
```
the current output is:
```
error: expected expression, found `)`
--> ./main.rs:2:30
|
2 | let _x = Box::new(|x|x+1;);
| ^ expected expression
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^
3 | }
| ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ this is the parsed closure...
3 | }
| - ...but likely you meant the closure to end here
help: try adding braces
|
2 ~ let _x = Box::new(|x| {x+1;);
3 ~ }}
|
error: expected `;`, found `}`
--> ./main.rs:2:32
|
2 | let _x = Box::new(|x|x+1;);
| ^ help: add `;` here
3 | }
| - unexpected token
error: aborting due to 3 previous errors
```
We got 3 errors, but all but the second are unnecessary or just wrong.
This commit allows outputting correct suggestions and errors. The above code would output like this:
```
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^ ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ - ...but likely you meant the closure to end here
| |
| this is the parsed closure...
help: try adding braces
|
2 | let _x = Box::new(|x| {x+1;});
| + +
error: aborting due to previous error
```
Fixes https://github.com/rust-lang/rust/issues/107959.
r? diagnostics
Fix ICE in 'duplicate diagnostic item' diagnostic
Not sure how to add this in a test; I found it by mistakenly running `cargo fix --lib -p std` rather than `x fix` at the root.
implement const iterator using `rustc_do_not_const_check`
Previous experiment: #102225.
Explanation: rather than making all default methods work under `const` all at once, this uses `rustc_do_not_const_check` as a workaround to "trick" the compiler to not run any checks on those other default methods. Any const implementations are only required to implement the `next` method. Any actual calls to the trait methods other than `next` will either error in compile time (at CTFE runs), or run the methods correctly if they do not have any non-const operations. This is extremely easy to maintain, remove, or improve.
This resolves an inconsistency in naming style for functions
on the parser, between functions parsing specific kinds of items
and those for expressions, favoring the parse_item_[sth] style
used by functions for items. There are multiple advantages
of that style:
* functions of both categories are collected in the same place
in the rustdoc output.
* it helps with autocompletion, as you can narrow down your
search for a function to those about expressions.
* it mirrors rust's path syntax where less specific things
come first, then it gets more specific, i.e.
std::collections::hash_map::Entry
The disadvantage is that it doesn't "read like a sentence"
any more, but I think the advantages weigh more greatly.
This change was mostly application of this command:
sed -i -E 's/(fn |\.)parse_([[:alnum:]_]+)_expr/\1parse_expr_\2/' compiler/rustc_parse/src/parser/*.rs
Plus very minor fixes outside of rustc_parse, and an invocation
of x fmt.
(This is a large commit. The changes to
`compiler/rustc_middle/src/ty/context.rs` are the most important ones.)
The current naming scheme is a mess, with a mix of `_intern_`, `intern_`
and `mk_` prefixes, with little consistency. In particular, in many
cases it's easy to use an iterator interner when a (preferable) slice
interner is available.
The guiding principles of the new naming system:
- No `_intern_` prefixes.
- The `intern_` prefix is for internal operations.
- The `mk_` prefix is for external operations.
- For cases where there is a slice interner and an iterator interner,
the former is `mk_foo` and the latter is `mk_foo_from_iter`.
Also, `slice_interners!` and `direct_interners!` can now be `pub` or
non-`pub`, which helps enforce the internal/external operations
division.
It's not perfect, but I think it's a clear improvement.
The following lists show everything that was renamed.
slice_interners
- const_list
- mk_const_list -> mk_const_list_from_iter
- intern_const_list -> mk_const_list
- substs
- mk_substs -> mk_substs_from_iter
- intern_substs -> mk_substs
- check_substs -> check_and_mk_substs (this is a weird one)
- canonical_var_infos
- intern_canonical_var_infos -> mk_canonical_var_infos
- poly_existential_predicates
- mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter
- intern_poly_existential_predicates -> mk_poly_existential_predicates
- _intern_poly_existential_predicates -> intern_poly_existential_predicates
- predicates
- mk_predicates -> mk_predicates_from_iter
- intern_predicates -> mk_predicates
- _intern_predicates -> intern_predicates
- projs
- intern_projs -> mk_projs
- place_elems
- mk_place_elems -> mk_place_elems_from_iter
- intern_place_elems -> mk_place_elems
- bound_variable_kinds
- mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter
- intern_bound_variable_kinds -> mk_bound_variable_kinds
direct_interners
- region
- intern_region (unchanged)
- const
- mk_const_internal -> intern_const
- const_allocation
- intern_const_alloc -> mk_const_alloc
- layout
- intern_layout -> mk_layout
- adt_def
- intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid)
- alloc_adt_def(!) -> mk_adt_def
- external_constraints
- intern_external_constraints -> mk_external_constraints
Other
- type_list
- mk_type_list -> mk_type_list_from_iter
- intern_type_list -> mk_type_list
- tup
- mk_tup -> mk_tup_from_iter
- intern_tup -> mk_tup
All the slice interners have a wrapper that handles the empty slice
case. We can instead handle this in the `slice_interners!` macro,
avoiding the need for most of the wrappers, and allowing the interner
functions to be renamed from `_intern_foos` to `intern_foos`.
The two exceptions:
- intern_predicates: I kept this wrapper because there's a FIXME
comment about a possible future change.
- intern_poly_existential_predicates: I kept this wrapper because it
asserts that the slice is empty and sorted.
Previously, there were two queries to check whether a type allows the
0x01 or zeroed bitpattern.
I am planning on adding a further initness to check, truly uninit for
MaybeUninit, which would make this three queries. This seems overkill
for such a small feature, so this PR unifies them into one.
Consider `tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`,
the error message where it gives additional notes about where the associated
type is defined, and how the dead code lint doesn't have an article,
like in `tests/ui/lint/dead-code/issue-85255.stderr`. They don't have
articles, so it seems unnecessary to have one here.
As a part of drop elaboration, we identify dead unwinds, i.e., unwind
edges on a drop terminators which are known to be unreachable, because
there is no need to drop anything.
Previously, the data flow framework was informed about the dead unwinds,
and it assumed those edges are absent from MIR. Unfortunately, the data
flow framework wasn't consistent in maintaining this assumption.
In particular, if a block was reachable only through a dead unwind edge,
its state was propagated to other blocks still. This became an issue in
the context of change removes DropAndReplace terminator, since it
introduces initialization into cleanup blocks.
To avoid this issue, remove unreachable unwind edges before the drop
elaboration, and elaborate only blocks that remain reachable.
We currently provide wrong suggestions and unhelpful errors on closure
bodies with braces missing. For example, given the following code:
```
fn main() {
let _x = Box::new(|x|x+1;);
}
```
the current output is like this:
```
error: expected expression, found `)`
--> ./main.rs:2:30
|
2 | let _x = Box::new(|x|x+1;);
| ^ expected expression
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^
3 | }
| ^
|
...
help: try adding braces
|
2 ~ let _x = Box::new(|x| {x+1;);
3 ~ }}
...
error: expected `;`, found `}`
--> ./main.rs:2:32
|
2 | let _x = Box::new(|x|x+1;);
| ^ help: add `;` here
3 | }
| - unexpected token
error: aborting due to 3 previous errors
```
This commit allows outputting correct suggestions and errors. The above
code would output like this:
```
error: closure bodies that contain statements must be surrounded by braces
--> ./main.rs:2:25
|
2 | let _x = Box::new(|x|x+1;);
| ^ ^
|
note: statement found outside of a block
--> ./main.rs:2:29
|
2 | let _x = Box::new(|x|x+1;);
| ---^ this `;` turns the preceding closure into a statement
| |
| this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
--> ./main.rs:2:23
|
2 | let _x = Box::new(|x|x+1;);
| ^^^^^^ - ...but likely you meant the closure to end here
| |
| this is the parsed closure...
help: try adding braces
|
2 | let _x = Box::new(|x| {x+1;});
| + +
error: aborting due to previous error
```
Use `tcx.ty_error_with_guaranteed` in more places, rename variants
1. Use `ty_error_with_guaranteed` more so we don't delay so many span bugs
2. Rename `ty_error_with_guaranteed` to `ty_error`, `ty_error` to `ty_error_misc`. This is to incentivize using the former over the latter in cases where we already are witness to a `ErrorGuaranteed` token.
Second commit is just name replacement, so the first commit can be reviewed on its own with more scrutiny.
Use associated type bounds in some places in the compiler
Use associated type bounds for some nested `impl Trait<Assoc = impl Trait2>` cases. I'm generally keen to introduce new lang features that are more mature into the compiler, but maybe let's see what others think?
Side-note: I was surprised that the only use-cases of nested impl trait in the compiler are just iterator related?!
Correctly handle aggregates in DataflowConstProp
The previous implementation from https://github.com/rust-lang/rust/pull/107411 flooded target of an aggregate assignment with `Bottom`, corresponding to the `deinit` that the interpreter does.
As a consequence, when assigning `target = Enum::Variant#i(...)` all the `(target as Variant#j)` were at `Bottom` while they should have been `Top`.
This PR replaces that flooding with `Top`.
Aside, it corrects a second bug where the wrong place would be used to assign to enum variant fields, resulting to nothing happening.
Fixes https://github.com/rust-lang/rust/issues/108166
Ban associated type bounds in bad positions
We should not try to lower associated type bounds into TAITs in positions where `impl Trait` is not allowed (except for in `where` clauses, like `where T: Trait<Assoc: Bound>`).
This is achieved by using the same `rustc_ast_lowering` machinery as impl-trait does to characterize positions as universal/existential/disallowed.
Fixes#106077
Split out the first commit into #108066, since it's not really related.
apply query response: actually define opaque types
not sure whether this fixes any code considering that #107891 doesn't break anything, but this is currently wrong as the `eq` there should just always fail right now.
We can definitely hit this code if we remove the `replace_opaque_types_with_inference_vars` hack. Doing so without this PR causes a few tests to ICE, e.g.
bd4a96a12d/tests/ui/impl-trait/issue-99642.rs (L1-L7)
r? `@oli-obk`
Lint dead code in closures and generators
Fixes#108296
I think this might be a potentially breaking change, but restores the behaviour of pre-1.64.
`@rustbot` label +A-lint
Don't delay `ReError` bug during lexical region resolve
Lexical region resolution returns a list of `RegionResolutionError` which don't necessarily correspond to diagnostics being emitted. The compiler may, validly, throw away these resolution errors and do something else. Therefore it's not valid to use `ReError` during lifetime resolution, since we may actually be on a totally fine compilation path.
For example, the `implied_bounds_entailment` lint runs region resolution twice, and only emits an error if it fails both times. If we delay a bug and create a `ReError` during this first run, then we will ICE.
Fixes#108170
----
Side-note: this is conceptually equivalent to how we can't necessarily delay bugs or create `ty::Error` during trait solving/fulfillment, since the compiler is allowed to throw away these fulfillment errors to do other things. It's only once we actually emit an error (`report_region_errors` / `report_fulfillment_errors`)
Remove type-traversal trait aliases
#107924 moved the type traversal (folding and visiting) traits into the type library, but created trait aliases in `rustc_middle` to minimise both the API churn for trait consumers and the arising boilerplate. As mentioned in that PR, an alternative approach of defining subtraits with blanket implementations of the respective supertraits was also considered at that time but was ruled out as not adding much value.
Unfortunately, it has since emerged that rust-analyzer has difficulty with these trait aliases at present, resulting in a degraded contributor experience (see the recent [r-a has become useless](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/r-a.20has.20become.20useless) topic on the #t-compiler/help Zulip stream).
This PR removes the trait aliases, and accordingly the underlying type library traits are now used directly; they are parameterised by `TyCtxt<'tcx>` rather than just the `'tcx` lifetime, and imports have been updated to reflect the fact that the trait aliases' explicitly named traits are no longer automatically brought into scope. These changes also roll-back the (no-longer required) workarounds to #107747 that were made in b409329c62.
Since this PR is just a find+replace together with the changes necessary for compilation & tidy to pass, it's currently just one mega-commit. Let me know if you'd like it broken up.
r? `@oli-obk`
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a
crate, so nothing is emitted into the crate's metadata. The assumption is
that the build system already knows about the crate's native dependencies
and can provide them at link time without these directives.
This is another way to address issue # #70093, which is currently addressed
by `-Zlink-native-libraries` (implemented in #70095). The latter is
implemented at link time, which has the effect of ignoring `#[link]`
in *every* crate. This makes it a very large hammer as it requires all
native dependencies to be known to the build system to be at all usable,
including those in sysroot libraries. I think this means its effectively
unused, and definitely under-used.
Being able to control this on a crate-by-crate basis should make it much
easier to apply when needed.
I'm not sure if we need both mechanisms, but we can decide that later.
errors: generate typed identifiers in each crate
Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter.
There are advantages and disadvantages to this change..
#### Advantages
- Changing a diagnostic now only recompiles the crate for that diagnostic and those crates that depend on it, rather than `rustc_error_messages` and all crates thereafter.
- This approach can be used to support first-party crates that want to supply translatable diagnostics (e.g. `rust-lang/thorin` in https://github.com/rust-lang/rust/pull/102612#discussion_r985372582, cc `@JhonnyBillM)`
- We can extend this a little so that tools built using rustc internals (like clippy or rustdoc) can add their own diagnostic resources (much more easily than those resources needing to be available to `rustc_error_messages`)
#### Disadvantages
- Crates can only refer to the diagnostic messages defined in the current crate (or those from dependencies), rather than all diagnostic messages.
- `rustc_driver` (or some other crate we create for this purpose) has to directly depend on *everything* that has error messages.
- It already transitively depended on all these crates.
#### Pending work
- [x] I don't know how to make `rustc_codegen_gcc`'s translated diagnostics work with this approach - because `rustc_driver` can't depend on that crate and so can't get its resources to provide to the diagnostic emission. I don't really know how the alternative codegen backends are actually wired up to the compiler at all.
- [x] Update `triagebot.toml` to track the moved FTL files.
r? `@compiler-errors`
cc #100717
Rollup of 8 pull requests
Successful merges:
- #108110 (Move some `InferCtxt` methods to `EvalCtxt` in new solver)
- #108168 (Fix ICE on type alias in recursion)
- #108230 (Convert a hard-warning about named static lifetimes into lint "unused_lifetimes")
- #108239 (Fix overlapping spans in removing extra arguments)
- #108246 (Add an InstCombine for redundant casts)
- #108264 (no-fail-fast support for tool testsuites)
- #108310 (rustdoc: Fix duplicated attributes for first reexport)
- #108318 (Remove unused FileDesc::get_cloexec)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix overlapping spans in removing extra arguments
Fixes#108225
Each span is already extended to include the previous comma, so extending to the *next* comma is unecessary and causes an ICE with assertions on.
``@rustbot`` label +A-diagnostics
Convert a hard-warning about named static lifetimes into lint "unused_lifetimes"
Fixes https://github.com/rust-lang/rust/issues/96956.
Some changes are ported from https://github.com/rust-lang/rust/pull/98079, thanks to jeremydavis519.
r? `@estebank` `@petrochenkov`
Any feedback is appreciated!
## Actions
- [x] resolve conflicts
- [x] fix build
- [x] address review comments in last pr
- [x] update tests
Move some `InferCtxt` methods to `EvalCtxt` in new solver
Moving towards eventually making the `InferCtxt` within `EvalCtxt` private, so that we make sure not to do anything strange in the solver. This doesn't finish this work yet, just gets it started.
r? ``@lcnr``
Extend `CodegenBackend` trait with a function returning the translation
resources from the codegen backend, which can be added to the complete
list of resources provided to the emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
`run-make/translation` had some targets that weren't listed in `all` and
thus weren't being tested - the behaviour that should have been being
tested was basically correct fortunately.
Signed-off-by: David Wood <david.wood@huawei.com>
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
Use a lock-free datastructure for source_span
follow up to the perf regression in https://github.com/rust-lang/rust/pull/105462
The main regression is likely the CStore, but let's evaluate the perf impact of this on its own
Define the `named_static_lifetimes` lint
This lint will replace the existing hard-warning.
Replace the named static lifetime hard-warning with the new lint
Update the UI tests for the `named_static_lifetimes` lint
Remove the direct dependency on `rustc_lint_defs`
fix build
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
use "UNUSED_LIFETIMES" instead
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
update 1 test and fix typo
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
update tests
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
fix tests: add extra blank line
Signed-off-by: Zhi Qi <qizhi@pingcap.com>
Use DefKind to give more item kind information during BindingObligation note
The current label says "required by a bound in this". When I see that label, my immediate impression is "this... **what**?". It feels like it was cut short.
Alternative to this would be saying "in this item", but adding the item kind is strictly more informational and adds very little overhead to the existing error presentation.
Better debug logs for borrowck constraint graph
It's really cumbersome to work with `RegionVar`s when trying to debug borrowck code or when trying to understand how the borrowchecker works. This PR collects some region information (behind `cfg(debug_assertions)`) for created `RegionVar`s (NLL region vars, this PR doesn't touch canonicalization) and prints the nodes and edges of the strongly connected constraints graph using representatives that use that region information (either lifetime names, locations in MIR or spans).
Linker: use -z <params> instead of -z<params>
The GNU linker accepts -z<params>, but this is undocumented, and not supported by other linkers.
In particular, `zig cc`, when used as the C compiler/linker (e.g. when using `cargo-zigbuild`), will not accept this undocumented syntax.
In `linker.rs`, both syntaxes are also used inconsistently.
The Go compiler used to have the same issue, but fixed it:
38607c5538
Make hidden type registration opt-in, so that each site can be reviewed on its own and we have the right defaults for trait solvers
r? `@lcnr`
pulled out of https://github.com/rust-lang/rust/pull/107891 as it is the uncontroversial part
The GNU linker accepts -z<params>, but this is undocumented, and
not supported by other linkers.
In particular, `zig cc`, when used as the C compiler/linker
(e.g. when using `cargo-zigbuild`), will not accept this
undocumented syntax.
In `linker.rs`, both syntaxes are also used inconsistently.
The Go compiler used to have the same issue, but fixed it:
38607c5538
Move `Fn*` traits malformedness protections to typeck
I found it strange that we were doing a custom well-formedness check just for the `Fn*` traits' `call_*` fn items. My understanding from the git history is that this is just to avoid ICEs later on in typeck.
Well, that well-formedness check isn't even implemented correctly for `FnOnce::call_once`, or `FnMut::call_mut` for that matter. Instead, this PR just makes the typeck checks more robust, and leaves it up to the call-site to report errors when lang items are implemented in funny ways.
This coincidentally fixes another ICE where a the `Add` lang item is implemented with a `add` item that's a const instead of a method.
Name placeholder in some region errors
Also don't print `ReVar` or `ReLateBound` as debug... these error messages are super uncommon anyways, but in the case they do trigger, let's be slightly more helpful.
remove unstable `pick_stable_methods_before_any_unstable` flag
This flag was only added in #90329 in case there was any issue with the impl so that it would be easy to tell nightly users to use the flag to disable the new logic to fix their code. It's now been enabled for two years and also I can't find any issues corresponding to this new functionality? This flag made it way harder to understand how this code works so it would be nice to remove it and simplify what's going on.
cc `@nbdd0121`
r? `@oli-obk`
Add rpitit queries
This is part of the changes we are making to lower RPITITs as an associated type. The rest of the stuff will follow under a `-Z` flag.
I still need to add comments to the code, explain stuff and also I'd need to avoid encoding in metadata when rpitit queries return `&[]`
r? `@compiler-errors`
lint: don't suggest MaybeUninit::assume_init for uninhabited types
Creating a zeroed uninhabited type such as `!` or an empty enum with `mem::zeroed()` (or transmuting `()` to `!`) currently triggers this lint:
```rs
warning: the type `!` does not permit zero-initialization
--> test.rs:5:23
|
5 | let _val: ! = mem::zeroed();
| ^^^^^^^^^^^^^
| |
| this code causes undefined behavior when executed
| help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
|
= note: the `!` type has no valid value
```
The `MaybeUninit` suggestion in the help message seems confusing/useless for uninhabited types, as such a type cannot be fully initialized in the first place (as the note implies).
This PR limits this help message to inhabited types which can be initialized
Miri: basic dyn* support
As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something.
TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all.
Strangely I did not need to do the equivalent of [this diff](https://github.com/rust-lang/rust/pull/106532#discussion_r1087095963) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized!
r? `@oli-obk` Cc `@eholk` (dyn-star) https://github.com/rust-lang/rust/issues/102425
