`try_fold_unevaluated` for infallible folders
#97447 added folding of unevaluated constants, but did not include an override of the default (fallible) operation in the blanket impl of `FallibleTypeFolder` for infallible folders. Here we provide that missing override.
r? ```@nnethercote```
Fix erroneous span for borrowck error
I am not confident that this is the correct fix, but it does the job. Open to suggestions for a real fix instead.
Fixes#97997
The issue is that we pass a [dummy location](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_middle/mir/visit.rs.html#302) when type-checking the ["required consts"](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Body.html#structfield.required_consts) that are needed by the MIR body during borrowck. This means that when we fail to evaluate the constant, we use the span of `bb0[0]`, instead of the actual span of the constant.
There are quite a few other places that use `START_BLOCK.start_location()`, `Location::START`, etc. when calling for a random/unspecified `Location` value. This is because, unlike (for example) `Span`, we don't have a dummy/miscellaneous value to use instead. I would appreciate guidance (either in this PR, or a follow-up) on what needs to be done to clean this up in general.
Add proper tracing spans to rustc_trait_selection::traits::error_reporting
While I was trying to figure out #97704 I did some of this to make the logs more legible, so I figured I'd do the whole module and open a PR with it. afaict this is an ongoing process in the compiler from the log->tracing transition? but lmk if there was a reason for the more verbose forms of logging as they are.
Also, for some of the functions with only one log in them, I put the function name as a message for that log instead of `#[instrument]`-ing the whole function with a span? but maybe the latter would actually be preferable, I'm not actually sure.
Remove dereferencing of Box from codegen
Through #94043, #94414, #94873, and #95328, I've been fixing issues caused by Box being treated like a pointer when it is not a pointer. However, these PRs just introduced special cases for Box. This PR removes those special cases and instead transforms a deref of Box into a deref of the pointer it contains.
Hopefully, this is the end of the Box<T, A> ICEs.
Mention formatting macros when encountering `ArgumentV1` method in const
Also open to just closing this if it's overkill. There are a lot of other distracting error messages around, so maybe it's not worth fixing just this one.
Fixes#93665
Don't omit comma when suggesting wildcard arm after macro expr
* Also adds `Span::eq_ctxt` to consolidate the various usages of `span.ctxt() == other.ctxt()`
* Also fixes an unhygenic usage of spans which caused the suggestion to render weirdly when we had one arm match in a macro
* Also always suggests a comma (i.e. even after a block) if we're rendering a wildcard arm in a single-line match (looks prettier 🌹)
Fixes#94866
Drop magic value 3 from code
Magic value 3 is used to create state for a yield point. It is in fact
the number of reserved variants.
Lift RESERVED_VARIANTS out to module scope and use it instead.
#97447 added folding of unevaluated constants, but did not include an override of the default (fallible) operation in the blanket impl of `FallibleTypeFolder` for infallible folders. Here we provide that missing override.
r? @nnethercote
Include ForeignItem when visiting types for WF check
Addresses Issue 95665 by including `hir::Node::ForeignItem` as a valid
type to visit in `diagnostic_hir_wf_check`.
Fixes#95665
Magic value 3 is used to create state for a yield point. It is in fact
the number of reserved variants.
Lift RESERVED_VARIANTS out to module scope and use it instead.
Fix pretty printing of empty bound lists in where-clause
Repro:
```rust
macro_rules! assert_item_stringify {
($item:item $expected:literal) => {
assert_eq!(stringify!($item), $expected);
};
}
fn main() {
assert_item_stringify! {
fn f<'a, T>() where 'a:, T: {}
"fn f<'a, T>() where 'a:, T: {}"
}
}
```
Previously this assertion would fail because rustc renders the where-clause as `where 'a, T` which is invalid syntax.
This PR makes the above assertion pass.
This bug also affects `-Zunpretty=expanded`. The intention is for that to emit syntactically valid code, but the buggy output is not valid Rust syntax.
```console
$ rustc <(echo "fn f<'a, T>() where 'a:, T: {}") -Zunpretty=expanded
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
fn f<'a, T>() where 'a, T {}
```
```console
$ rustc <(echo "fn f<'a, T>() where 'a:, T: {}") -Zunpretty=expanded | rustc -
error: expected `:`, found `,`
--> <anon>:7:23
|
7 | fn f<'a, T>() where 'a, T {}
| ^ expected `:`
```
Make missing argument placeholder more obvious that it's a placeholder
Use `/* ty */` instead of `{ty}`, since people might be misled into thinking that this is valid syntax, and not just a diagnostic placeholder.
Fixes#96880
Both functions do some modifying of streams using `make_mut`:
- `push` sometimes glues the first token of the next stream to the last
token of the first stream.
- `build` appends tokens to the first stream.
By doing all of this in the one place, things are simpler. The first
stream can be modified in both ways (if necessary) in the one place, and
any next stream with the first token removed doesn't need to be stored.
Fix `SourceScope` for `if let` bindings.
Fixes#97799.
I'm not sure how to test this properly, is there any way to observe the difference in behavior apart from `ui` tests? I'm worried that they would be overlooked in the case of a regression.
It's a weird function: it lets you modify the token stream in the middle
of iteration. There is only one call site, and it is only used for the
rare `ProceduralMasquerade` legacy case.
Make debug_triple depend on target json file content rather than file path
This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.
This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``
Stabilize `Path::try_exists()` and improve doc
This stabilizes the `Path::try_exists()` method which returns
`Result<bool, io::Error>` instead of `bool` allowing handling of errors
unrelated to the file not existing. (e.g permission errors)
Along with the stabilization it also:
* Warns that the `exists()` method is error-prone and suggests to use
the newly stabilized one.
* Suggests it instead of `metadata()` to handle errors.
* Mentions TOCTOU bugs to avoid false assumption that `try_exists()` is
completely safe fixed version of `exists()`.
* Renames the feature of still-unstable `std::fs::try_exists()` to
`fs_try_exists` to avoid name conflict.
The tracking issue #83186 remains open to track `fs_try_exists`.
Most futures don't go through this code path, because they're caught by
`maybe_note_obligation_cause_for_async_await`. But all generators do,
and `maybe_note` is imperfect and doesn't catch all futures. Improve the error message for those it misses.
At some point, we may want to consider unifying this with the code for `maybe_note_async_await`,
so that `async_await` notes all parent constraints, and `note_obligation` can point to yield points.
But both functions are quite complicated, and it's not clear to me how to combine them;
this seems like a good incremental improvement.
Rollup of 5 pull requests
Successful merges:
- #98105 (rustdoc: remove tuple link on round braces)
- #98136 (Rename `impl_constness` to `constness`)
- #98146 (Remove --memory-init-file flag when linking with Emscripten)
- #98219 (Skip late bound regions in GATSubstCollector)
- #98233 (Remove accidental uses of `&A: Allocator`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Skip late bound regions in GATSubstCollector
#93227 liberated late bound regions when collecting GAT substs in wfcheck. It should simply skip late bound regions instead.
r? ``@compiler-errors``
Rename `impl_constness` to `constness`
The current code is a basis for `is_const_fn_raw`, and `impl_constness`
is no longer a valid name, which is previously used for determining the
constness of impls, and not items in general.
r? `@oli-obk`
add comments in `store_dead_field_or_variant`
support multiple log level
add a item ident label
fix ui tests
fix a ui test
fix a rustdoc ui test
use let chain
refactor: remove `store_dead_field_or_variant`
fix a tiny bug
once cell renamings
This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128
- Move/rename `lazy::{OnceCell, Lazy}` to `cell::{OnceCell, LazyCell}`
- Move/rename `lazy::{SyncOnceCell, SyncLazy}` to `sync::{OnceLock, LazyLock}`
(I used `Lazy...` instead of `...Lazy` as it seems to be more consistent, easier to pronounce, etc)
```@rustbot``` label +T-libs-api -T-libs
Batch proc_macro RPC for TokenStream iteration and combination operations
This is the first part of #86822, split off as requested in https://github.com/rust-lang/rust/pull/86822#pullrequestreview-1008655452. It reduces the number of RPC calls required for common operations such as iterating over and concatenating TokenStreams.
Rollup of 5 pull requests
Successful merges:
- #97803 (Impl Termination for Infallible and then make the Result impls of Termination more generic)
- #97828 (Allow configuring where artifacts are downloaded from)
- #98150 (Emscripten target: replace -g4 with -g, and -g3 with --profiling-funcs)
- #98195 (Fix rustdoc json primitive handling)
- #98205 (Remove a possible unnecessary assignment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove a possible unnecessary assignment
The reference issue has been closed (the feature has been stabilized)
and things work fine without it, it seems.
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
Emscripten target: replace -g4 with -g, and -g3 with --profiling-funcs
Emscripten prints the following warning:
```
emcc: warning: please replace -g4 with -gsource-map [-Wdeprecated]
```
`@sbc100`
The reference issue has been closed (the feature has been stabilized)
and things work fine without fine, it seems.
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
ctfe: limit hashing of big const allocations when interning
Const allocations are only hashed for interning. However, they can be large, making the hashing expensive especially since it uses `FxHash`: it's better suited to short keys, not potentially big buffers like the actual bytes of allocation and the associated 1/8th sized `InitMask`.
We can partially hash these fields when they're large, hashing the length, and head and tail of these buffers, to
limit possible collisions while avoiding most of the hashing work.
r? `@ghost`
Rollup of 5 pull requests
Successful merges:
- #95392 (std: Stabilize feature try_reserve_2 )
- #97798 (Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown)
- #97844 (Windows: No panic if function not (yet) available)
- #98013 (Subtype FRU fields first in `type_changing_struct_update`)
- #98191 (Remove the rest of unnecessary `to_string`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Subtype FRU fields first in `type_changing_struct_update`
So this fixes a subtle bug that `type_changing_struct_update` introduced, where it'll no longer coerce the base expr correctly. I actually think this code is easier to understand now, too.
r? `@lcnr` since you reviewed the last one
Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown
This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed "the problem" (of not showing some parts of the suggestion) here: https://github.com/rust-lang/rust/pull/97759#discussion_r889689230.
I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so), but I want to at least discuss the result.
Here is an example of how this changes the output:
Before:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```
After:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
|
```
r? `@estebank`
`@rustbot` label +A-diagnostics +A-suggestion-diagnostics
`BitSet` related perf improvements
This commit makes two changes:
1. Changes `MaybeLiveLocals` to use `ChunkedBitSet`
2. Overrides the `fold` method for the iterator for `ChunkedBitSet`
I have local benchmarks verifying that each of these changes individually yield significant perf improvements to #96451 . I'm hoping this will be true outside of that context too. If that is not the case, I'll try to gate things on where they help as needed
r? `@nnethercote` who I believe was working on closely related things, cc `@tmiasko` because of the destprop pr
Move `finish` out of the `Encoder` trait.
This simplifies things, but requires making `CacheEncoder` non-generic.
(This was previously merged as commit 4 in #94732 and then was reverted
in #97905 because it caused a perf regression.)
r? `@ghost`
This is an experimental patch to try to reduce the codegen complexity of
TokenStream's FromIterator and Extend implementations for downstream
crates, by moving the core logic into a helper type. This might help
improve build performance of crates which depend on proc_macro as
iterators are used less, and the compiler may take less time to do
things like attempt specializations or other iterator optimizations.
The change intentionally sacrifices some optimization opportunities,
such as using the specializations for collecting iterators derived from
Vec::into_iter() into Vec.
This is one of the simpler potential approaches to reducing the amount
of code generated in crates depending on proc_macro, so it seems worth
trying before other more-involved changes.
This significantly reduces the cost of common interactions with TokenStream
when running with the CrossThread execution strategy, by reducing the number of
RPC calls required.
Rollup of 5 pull requests
Successful merges:
- #97377 (Do not suggest adding semicolon/changing delimiters for macros in item position that originates in macros)
- #97675 (Make `std::mem::needs_drop` accept `?Sized`)
- #98118 (Test NLL fix of bad lifetime inference for reference captured in closure.)
- #98166 (Add rustdoc-json regression test for #98009)
- #98169 (Keyword docs: Link to wikipedia article for dynamic dispatch)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Make `std::mem::needs_drop` accept `?Sized`
This change attempts to make `needs_drop` work with types like `[u8]` and `str`.
This enables code in types like `Arc<T>` that was not possible before, such as https://github.com/rust-lang/rust/pull/97676.
Compile `unicode-normalization` faster
Various optimizations and cleanups aimed at improving compilation of `unicode-normalization`, which is notable for having several very large `match`es with many char ranges.
Best reviewed one commit at a time.
r? `@oli-obk`
Big const allocations hash a large amount of data for interning:
the whole bytes buffer, and the 1/8th sized initmask, with FxHash.
This hash function is made for shorter keys.
This only hashes the length, and head and tail of these buffers, to
limit possible collisions while avoiding most of the hashing work.
Previously we only show at most 6 lines of suggestions and, if the
suggestions are more than 6 lines apart, we've just showed ... at the
end. This is probably fine, but quite confusing in my opinion.
This commit is an attempt to show ... in places where there is nothing
to suggest instead, for example:
Before:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```
After:
```text
help: consider enclosing expression in a block
|
3 ~ 'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
|
```
Support lint expectations for `--force-warn` lints (RFC 2383)
Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.
This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.
This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.
---
r? `@wesleywiser`
cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃
Follow-up of: https://github.com/rust-lang/rust/pull/87835
Issue: https://github.com/rust-lang/rust/issues/85549
Yeah, and that's it.
This simplifies things, but requires making `CacheEncoder` non-generic.
(This was previously merged as commit 4 in #94732 and then was reverted
in #97905 because it caused a perf regression.)
This commit removes the `a == b` early return, which isn't useful in
practice, and replaces it with one that helps matches with many ranges,
including char ranges.
The code is clearer and simpler without it. Note that the `a == b` early
return at the top of the function means the `a == b` test at the end of
the function could never succeed.
It's never executed when running the entire test suite. I think it's
because of the early return at the top of the function if `a.ty() != ty`
succeeds.
This is a performance win for `unicode-normalization`.
The commit also removes the closure, which isn't necessary. And
reformulates the comparison into a form I find easier to read.
The `MissingDoc` lint has quadratic behaviour when processing doc comments.
This is a problem for large doc comments (e.g. 1000+ lines) when
`deny(missing_code)` is enabled.
A 1000-line doc comment using `//!` comments is represented as 1000 attributes
on an item. The lint machinery iterates over each attribute with
`visit_attribute`. `MissingDoc`'s impl of that function calls
`with_lint_attrs`, which calls `enter_attrs`, which iterates over all 1000
attributes looking for a `doc(hidden)` attribute. I.e. for every attribute we
iterate over all the other attributes.
The fix is simple: don't call `with_lint_attrs` on attributes. This makes
sense: `with_lint_attrs` is intended to iterate over the attributes on a
language fragment like a statement or expression, but it doesn't need to
be called on attributes themselves.
Refactor path segment parameter error
This PR attempts to rewrite the error handling for an unexpected parenthesised type parameters to:
- Use provided data instead of re-parsing the whole span
- Add a multipart suggestion to reflect on the changes with an underline
- Remove the unnecessary "if" nesting
Fix suggestions for `&a: T` parameters
I've accidentally discovered that we have broken suggestions for `&a: T` parameters:
```rust
fn f(&mut bar: u32) {}
fn main() {
let _ = |&mut a| ();
}
```
```text
error[E0308]: mismatched types
--> ./t.rs:1:6
|
1 | fn f(&mut bar: u32) {}
| ^^^^^^^^-----
| | |
| | expected due to this
| expected `u32`, found `&mut _`
| help: did you mean `bar`: `&u32`
|
= note: expected type `u32`
found mutable reference `&mut _`
error[E0308]: mismatched types
--> ./t.rs:4:23
|
4 | let _: fn(u32) = |&mut a| ();
| ^^^^^--
| | |
| | expected due to this
| expected `u32`, found `&mut _`
| help: did you mean `a`: `&u32`
|
= note: expected type `u32`
found mutable reference `&mut _`
```
It's hard to see, but
1. The help span is overlapping with "expected" spans
2. It suggests `fn f( &u32) {}` (no `mut` and lost parameter name) and `|&u32 ()` (no closing `|` and lost parameter name)
I've tried to fix this.
r? ``@compiler-errors``
[RFC 2011] Minimal initial implementation
Tracking issue: #44838
Third step of #96496
Implementation has ~290 LOC with the bare minimum to be in a functional state. Currently only searches for binary operations to mimic what `assert_eq!` and `assert_ne!` already do.
r? `@oli-obk`
The code now accepts `Binder<OutlivesPredicate>`
instead of just `OutlivesPredicate` and thus exercises
the new, generalized `IfEqBound` codepaths. Note though
that we never *produce* Binder<OutlivesPredicate>, so we
are only testing a subset of those codepaths that excludes
actual higher-ranked outlives bounds.
STD support for the Nintendo 3DS
Rustc already supports compiling for the Nintendo 3DS using the `armv6k-nintendo-3ds` target (Tier 3). Until now though, only `core` and `alloc` were supported. This PR adds standard library support for the Nintendo 3DS. A notable exclusion is `std::thread` support, which will come in a follow-up PR as it requires more complicated changes.
This has been a joint effort by `@Meziu,` `@ian-h-chamberlain,` myself, and prior work by `@rust3ds` members.
### Background
The Nintendo 3DS (Horizon OS) is a mostly-UNIX looking system, with the caveat that it does not come with a full libc implementation out of the box. On the homebrew side (I'm not under NDA), the libc interface is partially implemented by the [devkitPro](https://devkitpro.org/wiki/devkitPro_pacman) toolchain and a user library like [`libctru`](https://github.com/devkitPro/libctru). This is important because there are [some possible legal barriers](https://github.com/rust-lang/rust/pull/88529#issuecomment-919938396) to linking directly to a library that uses the underlying platform APIs, since they might be considered a trade secret or under NDA.
To get around this, the standard library impl for the 3DS does not directly depend on any platform-level APIs. Instead, it expects standard libc functions to be linked in. The implementation of these libc functions is left to the user. Some functions are provided by the devkitPro toolchain, but in our testing, we used the following to fill in the other functions:
- [`libctru`] - provides more basic APIs, such as `nanosleep`. Linked in by way of [`ctru-sys`](https://github.com/Meziu/ctru-rs/tree/master/ctru-sys).
- [`pthread-3ds`](https://github.com/Meziu/pthread-3ds) - provides pthread APIs for `std::thread`. Implemented using [`libctru`].
- [`linker-fix-3ds`](https://github.com/Meziu/rust-linker-fix-3ds) - fulfills some other missing libc APIs. Implemented using [`libctru`].
For more details, see the `src/doc/rustc/src/platform-support/armv6k-nintendo-3ds.md` file added in this PR.
### Notes
We've already upstreamed changes to the [`libc`] crate to support this PR, as well as the upcoming threading PR. These changes have all been released as of 0.2.121, so we bump the crate version in this PR.
Edit: After some rebases, the version bump has already been merged so it doesn't appear in this PR.
A lot of the changes in this PR are straightforward, and follow in the footsteps of the ESP-IDF target: https://github.com/rust-lang/rust/pull/87666.
The 3DS does not support user space process spawning, so these APIs are unimplemented (similar to ESP-IDF).
[`libctru`]: https://github.com/devkitPro/libctru
[`libc`]: https://github.com/rust-lang/libc
The current code is a basis for `is_const_fn_raw`, and `impl_constness`
is no longer a valid name, which is previously used for determining the
constness of impls, and not items in general.
Remove `rustc_deprecated` diagnostics
Follow-up on #95960. The diagnostics will remain until the next bootstrap, at which point people will have had six weeks to adjust.
``@rustbot`` label +A-diagnostics
r? ``@compiler-errors``
Make `ExprKind::Closure` a struct variant.
Simple refactor since we both need it to introduce additional fields in `ExprKind::Closure`.
r? ``@Aaron1011``
Remove thread-local `IGNORED_ATTRIBUTES`.
It's just a copy of the read-only global `ich::IGNORED_ATTRIBUTES`, and
can be removed without any effect.
r? `@michaelwoerister`
Rollup of 7 pull requests
Successful merges:
- #97822 (Filter out intrinsics if we have other import candidates to suggest)
- #98026 (Move some tests to more reasonable directories)
- #98067 (compiler: remove unused deps)
- #98078 (Use unchecked mul to compute slice sizes)
- #98083 (Rename rustc_serialize::opaque::Encoder as MemEncoder.)
- #98087 (Suggest adding a `#[macro_export]` to a private macro)
- #98113 (Fix misspelling of "constraint" as "contraint")
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Rename rustc_serialize::opaque::Encoder as MemEncoder.
This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).
(This was previously merged as commit 5 in #94732 and then was reverted
in #97905 because of a perf regression caused by commit 4 in #94732.)
r? ```@bjorn3```
Use unchecked mul to compute slice sizes
This allows LLVM to realize that `slice.len() > 0` iff `slice.len() * size_of::<T>() > 0`, allowing a branch on the latter to be folded into the former when dropping vecs and boxed slices, in some cases.
Fixes (partially) #96497
Filter out intrinsics if we have other import candidates to suggest
Fixes#97618
Also open to just sorting these candidates to be last. Pretty easy to modify the code to do that, too.
Improve parsing errors and suggestions for bad `if` statements
1. Parses `if {}` as `if <err> {}` (block-like conditions that are missing a "then" block), and `if true && {}` as `if true && <err> {}` (unfinished binary operation), which is a more faithful recovery and leads to better typeck errors later on.
1. Points out the span of the condition if we don't see a "then" block after it, to help the user understand what is being parsed as a condition (and by elimination, what isn't).
1. Allow `if cond token else { }` to be fixed properly to `if cond { token } else { }`.
1. Fudge with the error messages a bit. This is somewhat arbitrary and I can revert my rewordings if they're useless.
----
Also this PR addresses a strange parsing regression (1.20 -> 1.21) where we chose to reject this piece of code somewhat arbitrarily, even though we should parse it fine:
```rust
fn main() {
if { if true { return } else { return }; } {}
}
```
For context, all of these other expressions parse correctly:
```rust
fn main() {
if { if true { return } else { return } } {}
if { return; } {}
if { return } {}
if { return if true { } else { }; } {}
}
```
The parser used a heuristic to determine if the "the parsed `if` condition makes sense as a condition" that did like a one-expr-deep reachability analysis. This should not be handled by the parser though.
Use valtrees as the type-system representation for constant values
This is not quite ready yet, there are still some problems with pretty printing and symbol mangling and `deref_const` seems to not work correctly in all cases.
Mainly opening now for a perf-run (which should be good to go, despite the still existing problems).
r? `@oli-obk`
cc `@lcnr` `@RalfJung`
This stabilizes the `Path::try_exists()` method which returns
`Result<bool, io::Error>` instead of `bool` allowing handling of errors
unrelated to the file not existing. (e.g permission errors)
Along with the stabilization it also:
* Warns that the `exists()` method is error-prone and suggests to use
the newly stabilized one.
* Suggests it instead of `metadata()` to handle errors.
* Mentions TOCTOU bugs to avoid false assumption that `try_exists()` is
completely safe fixed version of `exists()`.
* Renames the feature of still-unstable `std::fs::try_exists()` to
`fs_try_exists` to avoid name conflict.
The tracking issue #83186 remains open to track `fs_try_exists`.
Integrate measureme's hardware performance counter support.
*Note: this is a companion to https://github.com/rust-lang/measureme/pull/143, and duplicates some information with it for convenience*
**(much later) EDIT**: take any numbers with a grain of salt, they may have changed since initial PR open.
## Credits
I'd like to start by thanking `@alyssais,` `@cuviper,` `@edef1c,` `@glandium,` `@jix,` `@Mark-Simulacrum,` `@m-ou-se,` `@mystor,` `@nagisa,` `@puckipedia,` and `@yorickvP,` for all of their help with testing, and valuable insight and suggestions.
Getting here wouldn't have been possible without you!
(If I've forgotten anyone please let me know, I'm going off memory here, plus some discussion logs)
## Summary
This PR adds support to `-Z self-profile` for counting hardware events such as "instructions retired" (as opposed to being limited to time measurements), using the `rdpmc` instruction on `x86_64` Linux.
While other OSes may eventually be supported, preliminary research suggests some kind of kernel extension/driver is required to enable this, whereas on Linux any user can profile (at least) their own threads.
Supporting Linux on architectures other than x86_64 should be much easier (provided the hardware supports such performance counters), and was mostly not done due to a lack of readily available test hardware.
That said, 32-bit `x86` (aka `i686`) would be almost trivial to add and test once we land the initial `x86_64` version (as all the CPU detection code can be reused).
A new flag `-Z self-profile-counter` was added, to control which of the named `measureme` counters is used, and which defaults to `wall-time`, in order to keep `-Z self-profile`'s current functionality unchanged (at least for now).
The named counters so far are:
* `wall-time`: the existing time measurement
* name chosen for consistency with `perf.rust-lang.org`
* continues to use `std::time::Instant` for a nanosecond-precision "monotonic clock"
* `instructions:u`: the hardware performance counter usually referred to as "Instructions retired"
* here "retired" (roughly) means "fully executed"
* the `:u` suffix is from the Linux `perf` tool and indicates the counter only runs while userspace code is executing, and therefore counts no kernel instructions
* *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this isn't entirely true and why `instructions-minus-irqs:u` should be preferred instead*
* `instructions-minus-irqs:u`: same as `instructions:u`, except the count of hardware interrupts ("IRQs" here for brevity) is subtracted
* *see [Caveats/Subtracting IRQs](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs) for why this should be preferred over `instructions:u`*
* `instructions-minus-r0420:u`: experimental counter, same as `instructions-minus-irqs:u` but subtracting an undocumented counter (`r0420:u`) instead of IRQs
* the `rXXXX` notation is again from Linux `perf`, and indicates a "raw" counter, with a hex representation of the low-level counter configuration - this was picked because we still don't *really* know what it is
* this only exists for (future) testing and isn't included/used in any comparisons/data we've put together so far
* *see [Challenges/Zen's undocumented 420 counter](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter) for details on how this counter was found and what it does*
---
There are also some additional commits:
* ~~see [Challenges/Rebasing *shouldn't* affect the results, right?](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results,-right) for details on the changes to `rustc_parse` and `rustc_trait_section` (the latter far more dubious, and probably shouldn't be merged, or not as-is)~~
* **EDIT**: the effects of these are no long quantifiable, the PR includes reverts for them
* ~~see [Challenges/`jemalloc`: purging will commence in ten seconds](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds) for details on the `jemalloc` change~~
* this is also separately found in #77162, and we probably want to avoid doing it by default, ideally we'd use the runtime control API `jemalloc` offers (assuming that can stop the timer that's already running, which I'm not sure about)
* **EDIT**: until we can do this based on `-Z` flags, this commit has also been reverted
* the `proc_macro` change was to avoid randomized hashing and therefore ASLR-like effects
---
**(much later) EDIT**: take any numbers with a grain of salt, they may have changed since initial PR open.
#### Write-up / report
Because of how extensive the full report ended up being, I've kept most of it [on `hackmd.io`](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view), but for convenient access, here are all the sections (with individual links):
<sup>(someone suggested I'd make a backup, so [here it is on the wayback machine](http://web.archive.org/web/20201127164748/https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view) - I'll need to remember to update that if I have to edit the write-up)</sup>
* [**Motivation**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Motivation)
* [**Results**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Results)
* [**Overhead**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Overhead)
*Preview (see the report itself for more details):*
|Counter|Total<br>`instructions-minus-irqs:u`|Overhead from "Baseline"<br>(for all 1903881<br>counter reads)|Overhead from "Baseline"<br>(per each counter read)|
|-|-|-|-|
|Baseline|63637621286 ±6||
|`instructions:u`|63658815885 ±2| +21194599 ±8| +11|
|`instructions-minus-irqs:u`|63680307361 ±13| +42686075 ±19| +22|
|`wall-time`|63951958376 ±10275|+314337090 ±10281|+165|
* [**"Macro" noise (self time)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Macro”-noise-(self-time))
*Preview (see the report itself for more details):*
|| `wall-time` (ns) | `instructions:u` | `instructions-minus-irqs:u`
-: | -: | -: | -:
`typeck` | 5478261360 ±283933373 (±~5.2%) | 17350144522 ±6392 (±~0.00004%) | 17351035832.5 ±4.5 (±~0.00000003%)
`expand_crate` | 2342096719 ±110465856 (±~4.7%) | 8263777916 ±2937 (±~0.00004%) | 8263708389 ±0 (±~0%)
`mir_borrowck` | 2216149671 ±119458444 (±~5.4%) | 8340920100 ±2794 (±~0.00003%) | 8341613983.5 ±2.5 (±~0.00000003%)
`mir_built` | 1269059734 ±91514604 (±~7.2%) | 4454959122 ±1618 (±~0.00004%) | 4455303811 ±1 (±~0.00000002%)
`resolve_crate` | 942154987.5 ±53068423.5 (±~5.6%) | 3951197709 ±39 (±~0.000001%) | 3951196865 ±0 (±~0%)
* [**"Micro" noise (individual sampling intervals)**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#“Micro”-noise-(individual-sampling-intervals))
* [**Caveats**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Caveats)
* [**Disabling ASLR**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Disabling-ASLR)
* [**Non-deterministic proc macros**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Non-deterministic-proc-macros)
* [**Subtracting IRQs**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Subtracting-IRQs)
* [**Lack of support for multiple threads**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Lack-of-support-for-multiple-threads)
* [**Challenges**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Challenges)
* [**How do we even read hardware performance counters?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#How-do-we-even-read-hardware-performance-counters)
* [**ASLR: it's free entropy**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#ASLR-it’s-free-entropy)
* [**The serializing instruction**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#The-serializing-instruction)
* [**Getting constantly interrupted**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Getting-constantly-interrupted)
* [**AMD patented time-travel and dubbed it `SpecLockMap`<br><sup> or: "how we accidentally unlocked `rr` on AMD Zen"</sup>**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#AMD-patented-time-travel-and-dubbed-it-SpecLockMapnbspnbspnbspnbspnbspnbspnbspnbspor-“how-we-accidentally-unlocked-rr-on-AMD-Zen”)
* [**`jemalloc`: purging will commence in ten seconds**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#jemalloc-purging-will-commence-in-ten-seconds)
* [**Rebasing *shouldn't* affect the results, right?**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Rebasing-*shouldn’t*-affect-the-results,-right)
* [**Epilogue: Zen's undocumented 420 counter**](https://hackmd.io/sH315lO2RuicY-SEt7ynGA?view#Epilogue-Zen’s-undocumented-420-counter)
This adds the typeid and `vcall_visibility` metadata to vtables when the
-Cvirtual-function-elimination flag is set.
The typeid is generated in the same way as for the
`llvm.type.checked.load` intrinsic from the trait_ref.
The offset that is added to the typeid is always 0. This is because LLVM
assumes that vtables are constructed according to the definition in the
Itanium ABI. This includes an "address point" of the vtable. In C++ this
is the offset in the vtable where information for RTTI is placed. Since
there is no RTTI information in Rust's vtables, this "address point" is
always 0. This "address point" in combination with the offset passed to
the `llvm.type.checked.load` intrinsic determines the final function
that should be loaded from the vtable in the
`WholeProgramDevirtualization` pass in LLVM. That's why the
`llvm.type.checked.load` intrinsics are generated with the typeid of the
trait, rather than with that of the function that is called. This
matches what `clang` does for C++.
The vcall_visibility metadata depends on three factors:
1. LTO level: Currently this is always fat LTO, because LLVM only
supports this optimization with fat LTO.
2. Visibility of the trait: If the trait is publicly visible, VFE
can only act on its vtables after linking.
3. Number of CGUs: if there is more than one CGU, also vtables with
restricted visibility could be seen outside of the CGU, so VFE can
only act on them after linking.
To reflect this, there are three visibility levels: Public, LinkageUnit,
and TranslationUnit.
Add the intrinsic
declare {i8*, i1} @llvm.type.checked.load(i8* %ptr, i32 %offset, metadata %type)
This is used in the VFE optimization when lowering loading functions
from vtables to LLVM IR. The `metadata` is used to map the function to
all vtables this function could belong to. This ensures that functions
from vtables that might be used somewhere won't get removed.
This function computes a Itanium-like typeid for a trait_ref. This is
required for the VFE optimization in LLVM. It is used to map
`llvm.type.checked.load` invocations, that is loading the function from
a vtable, to the vtables this function could be from.
It is important to note that `typeid`s are not unique. So multiple
vtables of the same trait can share `typeid`s.
To apply the optimization the `Virtual Function Elim` module flag has to
be set. To apply this optimization post-link the `LTOPostLink` module
flag has to be set.
Adds the virtual-function-elimination unstable compiler flag and a check
that this flag is only used in combination with -Clto. LLVM can only
apply this optimization with fat LTO.
lint: add diagnostic translation migration lints
Introduce allow-by-default lints for checking whether diagnostics are written in
`SessionDiagnostic` or `AddSubdiagnostic` impls and whether diagnostics are translatable. These lints can be denied for modules once they are fully migrated to impls and translation.
These lints are intended to be temporary - once all diagnostics have been changed then we can just change the APIs we have and that will enforce these constraints thereafter.
r? `````@oli-obk`````
Rename the `ConstS::val` field as `kind`.
And likewise for the `Const::val` method.
Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.
The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.
r? `@BoxyUwU`
Remove RegionckMode in favor of calling new skip_region_resolution
Simple cleanup. We can skip a bunch of stuff for places where NLL does the region checking, so skip earlier.
r? rust-lang/types
This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).
(This was previously merged as commit 5 in #94732 and then was reverted
in #97905 because of a perf regression caused by commit 4 in #94732.)
And likewise for the `Const::val` method.
Because its type is called `ConstKind`. Also `val` is a confusing name
because `ConstKind` is an enum with seven variants, one of which is
called `Value`. Also, this gives consistency with `TyS` and `PredicateS`
which have `kind` fields.
The commit also renames a few `Const` variables from `val` to `c`, to
avoid confusion with the `ConstKind::Value` variant.
Add Apple WatchOS compile targets
Hello,
I would like to add the following target triples for Apple WatchOS as Tier 3 platforms:
armv7k-apple-watchos
arm64_32-apple-watchos
x86_64-apple-watchos-sim
There are some pre-requisites Pull Requests:
https://github.com/rust-lang/compiler-builtins/pull/456 (merged)
https://github.com/alexcrichton/cc-rs/pull/662 (pending)
https://github.com/rust-lang/libc/pull/2717 (merged)
There will be a subsequent PR with standard library changes for WatchOS. Previous compiler and library changes were in a single PR (https://github.com/rust-lang/rust/pull/94736) which is now closed in favour of separate PRs.
Many thanks!
Vlad.
### Tier 3 Target Requirements
Adds support for Apple WatchOS compile targets.
Below are details on how this target meets the requirements for tier 3:
> tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
`@deg4uss3r` has volunteered to be the target maintainer. I am also happy to help if a second maintainer is required.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
Uses the same naming as the LLVM target, and the same convention as other Apple targets.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
I don't believe there is any ambiguity here.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
I don't see any legal issues here.
> The target must not introduce license incompatibilities.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
> If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
> Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
I see no issues with any of the above.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
Only relevant to those making approval decisions.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
core and alloc can be used. std support will be added in a subsequent PR.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.
Use --target=<target> option to cross compile, just like any target. Tests can be run using the WatchOS simulator (see https://developer.apple.com/documentation/xcode/running-your-app-in-the-simulator-or-on-a-device).
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
I don't foresee this being a problem.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
No other targets should be affected by the pull request.
Improve parser diagnostics
This pr fixes https://github.com/rust-lang/rust/issues/93867 and contains a couple of diagnostics related changes to the parser.
Here is a short list with some of the changes:
- don't suggest the same thing that is the current token
- suggest removing the current token if the following token is one of the suggestions (maybe incorrect)
- tell the user to put a type or lifetime after where if there is none (as a warning)
- reduce the amount of tokens suggested (via the new eat_noexpect and check_noexpect methods)
If any of these changes are undesirable, i can remove them, thanks!
Remove unnecessary `to_string` and `String::new`
73fa217bc1 changed the type of the `suggestion` argument to `impl ToString`. This patch removes unnecessary `to_string` and `String::new`.
cc: `````@davidtwco`````
Make `type_changing_struct_update` no longer an incomplete feature
After #97705, I don't see what would make it incomplete anymore. `check_expr_struct_fields` seems to now implement the RFC to the letter.
r? ``````@nikomatsakis``````
cc ``````@rust-lang/types``````
interpret: unify offset_from check with offset check
`offset` does the check with a single `check_ptr_access` call while `offset_from` used two calls. Make them both just one one call.
I originally intended to actually factor this into a common function, but I am no longer sure if that makes a lot of sense... the two functions start with pretty different precondition (e.g. `offset` *knows* that the 2nd pointer has the same provenance).
I also reworded the UB messages a little. Saying it "cannot" do something is not how we usually phrase UB (as far as I know). Instead it's not *allowed* to do that.
r? ``````@oli-obk``````
Use safer `strip=symbols`-flag for dylibs on macOS
Closes#93988
To safely strip dylibs on macOS, the `-x` flag is needed per the manpage (see the discussion here: https://github.com/rust-lang/rust/issues/93988#issuecomment-1042574854).
Thus, when the current `crate_type` is producing a dylib (I assume this is the case for proc macros) use the `-x` flag instead of bare `strip` for `strip=symbols`.
Tidy up miscellaneous bounds suggestions
Just some small fixes to suggestions
- Generalizes `Ty::is_suggestable` into a `TypeVisitor`, so that it can be called on things other than `Ty`
- Makes `impl Trait` in arg position no longer suggestible (generalizing the fix in #97640)
- Fixes `impl Trait` not being replaced with fresh type param when it's deeply nested in function signature (fixes#97760)
- Fixes some poor handling of `where` clauses with no predicates (also #97760)
- Uses `InferCtxt::resolve_numeric_literals_with_default` so we suggest `i32` instead of `{integer}` (fixes#97677)
Sorry there aren't many tests the fixes. Most of them would just be duplicates of other tests with empty `where` clauses or `impl Trait` in arg position instead of generic params. Let me know if you'd want more test coverage.
Fix inference issues with unconstrained base expr in `type_changing_struct_update`
Use fresh infer vars to guide inference along in `type_changing_struct_update`.
Fixes#96878
Handle `def_ident_span` like `def_span`.
`def_ident_span` had an ad-hoc status in the compiler.
This PR refactors it to be a first-class citizen like `def_span`:
- it gets encoded in the main metadata loop, instead of the visitor;
- its implementation is updated to mirror the one of `def_span`.
We do not remove the `Option` in the return type, since some items do not have an ident, AnonConsts for instance.
Make -Cpasses= only apply to pre-link optimization
This change causes passes specified in -Cpasses= to be applied
only during pre-link optimization, not during LTO. This avoids
such passes running multiple times, which they may not be
designed for.
Fixes https://github.com/rust-lang/rust/issues/97713
Rollup of 5 pull requests
Successful merges:
- #97761 (validating the vtable can lead to Stacked Borrows errors)
- #97789 (Fix#71363's test by adding `-Z translate-remapped-path-to-local-path=no`)
- #97913 (Wrap `HirId`s of locals into `LocalVarId`s for THIR nodes)
- #97979 (Fix typos in Provider API docs)
- #97987 (remove an unnecessary `String`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Wrap `HirId`s of locals into `LocalVarId`s for THIR nodes
This is the first effort to decouple `HirId`s from THIR. `HirId` is not very relevant in building THIR and MIR.
Based on the changeset, I think there are a few other pending refactoring that we could perform after this, in case we want to eliminate use of `HirId` in THIR.
- `TypeckResults::closure_min_captures` could be remapped from the variable `HirId`s to `LocalVarId` while the THIR is getting built.
- Use of `ScopeTree::var_scope` could be eliminated as well, since we will consider deprecating `ScopeTree` in the future.
Fix#71363's test by adding `-Z translate-remapped-path-to-local-path=no`
The test relies on `library/std/src/error.rs` not corresponding to a local path, but remapping might still find the related local file of a remapped path. To fix the test, this PR adds a new `-Z` flag to disable finding the corresponding local path of a remapped path.
Never regard macro rules with compile_error! invocations as unused
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we should never warn about unused macro arms
that contain invocations of compile_error.
See also https://github.com/rust-lang/rust/pull/96150#issuecomment-1126599107 and the discussion after that.
Furthermore, the PR also contains two commits to silence `unused_macro_rules` when a macro has an invalid rule, and to add a test that `unused_macros` does not behave badly in the same situation.
r? `@petrochenkov` as I've talked to them about this
Mention `infer::Trace` methods on `infer::At` methods' docs
I missed that you could do `infcx.at(...).trace(...).eq(a, b)` when `a` and `b` dont implement `ToTrace` but does implement `Relate` these docs would have helped see that 😅
Revert part of #94372 to improve performance
#94732 was supposed to give small but widespread performance improvements, as judged from three per-merge performance runs. But the performance run that occurred after merging included a roughly equal number of improvements and regressions, for unclear reasons.
This PR is for a test run reverting those changes, to see what happens.
r? `@ghost`
cleanup bound variable handling
each commit should be pretty self-contained and hopefully straightforward to review.
I've added 677ec23a8dbf8ff5f1c03ccebd46f8b85e5ec1fc so that we can stop returning the region map from `replace_bound_vars_with_fresh_vars` in the following commit.
r? `@nikomatsakis` or `@jackh726`
This change causes passes specified in -Cpasses= to be applied
only during pre-link optimization, not during LTO. This avoids
such passes running multiple times, which they may not be
designed for.
Fixes https://github.com/rust-lang/rust/issues/97713
Removes debug settings from wasm32_unknown_emscripten default link args
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
``@sbc100``
Introduce allow-by-default lints for checking whether diagnostics are
written in `SessionDiagnostic`/`AddSubdiagnostic` impls and whether
diagnostics are translatable. These lints can be denied for modules once
they are fully migrated to impls and translation.
Signed-off-by: David Wood <david.wood@huawei.com>
Rollup of 6 pull requests
Successful merges:
- #97718 (Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383))
- #97876 (update docs for `std::future::IntoFuture`)
- #97888 (Don't use __gxx_personality_v0 in panic_unwind on emscripten target)
- #97922 (Remove redundant calls to reserve in impl Write for VecDeque)
- #97927 (Do not introduce bindings for types and consts in HRTB.)
- #97937 (Fix a typo in `test/ui/hrtb/hrtb-just-for-static.rs`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)
Fixes a small ICE with the `delayed_good_path_bug` check.
---
r? ``@wesleywiser``
cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this
closes: https://github.com/rust-lang/rust/issues/95540
cc: https://github.com/rust-lang/rust/issues/85549
Prior to this commit, if a macro had any malformed rules, all rules would
be reported as unused, regardless of whether they were used or not.
So we just turn off unused rule checking completely for macros with
malformed rules.
The very point of compile_error! is to never be reached, and one of
the use cases of the macro, currently also listed as examples in the
documentation of compile_error, is to create nicer errors for wrong
macro invocations. Thus, we shuuld never warn about unused macro arms
that contain invocations of compile_error.
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
Revert "remove num_cpus dependency" in rustc and update cargo
Fixes#97549. This PR reverts #94524 and does a Cargo update to pull in rust-lang/cargo#10737.
Rust 1.61.0 has a regression in which it misidentifies the number of available CPUs in some environments, leading to enormously increased memory usage and failing builds. In between Rust 1.60 and 1.61 both rustc and cargo replaced some uses of `num_cpus` with `available_parallelism`, which eliminated support for cgroupv1, still apparently in common use. This PR switches both rustc and cargo back to using `num_cpus` in order to support environments where the available parallelism is controlled by cgroupv1. Both can use `available_parallism` again once it handles cgroupv1 (if ever).
I have confirmed that the rustc part of this PR fixes the memory usage regression in my non-Cargo environment, and others have confirmed in #97549 that the Cargo regression was at fault for the memory usage regression in their environments.
Relax mipsel-sony-psp's linker script
Previously, the linker script forcefully kept all `.lib.stub` sections, unnecessarily bloating the binary. Now, the script is LTO and `--gc-sections` friendly.
`--nmagic` was also added to the linker, because page alignment is not required on the PSP. This further reduces binary size.
Accompanying changes for the `psp` crate are found in: https://github.com/overdrivenpotato/rust-psp/pull/118
optimize `superset` method of `IntervalSet`
Given that intervals in the `IntervalSet` are sorted and strictly separated( it means the `end` of the previous interval will not be equal to the `start` of the next interval), we can reduce the complexity of the `superset` method from O(NMlogN) to O(2N) (N is the number of intervals and M is the length of each interval)
This commit adds a new unstable attribute, `#[doc(tuple_varadic)]`, that
shows a 1-tuple as `(T, ...)` instead of just `(T,)`, and links to a section
in the tuple primitive docs that talks about these.
use precise spans for recursive const evaluation
This fixes https://github.com/rust-lang/rust/issues/73283 by using a `TyCtxtAt` with a more precise span when the interpreter recursively calls itself. Hopefully such calls are sufficiently rare that this does not cost us too much performance.
(In theory, cycles can also arise through layout computation, as layout can depend on consts -- but layout computation happens all the time so we'd have to do something to not make this terrible for performance.)
Don't suggest adding `let` in certain `if` conditions
Avoid being too eager to suggest `let` in an `if` condition with an `=`, namely when the LHS of the `=` isn't even valid as a pattern (to a first degree approximation).
This heustic I came up with kinda sucks. Let me know if it needs to be refined.
Fix indices and remove some unwraps in arg mismatch algorithm
This is a more conservative fix than #97542, addressing some indices which were used incorectly and unwraps which are bound to panic (e.g. when the provided and expected arg counts differ). Beta nominating this as it's quite easy to cause ICEs -- I wrote a fuzzer and found hundreds of examples of ICEs.
cc `@jackh726` as author of #92364, and `@estebank` as reviewer of that PR.
fixes#97484
r? `@jackh726` this should be _much_ easier to review than the other PR 😅
Impl Traits lowering minor refactors
This are unrelated changes on my RPIT refactor that may be better to merge before opening the main PR.
r? `@cjgillot`
cc `@nikomatsakis`
Specify DWARF alignment in bits, not bytes.
In DWARF, alignment of types is specified in bits, as is made clear by the
parameter name `AlignInBits`. However, `rustc` was incorrectly passing a byte
alignment. This commit fixes that.
This was noticed in upstream LLVM when I tried to check in a test consisting of
LLVM IR generated from `rustc` and it triggered assertions [1].
[1]: https://reviews.llvm.org/D126835
it feels arbitrary to have `Ty` and `Const` directly
in that module and to not have `GenericArg` and
`GenericArgKind` there. Writing `ty::GenericArg`
can also feel clearer than importing it. Using
`ty::subst::GenericArg` however is ugly.
Recover missing comma after match arm
If we're missing a comma after a match arm expression, try parsing another pattern and a following `=>`. If we find both of those, then recover by suggesting to insert a `,`.
Fixes#80112
Recover `import` instead of `use` in item
When we definitely don't have a macro invocation (i.e. when we don't have `import ::`), then it's more productive to parse `import` as if it was incorrectly mistaken for `use`.
Not sure if this needs to be a verbose suggestion, but it renders strangely when it's not verbose:
```
error: expected item, found `import`
--> /home/michael/test.rs:1:1
|
1 | import std::{io::{self, Write}, rc::Rc};
| ^^^^^^ help: items are imported using the `use` keyword: `use`
```
Happy to change it to `span_suggestion` instead of `span_suggestion_verbose` though.
Fixes#97788
Remove unwrap from get_vtable
This avoids ICE on issue #97381 I think the bug is a bit deeper though, it compiles fine when `v` is `&v` which makes me think `Deref` is causing some issue with borrowck but it's fine I guess since this thing crashes since `nightly-2020-09-17` 😅
This avoids the name clash with `rustc_serialize::Encoder` (a trait),
and allows lots qualifiers to be removed and imports to be simplified
(e.g. fewer `as` imports).
This commit makes type folding more like the way chalk does it.
Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods.
- `fold_with` is the standard entry point, and defaults to calling
`super_fold_with`.
- `super_fold_with` does the actual work of traversing a type.
- For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead
calls into a `TypeFolder`, which can then call back into
`super_fold_with`.
With the new approach, `TypeFoldable` has `fold_with` and
`TypeSuperFoldable` has `super_fold_with`.
- `fold_with` is still the standard entry point, *and* it does the
actual work of traversing a type, for all types except types of
interest.
- `super_fold_with` is only implemented for the types of interest.
Benefits of the new model.
- I find it easier to understand. The distinction between types of
interest and other types is clearer, and `super_fold_with` doesn't
exist for most types.
- With the current model is easy to get confused and implement a
`super_fold_with` method that should be left defaulted. (Some of the
precursor commits fixed such cases.)
- With the current model it's easy to call `super_fold_with` within
`TypeFolder` impls where `fold_with` should be called. The new
approach makes this mistake impossible, and this commit fixes a number
of such cases.
- It's potentially faster, because it avoids the `fold_with` ->
`super_fold_with` call in all cases except types of interest. A lot of
the time the compile would inline those away, but not necessarily
always.
We already have `visit_unevaluated`, so this improves consistency.
Also, define `TypeFoldable for Unevaluated<'tcx, ()>` in terms of
`TypeFoldable for Unevaluated<'tcx>`, which is neater.
Because `TypeFoldable::try_fold_mir_const` exists, and even though
`visit_mir_const` isn't needed right now, the consistency makes the code
easier to understand.
RustWrapper: adapt to APInt API changes in LLVM 15
In https://reviews.llvm.org/D125556 upstream changed sext() and zext()
to allow some no-op cases, which previously required use of the *OrSelf()
methods, which I assume is what was going on here. The *OrSelf() methods
got removed in https://reviews.llvm.org/D125559 after two weeks of
deprecation because they came with some bonus (probably-undesired)
behavior. Since the behavior of sext() and zext() changed slightly, I
kept the old *OrSelf() calls in LLVM 14 and earlier, and only use the
new version in LLVM 15.
r? `@nikic`
Change `Direction::{is_forward,is_backward}` functions into constants
Make it explicit that the analysis direction is constant.
This also makes the value immediately available for optimizations.
Previously those functions were neither inline nor generic and so their
definition was unavailable when using data flow framework from other
crates.
There are two impls of the `Encoder` trait: `opaque::Encoder` and
`opaque::FileEncoder`. The former encodes into memory and is infallible, the
latter writes to file and is fallible.
Currently, standard `Result`/`?`/`unwrap` error handling is used, but this is a
bit verbose and has non-trivial cost, which is annoying given how rare failures
are (especially in the infallible `opaque::Encoder` case).
This commit changes how `Encoder` fallibility is handled. All the `emit_*`
methods are now infallible. `opaque::Encoder` requires no great changes for
this. `opaque::FileEncoder` now implements a delayed error handling strategy.
If a failure occurs, it records this via the `res` field, and all subsequent
encoding operations are skipped if `res` indicates an error has occurred. Once
encoding is complete, the new `finish` method is called, which returns a
`Result`. In other words, there is now a single `Result`-producing method
instead of many of them.
This has very little effect on how any file errors are reported if
`opaque::FileEncoder` has any failures.
Much of this commit is boring mechanical changes, removing `Result` return
values and `?` or `unwrap` from expressions. The more interesting parts are as
follows.
- serialize.rs: The `Encoder` trait gains an `Ok` associated type. The
`into_inner` method is changed into `finish`, which returns
`Result<Vec<u8>, !>`.
- opaque.rs: The `FileEncoder` adopts the delayed error handling
strategy. Its `Ok` type is a `usize`, returning the number of bytes
written, replacing previous uses of `FileEncoder::position`.
- Various methods that take an encoder now consume it, rather than being
passed a mutable reference, e.g. `serialize_query_result_cache`.
In DWARF, alignment of types is specified in bits, as is made clear by the
parameter name `AlignInBits`. However, `rustc` was incorrectly passing a byte
alignment. This commit fixes that.
This was noticed in upstream LLVM when I tried to check in a test consisting of
LLVM IR generated from `rustc` and it triggered assertions [1].
[1]: https://reviews.llvm.org/D126835
In https://reviews.llvm.org/D125556 upstream changed sext() and zext()
to allow some no-op cases, which previously required use of the *OrSelf()
methods, which I assume is what was going on here. The *OrSelf() methods
got removed in https://reviews.llvm.org/D125559 after two weeks of
deprecation because they came with some bonus (probably-undesired)
behavior. Since the behavior of sext() and zext() changed slightly, I
kept the old *OrSelf() calls in LLVM 14 and earlier, and only use the
new version in LLVM 15.
r? @nikic
Fix precise field capture of univariant enums
When constructing a MIR from a THIR field expression, introduce an
additional downcast projection before accessing a field of an enum.
When rebasing a place builder on top of a captured place, account for
the fact that a single HIR enum field projection corresponds to two MIR
projection elements: a downcast element and a field element.
Fixes#95271.
Fixes#96299.
Fixes#96512.
Fixes#97378.
r? ``@nikomatsakis`` ``@arora-aman``
Make it explicit that the analysis direction is constant.
This also makes the value immediately available for optimizations.
Previously those functions were neither inline nor generic and so their
definition was unavailable when using data flow framework from other
crates.
Previously, the linker script forcefully kept all `.lib.stub` sections,
unnecessarily bloating the binary. Now, the script is LTO and
`--gc-sections` friendly.
`--nmagic` was also added to the linker, because page alignment is not
required on the PSP. This further reduces binary size.
Accompanying changes for the PSP crate are found in:
https://github.com/overdrivenpotato/rust-psp/pull/118
Rollup of 5 pull requests
Successful merges:
- #97058 (Various refactors to the incr comp workproduct handling)
- #97301 (Allow unstable items to be re-exported unstably without requiring the feature be enabled)
- #97738 (Fix ICEs from zsts within unsized types with non-zero offsets)
- #97771 (Remove SIGIO reference on Haiku)
- #97808 (Add some unstable target features for the wasm target codegen)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add some unstable target features for the wasm target codegen
I was experimenting with cross-language LTO for the wasm target recently
between Rust and C and found that C was injecting the `+mutable-globals`
flag on all functions. When specifying the corresponding
`-Ctarget-feature=+mutable-globals` feature to Rust it prints a warning
about an unknown feature. I've added the `mutable-globals` feature plus
another few I know of to the list of known features for wasm targets.
These features all continue to be unstable to source code as they were
before.
Fix ICEs from zsts within unsized types with non-zero offsets
- Fixes#97732
- Fixes ICEs while compiling `alloc` with `-Z randomize-layout`
r? ``@eddyb``
Allow unstable items to be re-exported unstably without requiring the feature be enabled
Closes#94972
The diagnostic may need some work still, and I haven't added a test yet
Various refactors to the incr comp workproduct handling
This is the result of me looking into adding support for having multiple object files for a single codegen unit to incr comp. This is necessary to support inline assembly in cg_clif without requiring partial linking which is not supported on Windows and seems to fail on macOS for some reason. Cg_clif uses an external assembler to handle inline asm and thus produces one object file with regular functions and one object file containing compiled inline asm for each codegen unit which uses inline asm. Current incr comp can't handle this. This PR doesn't yet add support for this, but it makes it easier to do so.
Add support for emitting functions with `coldcc` to LLVM
The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
Remove migrate borrowck mode
Closes#58781Closes#43234
# Stabilization proposal
This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors, then MIR borrowck (NLL) never occurs. If there *aren't* any errors, then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program, this should not break any programs. It does, however, change diagnostics significantly and allows a slightly larger set of programs to compile.
Tracking issue: #43234
RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md
Version: 1.63 (2022-06-30 => beta, 2022-08-11 => stable).
## Motivation
Over time, the Rust borrow checker has become "smarter" and thus allowed more programs to compile. There have been three different implementations: AST borrowck, MIR borrowck, and polonius (well, in progress). Additionally, there is the "lexical region resolver", which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker, but does emit some errors.
The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017, work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017, for the most part. During 2018, efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into "migrate" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition.
In early 2019, migrate mode was turned on by default in the 2015 edition as well, but with MIR borrowck errors emitted as warnings. By late 2019, these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker.
In the period since, various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver.
While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics), those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff.
## What is stabilized
As said previously, this does not fundamentally change the landscape of accepted programs. However, there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)`, but not otherwise.
There are two notable patterns that are "fixed" by this stabilization. First, the `scoped_threads` feature, which is a continutation of a pre-1.0 API, can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second, actually seen in the standard library. In the `Extend` impl for `HashMap`, there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl.
As mentioned before, there are a large number of diagnostic differences. Most of them are better, but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general "lifetime may not live long enough" error. While this may *seem* bad, the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however, on paper, they end up being roughly the same with roughly the same kinds of solutions.
## What isn't stabilized
This PR does not completely remove the lexical region resolver. In the future, it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck.
## Tests
Many test outputs get updated by this PR. However, there are number of tests specifically geared towards NLL under `src/test/ui/nll`
## History
* On 2017-07-14, [tracking issue opened](https://github.com/rust-lang/rust/issues/43234)
* On 2017-07-20, [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271)
* On 2017-08-29, [RFC opened](https://github.com/rust-lang/rfcs/pull/2094)
* On 2017-11-16, [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825)
* On 2017-12-20, [NLL feature complete](https://github.com/rust-lang/rust/pull/46862)
* On 2018-07-07, [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083)
* On 2018-07-27, [Add migrate mode](https://github.com/rust-lang/rust/pull/52681)
* On 2019-04-22, [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114)
* On 2019-08-26, [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221)
* On 2019-08-27, [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)
I was experimenting with cross-language LTO for the wasm target recently
between Rust and C and found that C was injecting the `+mutable-globals`
flag on all functions. When specifying the corresponding
`-Ctarget-feature=+mutable-globals` feature to Rust it prints a warning
about an unknown feature. I've added the `mutable-globals` feature plus
another few I know of to the list of known features for wasm targets.
These features all continue to be unstable to source code as they were
before.
Rollup of 5 pull requests
Successful merges:
- #97312 (Compute lifetimes in scope at diagnostic time)
- #97495 (Add E0788 for improper #[no_coverage] usage)
- #97579 (Avoid creating `SmallVec`s in `global_llvm_features`)
- #97767 (interpret: do not claim UB until we looked more into variadic functions)
- #97787 (E0432: rust 2018 -> rust 2018 or later in --explain message)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: better control over whether we read data with provenance
The resolution in https://github.com/rust-lang/unsafe-code-guidelines/issues/286 seems to be that when we load data at integer type, we implicitly strip provenance. So let's implement that in Miri at least for scalar loads. This makes use of the fact that `Scalar` layouts distinguish pointer-sized integers and pointers -- so I was expecting some wild bugs where layouts set this incorrectly, but so far that does not seem to happen.
This does not entirely implement the solution to https://github.com/rust-lang/unsafe-code-guidelines/issues/286; we still do the wrong thing for integers in larger types: we will `copy_op` them and then do validation, and validation will complain about the provenance. To fix that we need mutating validation; validation needs to strip the provenance rather than complaining about it. This is a larger undertaking (but will also help resolve https://github.com/rust-lang/miri/issues/845 since we can reset padding to `Uninit`).
The reason this is useful is that we can now implement `addr` as a `transmute` from a pointer to an integer, and actually get the desired behavior of stripping provenance without exposing it!
interpret: do not claim UB until we looked more into variadic functions
I am not actually sure if this is UB, and anyway for FFI shims, Miri currently does not attempt to distinguish between arguments passed via variadics vs directly. So let's be consistent.
(Programs that ran into this error will anyway immediately fall through to the "unsupported" message on the next line.)
Avoid creating `SmallVec`s in `global_llvm_features`
This PR made a simple optimization to avoid creating extra `SmallVec`s by adjusting the use of iterator statements.
Also, given the very small size of `tied_target_features`, there is no need to insert each feature into the FxHashMap.
Add E0788 for improper #[no_coverage] usage
Essentially, this adds proper checking for the attribute (tracking issue #84605) and throws errors when it's put in obviously-wrong places, like on struct or const definitions. Most of the code is taken directly from the checks for the `#[inline]` attribute, since it's very similar.
Right now, the code only checks at the function level, but it seems reasonable to allow adding `#[no_coverage]` to individual blocks or expressions, so, for now those just throw `unused_attributes` warnings. Similarly, since there was a lot of desire to eventually allow recursive definitions as well on modules and impl blocks, these also throw `unused_attributes` instead of an error.
I'm not sure if anything has to be done since this error is technically for an unstable feature, but since an error for using unstable features will show up anyway, I think it's okay.
This is the first big piece needed for stabilising this attribute, although I personally would like to explore renaming it to `#[coverage(never)]` on a separate PR, which I will offer soon. There's a lot of discussion still to be had about that, which is why it will be kept separate.
I don't think much is needed besides adding this simple check and a UI test, but let me know if there's something else that should be added to make this happen.
Compute lifetimes in scope at diagnostic time
The set of available lifetimes is currently computed during lifetime resolution on HIR. It is only used for one diagnostic.
In this PR, HIR lifetime resolution just reports whether elided lifetimes are well-defined at the place of use. The diagnostic code is responsible for building a list of lifetime names if elision is not allowed.
This will allow to remove lifetime resolution on HIR eventually.
The test relies on library/std/src/error.rs not corresponding to a local
path, but remapping might still find the related local file of a
remapped path. To fix the test, this adds a new -Z flag to disable
finding the corresponding local path of a remapped path.
Do `suggest_await_before_try` with infer variables in self, and clean up binders
Fixes#97704
Also cleans up binders in this fn, since everything is a `Poly*` and we really shouldn't have stray escaping late-bound regions everywhere. That's why the function changed so much. This isn't necessary, so I can revert if necessary.
Because it really has two halves:
- A read-only part that checks if further work is needed.
- The further work part, which is much less hot.
This makes things a bit clearer and nicer.
Replace `&Vec<_>`s with `&[_]`s
It's generally preferable to use `&[_]` since it's one less indirection and it can be created from types other that `Vec`.
I've left `&Vec` in some locals where it doesn't really matter, in cases where `TypeFoldable` is expected (`TypeFoldable: Clone` so slice can't implement it) and in cases where it's `&TypeAliasThatIsActiallyVec`. Nothing important, really, I was just a little annoyed by `visit_generic_param_vec` :D
r? `@compiler-errors`
riscv32imac-unknown-xous-elf: add target
This PR starts the process of upstreaming support for our operating system, thanks to a suggestion from `@yaahc` [on Twitter](https://twitter.com/yaahc_/status/1530558574706839567?s=20&t=Mgkn1LEYvGU6FEi5SpZRsA). We have maintained a fork of Rust and have made changes to improve support for our platform since Rust 1.51. Now we would like to upstream these changes.
Xous is a microkernel operating system designed to run on small systems. The kernel contains a wide range of userspace processes that provide common services such as console output, networking, and time access.
The kernel and its services are completely written in Rust using a custom build of libstd. This adds support for this target to upstream Rust so that we can drop support for our out-of-tree `target.json` file.
This first patch adds a Tier 3 target for Xous running on RISC-V. Future patches will add libstd support, but those patches require changes to `dlmalloc` and `compiler_builtins`.
> Tier 3 policy:
>
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I will be the target maintainer for this target on matters that pertain to the `xous` part of the triple. For matters pertaining to the `riscv32imac` part of the triple, there should be no difference from all other `riscv` targets. If there are issues, I will address issues regarding the target.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
This is a new OS, so I have taken the `riscv32imac-unknown-none-elf` target and changed the `os` section of the triple. This follows convention on targets such as `riscv32gc-unknown-linux-gnu` and `mipsel-unknown-linux-uclibc`. An argument could be made for omitting the `-elf` section of the triple, such as `riscv32imc-esp-espidf`, however I'm not certain what benefit that has.
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
I feel that the target name does not introduce any ambiguity.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
The only unusual requirement for building the `compiler-builtins` crate is a standard RISC-V C compiler supported by `cc-rs`, and using this target does not require any additional software beyond what is shipped by `rustup`.
> The target must not introduce license incompatibilities.
All of the additional code will use Apache-2.0.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Agreed, and there is no problem here.
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
The only new dependency will be the `xous` crate, which is licensed `MIT OR Apache-2.0`
> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
Linking is performed by `rust-lld`
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
There are no terms. Xous is completely open. It runs on open hardware. We even provide the source to the CPU.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
This paragraph makes sense, but I don't think it's directed at me.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
This paragraph also does not appear to be directed at me.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
So far we have:
* Thread
* Mutexex
* Condvar
* TcpStream
* TcpListener
* UdpSocket
* DateTime
* alloc
These will be merged as part of libstd in a future patch once I submit support for Xous in `dlmalloc` and `compiler-builtins`.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Testing is currently done on real hardware or in a Renode emulator. I can add documentation on how to do this in a future patch, and I would need instructions on where to add said documentation.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Alright.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
Sounds good.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
This shouldn't affect any other targets, so this is understood.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
This shouldn't come up right away. `xous` is a new operating system, and most features are keyed off of `target(os = "xous")` rather than a given architecture.
Handle more cases in cfg_accessible
This PR tries to handle more cases in the cfg_accessible implementation by only emitting a "not sure" error only if we have partially resolved a path.
This PR also adds many tests for the "not sure" cases and for private items.
r? `@petrochenkov`
Improve soundness of rustc_data_structures
Make it runnable in miri by adding some ignores and changing N in miri. Also fix a stacked borrows issue in sip128.
Iterate over `maybe_unused_trait_imports` when checking dead trait imports
Closes#96873
r? `@cjgillot`
Some questions, if you have time:
- Is there a way to shorten the `rustc_data_structures::fx::FxIndexSet` path in the query declaration? I wasn't sure where to put a `use`.
- Was returning by reference from the query the right choice here?
- How would I go about evaluating the importance of the `is_dummy()` call in `check_crate`? I don't see failing tests when I comment it out. Should I just try to determine whether dummy spans can ever be put into `maybe_unused_trait_imports`?
- Am I doing anything silly with the various ID types?
- Is that `let-else` with `unreachable!()` bad? (i.e is there a better idiom? Would `panic!("<explanation>")` be better?)
- If I want to evaluate the perf of using a `Vec` as mentioned in #96873, is the best way to use the CI or is it feasible locally?
Thanks :)
It creates the src pointer first, which is then invalidated by a
unique borrow of the destination pointer. Swap the borrows around
to fix this. Found with miri.
Some tests took too long and owning_ref is fundamentally flawed,
so don't run these tests or run them with a shorter N. This makes
miri with `-Zmiri-strict-provenance` usable to find UB.
Xous is a microkernel operating system designed to run on small systems.
The kernel contains a wide range of userspace processes that provide
common services such as console output, networking, and time access.
The kernel and its services are completely written in Rust using a
custom build of libstd. This adds support for this target to upstream
Rust so that we can drop support for our out-of-tree `target.json` file.
Add a Tier 3 target for Xous running on RISC-V.
Signed-off-by: Sean Cross <sean@xobs.io>
Fix reachability analysis for const methods
Use `method_might_be_inlined` directly for `ImplItemKind::Fn` instead of duplicating the logic in `def_id_represents_local_inlined_item`.
This is parallel to how we use `item_might_be_inlined` for `ItemKind::Fn` in that same body.
Fixes#97708
Remove all json handling from rustc_serialize
Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation).
This allowed for removing and simplifying a lot of code, which hopefully results in faster serialization/deserialization and faster compiles of rustc itself.
Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format.
Note that I had to remove `-Zast-json` and `-Zast-json-noexpand` as the relevant AST types don't implement `serde::Serialize`.
Fixes#40177
See also https://github.com/rust-lang/compiler-team/issues/418
Compute `is_late_bound_map` query separately from lifetime resolution
This query is actually very simple, and is only useful for functions and method. It can be computed directly by fetching the HIR, with no need to embed it within the lifetime resolution visitor.
Based on https://github.com/rust-lang/rust/pull/96296
rewrite error handling for unresolved inference vars
Pretty much completely rewrites `fn emit_inference_failure_err`.
This new setup should hopefully be easier to extend and is already a lot better when looking for generic arguments.
Because this is a rewrite there are still some parts which are lacking, these are tracked in #94483 and will be fixed in later PRs.
r? `@estebank` `@petrochenkov`
On E0204 suggest missing type param bounds
```
error[E0204]: the trait `Copy` may not be implemented for this type
--> f42.rs:9:17
|
9 | #[derive(Debug, Copy, Clone)]
| ^^^^
10 | pub struct AABB<K>{
11 | pub loc: Vector2<K>,
| ------------------- this field does not implement `Copy`
12 | pub size: Vector2<K>
| -------------------- this field does not implement `Copy`
|
note: the `Copy` impl for `Vector2<K>` requires that `K: Debug`
--> f42.rs:11:5
|
11 | pub loc: Vector2<K>,
| ^^^^^^^^^^^^^^^^^^^
note: the `Copy` impl for `Vector2<K>` requires that `K: Debug`
--> f42.rs:12:5
|
12 | pub size: Vector2<K>
| ^^^^^^^^^^^^^^^^^^^^
= note: this error originates in the derive macro `Copy` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider restricting type parameter `K`
|
10 | pub struct AABB<K: Debug>{
| +++++++
```
Fix#89137.
take back half-baked noaliasing check in Assignment
Doing an aliasing check in `copy_op` does not make a ton of sense. We have to eventually do something in the `Assignment` statement handling instead.
Remove label/lifetime shadowing warnings
This PR removes some pre-1.0 shadowing warnings for labels and lifetimes.
The current behaviour of the compiler is to warn
* labels that shadow unrelated labels in the same function --> removed
```rust
'a: loop {}
'a: loop {} // STOP WARNING
```
* labels that shadow enclosing labels --> kept, but only if shadowing is hygienic
```rust
'a: loop {
'a: loop {} // KEEP WARNING
}
```
* labels that shadow lifetime --> removed
```rust
fn foo<'a>() {
'a: loop {} // STOP WARNING
}
```
* lifetimes that shadow labels --> removed
```rust
'a: loop {
let b = Box::new(|x: &i8| *x) as Box<dyn for <'a> Fn(&'a i8) -> i8>; // STOP WARNING
}
```
* lifetimes that shadow lifetimes --> kept
```rust
fn foo<'a>() {
let b = Box::new(|x: &i8| *x) as Box<dyn for <'a> Fn(&'a i8) -> i8>; // KEEP WARNING
}
```
Closes https://github.com/rust-lang/rust/issues/31745.
-----
From `@petrochenkov` in https://github.com/rust-lang/rust/pull/95781#issuecomment-1105199014
> I think we should remove these silly checks entirely.
> They were introduced long time ago in case some new language features appear and require this space.
> Now we have another mechanism for such language changes - editions, and if "lifetimes in expressions" or something like that needs to be introduced it could be introduced as an edition change.
> However, there was no plans to introduce anything like for years, so it's unlikely that even the edition mechanism will be necessary.
r? rust-lang/lang
don't use a `span_note` for ignored impls
Searching for the `derive` isn't too difficult as it's right above the field definition.
By using a span these errors are a lot more verbose than they should be, which is especially annoying as one can end up with a lot of `dead_code` warnings.
```
error[E0204]: the trait `Copy` may not be implemented for this type
--> f42.rs:9:17
|
9 | #[derive(Debug, Copy, Clone)]
| ^^^^
10 | pub struct AABB<K>{
11 | pub loc: Vector2<K>,
| ------------------- this field does not implement `Copy`
12 | pub size: Vector2<K>
| -------------------- this field does not implement `Copy`
|
note: the `Copy` impl for `Vector2<K>` requires that `K: Debug`
--> f42.rs:11:5
|
11 | pub loc: Vector2<K>,
| ^^^^^^^^^^^^^^^^^^^
note: the `Copy` impl for `Vector2<K>` requires that `K: Debug`
--> f42.rs:12:5
|
12 | pub size: Vector2<K>
| ^^^^^^^^^^^^^^^^^^^^
= note: this error originates in the derive macro `Copy` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider restricting type parameter `K`
|
10 | pub struct AABB<K: Debug>{
| +++++++
```
Fix#89137.
Lazify `SourceFile::lines`.
`SourceFile::lines` is a big part of metadata. It's stored in a compressed form
(a difference list) to save disk space. Decoding it is a big fraction of
compile time for very small crates/programs.
This commit introduces a new type `SourceFileLines` which has a `Lines`
form and a `Diffs` form. The latter is used when the metadata is first
read, and it is only decoded into the `Lines` form when line data is
actually needed. This avoids the decoding cost for many files,
especially in `std`. It's a performance win of up to 15% for tiny
crates/programs where metadata decoding is a high part of compilation
costs.
A `RefCell` is needed because the methods that access lines data (which can
trigger decoding) take `&self` rather than `&mut self`. To allow for this,
`SourceFile::lines` now takes a `FnMut` that operates on the lines slice rather
than returning the lines slice.
r? `@Mark-Simulacrum`
Revert #96682.
The change was "Show invisible delimiters (within comments) when pretty
printing". It's useful to show these delimiters, but is a breaking
change for some proc macros.
Fixes#97608.
r? ``@petrochenkov``
[RFC 2011] Basic compiler infrastructure
Splitting https://github.com/rust-lang/rust/pull/96496 into smaller pieces as was done in https://github.com/rust-lang/rust/pull/97233. Hope review will be easier.
This PR practically contains no logic and only serves as a building ground for the actual code that will be placed in a posterior step.
* Adds `context.rs` to place the new `assert!` logic. Has a lot of unused elements but all of them are used by the implementation.
* Creates an unstable flag because the feature is not yet complete and also to allow external feedback.
* Creates the necessary `sym` identifiers that are mostly based on the library elements -> https://github.com/rust-lang/rust/blob/master/library/core/src/asserting.rs
* Modifies `assert.rs` to branch to `context.rs` if the unstable flag is enabled.
* Adds a test to satisfy tidy but the test does nothing in reality.
Add #[rustc_box] and use it inside alloc
This commit adds an alternative content boxing syntax, and uses it inside alloc.
```Rust
#![feature(box_syntax)]
fn foo() {
let foo = box bar;
}
```
is equivalent to
```Rust
#![feature(rustc_attrs)]
fn foo() {
let foo = #[rustc_box] Box::new(bar);
}
```
The usage inside the very performance relevant code in
liballoc is the only remaining relevant usage of box syntax
in the compiler (outside of tests, which are comparatively easy to port).
box syntax was originally designed to be used by all Rust
developers. This introduces a replacement syntax more tailored
to only being used inside the Rust compiler, and with it,
lays the groundwork for eventually removing box syntax.
[Earlier work](https://github.com/rust-lang/rust/pull/87781#issuecomment-894714878) by `@nbdd0121` to lower `Box::new` to `box` during THIR -> MIR building ran into borrow checker problems, requiring the lowering to be adjusted in a way that led to [performance regressions](https://github.com/rust-lang/rust/pull/87781#issuecomment-894872367). The proposed change in this PR lowers `#[rustc_box] Box::new` -> `box` in the AST -> HIR lowering step, which is way earlier in the compiler, and thus should cause less issues both performance wise as well as regarding type inference/borrow checking/etc. Hopefully, future work can move the lowering further back in the compiler, as long as there are no performance regressions.
Diagnose anonymous lifetimes errors more uniformly between async and regular fns
Async fns and regular fns are desugared differently. For the former, we create a generic parameter at HIR level. For the latter, we just create an anonymous region for typeck.
I plan to migrate regular fns to the async fn desugaring.
Before that, this PR attempts to merge the diagnostics for both cases.
r? ```@estebank```
Apply track_caller to closure on `expect_non_local()`
r? `@petrochenkov`
Alternatively we could remove the closure by replicating the same logic of `map_id()`. I'm happy to switch to it if you'd like.
Add Windows application manifest to rustc-main
Windows allows setting some runtime options using a manifest file. The format of the XML file is documented here: https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests
The manifest file in this PR does three things:
* Declares which Windows versions we support. This may help avoid unnecessary compatibility shims.
* Uses the UTF-8 code page. While Rust itself uses UTF-16 APIs, other code may rely on the code page.
* Makes the application long path aware (if also enabled by the user). This allows for the current directory to be longer than `PATH_MAX`.
These changes only affect the `rustc` process and not any other DLLs or compiled programs.
The change was "Show invisible delimiters (within comments) when pretty
printing". It's useful to show these delimiters, but is a breaking
change for some proc macros.
Fixes#97608.
rename PointerAddress → PointerExposeAddress
`PointerAddress` sounds a bit too much like `ptr.addr()`, but this corresponds to `ptr.expose_addr()`.
r? `@tmiasko`
Move conditions out of recover/report functions.
`Parser` has six recover/report functions that are passed a boolean, and
nothing is done if the boolean has a particular value.
This PR moves the tests outside the functions. This has the following effects.
- The number of lines of code goes down.
- Some `use` items become shorter.
- Avoids the strangeness whereby 11 out of 12 calls to
`maybe_recover_from_bad_qpath` pass `true` as the second argument.
- Makes it clear at the call site that only one of
`maybe_recover_from_bad_type_plus` and `maybe_report_ambiguous_plus` will be
run.
r? `@estebank`
* Confirm the path segment being modified is an `enum`
* Check whether type has type param before suggesting changing `Self`
* Wording changes
* Add clarifying comments
* Suggest removing args from `Self` if the type doesn't have type params
Rollup of 4 pull requests
Successful merges:
- #96271 (suggest `?` when method is missing on `Result<T, _>` but found on `T`)
- #97264 (Suggest `extern crate foo` when failing to resolve `use foo`)
- #97592 (rustdoc: also index impl trait and raw pointers)
- #97621 (update Miri)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Tweak insert docs
For `{Hash, BTree}Map::insert`, I always have to take a few extra seconds to think about the slight weirdness about the fact that if we "did not" insert (which "sounds" false), we return true, and if we "did" insert, (which "sounds" true), we return false.
This tweaks the doc comments for the `insert` methods of those types (as well as what looks like a rustc internal data structure that I found just by searching the codebase for "If the set did") to first use the "Returns whether _something_" pattern used in e.g. `remove`, where we say that `remove` "returns whether the value was present".
simplify code of finding arg index in `opt_const_param_of`
From the FIXME in the impl of `opt_const_param_of`. Part of the code is simplified by blending two iterator statements and using `let...else` statement.
Ensure we never consider the null pointer dereferencable
This replaces the checks that are being removed in https://github.com/rust-lang/rust/pull/97188. Those checks were too early and hence incorrect.
`SourceFile::lines` is a big part of metadata. It's stored in a compressed form
(a difference list) to save disk space. Decoding it is a big fraction of
compile time for very small crates/programs.
This commit introduces a new type `SourceFileLines` which has a `Lines`
form and a `Diffs` form. The latter is used when the metadata is first
read, and it is only decoded into the `Lines` form when line data is
actually needed. This avoids the decoding cost for many files,
especially in `std`. It's a performance win of up to 15% for tiny
crates/programs where metadata decoding is a high part of compilation
costs.
A `Lock` is needed because the methods that access lines data (which can
trigger decoding) take `&self` rather than `&mut self`. To allow for this,
`SourceFile::lines` now takes a `FnMut` that operates on the lines slice rather
than returning the lines slice.
This commit adds an alternative content boxing syntax,
and uses it inside alloc.
The usage inside the very performance relevant code in
liballoc is the only remaining relevant usage of box syntax
in the compiler (outside of tests, which are comparatively
easy to port).
box syntax was originally designed to be used by all Rust
developers. This introduces a replacement syntax more tailored
to only being used inside the Rust compiler, and with it,
lays the groundwork for eventually removing box syntax.
Rollup of 6 pull requests
Successful merges:
- #89685 (refactor: VecDeques Iter fields to private)
- #97172 (Optimize the diagnostic generation for `extern unsafe`)
- #97395 (Miri call ABI check: ensure type size+align stay the same)
- #97431 (don't do `Sized` and other return type checks on RPIT's real type)
- #97555 (Source code page: line number click adds `NaN`)
- #97558 (Fix typos in comment)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
don't do `Sized` and other return type checks on RPIT's real type
Fixes an ICE where we're doing `Sized` check against the RPIT's real type, instead of against the opaque type. This differs from what we're doing in MIR typeck, which causes ICE #97226.
This regressed in #96516 -- this adjusts that fix to be a bit more conservative. That PR was backported and thus the ICE is also present in stable. Not sure if it's worth to beta and/or stable backport, probably not the latter but I could believe the former.
r? `@oli-obk`
cc: another attempt to fix this ICE #97413. I believe this PR addresses the root cause.
Miri call ABI check: ensure type size+align stay the same
We should almost certainly not accept calls where caller and callee disagree on the size or alignment of the type.
The checks we do *almost* imply that, except that `ScalarPair` types can have `repr(align)` and thus differ in size/align even when they are pairs of the same primitive type.
r? ``@oli-obk``
Optimize the diagnostic generation for `extern unsafe`
This PR does the following about diagnostic generation when parsing foreign mod:
1. Fixes the FIXME about avoiding depending on the error message text.
2. Continue parsing when `unsafe` is followed by `{` (just like `unsafe extern {...}`).
3. Add test case.
errors: simplify referring to fluent attributes
To render the message of a Fluent attribute, the identifier of the Fluent message must be known. `DiagnosticMessage::FluentIdentifier` contains both the message's identifier and optionally the identifier of an attribute. Generated constants for each attribute would therefore need to be named uniquely (amongst all error messages) or be able to refer to only the attribute identifier which will be combined with a message identifier later. In this commit, the latter strategy is implemented as part of the `Diagnostic` type's functions for adding subdiagnostics of various kinds.
r? `@oli-obk`
Add validation layer for Derefer
_Follow up work to #96549#96116#95857 #95649_
This adds validation for Derefer making sure it is always the first projection.
r? rust-lang/mir-opt
To render the message of a Fluent attribute, the identifier of the
Fluent message must be known. `DiagnosticMessage::FluentIdentifier`
contains both the message's identifier and optionally the identifier of
an attribute. Generated constants for each attribute would therefore
need to be named uniquely (amongst all error messages) or be able to
refer to only the attribute identifier which will be combined with a
message identifier later. In this commit, the latter strategy is
implemented as part of the `Diagnostic` type's functions for adding
subdiagnostics of various kinds.
Signed-off-by: David Wood <david.wood@huawei.com>
Ensure source file present when calculating max line number
Resubmission of #89268, fixes#71363
The behavior difference of `simulate-remapped-rust-src-base` is not something we should take into account here, so limiting targets to run the test makes sense, I think.
r? `@davidtwco,` and `@estebank,` you might be interested in this change
Replace `#[default_method_body_is_const]` with `#[const_trait]`
pulled out of #96077
related issues: #67792 and #92158
cc `@fee1-dead`
This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).
Finish bumping stage0
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
This now brings us to cfg-clean, with the exception of check-cfg-features in bootstrap;
I'd prefer to leave that for a separate PR at this time since it's likely to be more tricky.
cc https://github.com/rust-lang/rust/pull/97147#issuecomment-1132845061
r? `@pietroalbini`
Prepare Rust for opaque pointers
Fix one codegen bug with opaque pointers, and update our IR tests to accept both typed pointer and opaque pointer IR. This is a bit annoying, but unavoidable if we want decent test coverage on both LLVM 14 and LLVM 15.
This prepares Rust for when LLVM will enable opaque pointers by default.
Rollup of 5 pull requests
Successful merges:
- #96950 (Add regression test for #96395)
- #97028 (Add support for embedding pretty printers via `#[debugger_visualizer]` attribute)
- #97478 (Remove FIXME on `ExtCtxt::fn_decl()`)
- #97479 (Make some tests check-pass)
- #97482 (ptr::invalid is not equivalent to a int2ptr cast)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove FIXME on `ExtCtxt::fn_decl()`
`ExtCtxt::fn_decl()` is used like `self.fn_decl(..)` or `self.cx.fn_decl(..)`, coverting it to an assoc fn, for example, makes it inconvenience (e.g. `self.cx.fn_decl(..)` would be longer to represent). Given that, it doesn't seem a "FIXME" thing and unused `self` is okay, I think.
Add support for embedding pretty printers via `#[debugger_visualizer]` attribute
Initial support for [RFC 3191](https://github.com/rust-lang/rfcs/pull/3191) in PR https://github.com/rust-lang/rust/pull/91779 was scoped to supporting embedding NatVis files using a new attribute. This PR implements the pretty printer support as stated in the RFC mentioned above.
This change includes embedding pretty printers in the `.debug_gdb_scripts` just as the pretty printers for rustc are embedded today. Also added additional tests for embedded pretty printers. Additionally cleaned up error checking so all error checking is done up front regardless of the current target.
RFC: https://github.com/rust-lang/rfcs/pull/3191
Update to rebased rustc-rayon 0.4
In rayon-rs/rayon#938, miri uncovered a race in `rustc-rayon-core` that had already been fixed in the regular `rayon-core`. I have now rebased that fork onto the latest rayon branch, and published as 0.4. I also updated `indexmap` to bump the dependency.
`Cargo.lock` changes:
Updating indexmap v1.8.0 -> v1.8.2
Updating rayon v1.5.1 -> v1.5.3
Updating rayon-core v1.9.1 -> v1.9.3
Updating rustc-rayon v0.3.2 -> v0.4.0
Updating rustc-rayon-core v0.3.2 -> v0.4.1
Previously whenever a duplicate discriminant was detected for an Enum,
we would print the discriminant bits in the diagnostic without any
casting. This caused us to display incorrect values for negative
discriminants. After this PR we format the discriminant signedness
correctly. Also reworded some of the original error
messages.
proc_macro: don't pass a client-side function pointer through the server.
Before this PR, `proc_macro::bridge::Client<F>` contained both:
* the C ABI entry-point `run`, that the server can call to start the client
* some "payload" `f: F` passed to that entry-point
* in practice, this was always a (client-side Rust ABI) `fn` pointer to the actual function the proc macro author wrote, i.e. `#[proc_macro] fn foo(input: TokenStream) -> TokenStream`
In other words, the client was passing one of its (Rust) `fn` pointers to the server, which was passing it back to the client, for the client to call (see later below for why that was ever needed).
I was inspired by `@nnethercote's` attempt to remove the `get_handle_counters` field from `Client` (see https://github.com/rust-lang/rust/pull/97004#issuecomment-1139273301), which combined with removing the `f` ("payload") field, could theoretically allow for a `#[repr(transparent)]` `Client` that mostly just newtypes the C ABI entry-point `fn` pointer <sub>(and in the context of e.g. wasm isolation, that's *all* you want, since you can reason about it from outside the wasm VM, as just a 32-bit "function table index", that you can pass to the wasm VM to call that function)</sub>.
<hr/>
So this PR removes that "payload". But it's not a simple refactor: the reason the field existed in the first place is because monomorphizing over a function type doesn't let you call the function without having a value of that type, because function types don't implement anything like `Default`, i.e.:
```rust
extern "C" fn ffi_wrapper<A, R, F: Fn(A) -> R>(arg: A) -> R {
let f: F = ???; // no way to get a value of `F`
f(arg)
}
```
That could be solved with something like this, if it was allowed:
```rust
extern "C" fn ffi_wrapper<
A, R,
F: Fn(A) -> R,
const f: F // not allowed because the type is a generic param
>(arg: A) -> R {
f(arg)
}
```
Instead, this PR contains a workaround in `proc_macro::bridge::selfless_reify` (see its module-level comment for more details) that can provide something similar to the `ffi_wrapper` example above, but limited to `F` being `Copy` and ZST (and requiring an `F` value to prove the caller actually can create values of `F` and it's not uninhabited or some other unsound situation).
<hr/>
Hopefully this time we don't have a performance regression, and this has a chance to land.
cc `@mystor` `@bjorn3`
Try to cache region_scope_tree as a query
This PR will attempt to restore `region_scope_tree` as a query so that caching works again. It seems that `region_scope_tree` could be re-computed for nested items after all, which could explain the performance regression introduced by #95563.
cc `@Mark-Simulacrum` `@pnkfelix` I will try to trigger a perf run here.
Split dead store elimination off dest prop
This splits off a part of #96451 . I've added this in as its own pass for now, so that it actually runs, can be tested, etc. In the dest prop PR, I'll stop invoking this as its own pass, so that it doesn't get invoked twice.
r? `@tmiasko`
macros: introduce `fluent_messages` macro
Adds a new `fluent_messages` macro which performs compile-time validation of the compiler's Fluent resources (i.e. that the resources parse and don't multiply define the same messages) and generates constants that make using those messages in diagnostics more ergonomic.
For example, given the following invocation of the macro..
```rust
fluent_messages! {
typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..
```fluent
typeck-field-multiply-specified-in-initializer =
field `{$ident}` specified more than once
.label = used more than once
.label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it fails to do so...
```text
error: could not parse Fluent resource
--> $DIR/test.rs:35:28
|
LL | missing_message => "./missing-message.ftl",
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: see additional errors emitted
error: expected a message field for "missing-message"
--> ./missing-message.ftl:1:1
|
1 | missing-message =
| ^^^^^^^^^^^^^^^^^^
|
```
...or generating the following code if it succeeds:
```rust
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
include_str!("./typeck.ftl"),
];
mod fluent_generated {
mod typeck {
pub const field_multiply_specified_in_initializer: DiagnosticMessage =
DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
DiagnosticMessage::fluent_attr(
"typeck-field-multiply-specified-in-initializer",
"previous-use-label"
);
}
}
```
When emitting a diagnostic, the generated constants can be used as follows:
```rust
let mut err = sess.struct_span_err(
span,
fluent::typeck::field_multiply_specified_in_initializer
);
err.span_label(
span,
fluent::typeck::field_multiply_specified_in_initializer_label
);
err.span_label(
previous_use_span,
fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```
I'd like to reduce the verbosity of referring to labels/notes/helps with this scheme (though it wasn't much better before), but I'll leave that for a follow-up.
r? `@oli-obk`
cc `@pvdrz` `@compiler-errors`
Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL
This PR introduces suggestions for relaxing static lifetime bounds on impls of dyn trait items for NLL similar to what is already available in lexical region diagnostics.
Fixes https://github.com/rust-lang/rust/issues/95701
r? `@estebank`
Update jemalloc to v5.3
Now that `jemalloc` version 5.3 has been released, this PR updates `tikv-jemalloc-sys` to the corresponding release.
The crates.io publishing issue seems to have been resolved for the `jemalloc-sys` package, and version 5.3.0 is now also available under the historical name (and should become the preferred crate to be used). Therefore, this PR also switches back to using `jemalloc-sys` instead of `tikv-jemalloc-sys`.
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
Move various checks to typeck so them failing causes the typeck result to get tainted
Fixes#69487fixes#79047
cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant
libcore: Add `iter::from_generator` which is like `iter::from_fn`, but for coroutines instead of functions
An equally useful little helper.
I didn't follow any of the async-wg work, so I don't know why something like this wasn't added before.
omit `record_accesses` function when collecting `MonoItem`s
This PR fixes the FIXME in the impl of `record_accesses` function.
[Edit] We can call `instantiation_mode` when push the `MonoItem` into `neighbors`. This avoids extra local variables `accesses: SmallVec<[_; 128]>`
`imported_source_files` adjusts lots of file positions, and then calls
`new_imported_source_file`, which then adjust them all again. This
commit combines the two adjustments into one, for a small perf win.
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
Output correct type responsible for structural match violation
Previously we included the outermost type that caused a structural match violation in the error message and stated that that type must be annotated with `#[derive(Eq, PartialEq)]` even if it already had that annotation. This PR outputs the correct type in the error message.
Fixes https://github.com/rust-lang/rust/issues/97278
Do writeback of Closure params before visiting the parent expression
This means that given the expression:
```
let x = |a: Vec<_>| {};
```
We will visit the HIR node for `a` before `x`, and report the ambiguity on the former instead of the latter. This also moves writeback for struct field ids and const blocks before, but the ordering of this and walking the expr doesn't seem to matter.
This was relying on the presence of a bitcast to avoid using the
constant global initializer for a load using a different type.
With opaque pointers, we need to check this explicitly.
Minor improvement on else-no-if diagnostic
Don't suggest wrapping in block since it's highly likely to be a missing `if` after `else`. Also rework message a bit (open to further suggestions).
cc: https://github.com/rust-lang/rust/pull/97298#discussion_r880933431
r? `@estebank`
RFC3239: Implement `cfg(target)` - Part 2
This pull-request implements the compact `cfg(target(..))` part of [RFC 3239](https://github.com/rust-lang/rust/issues/96901).
I recommend reviewing this PR on a per commit basics, because of some moving parts.
cc `@GuillaumeGomez`
r? `@petrochenkov`
Modify MIR building to drop repeat expressions with length zero
Closes#74836 .
Previously, when a user wrote `[foo; 0]` we used to simply leak `foo`. The goal is to fix that. This PR changes MIR building to make `[foo; 0]` equivalent to `{ drop(foo); [] }` in all cases. Of course, this is a breaking change (see below). A crater run did not indicate any regressions though, and given that the previous behavior was almost definitely not what any user wanted, it seems unlikely that anyone was relying on this.
Note that const generics are in general unaffected by this. Inserting the extra `drop` is only meaningful/necessary when `foo` is of a non-`Copy` type, and array repeat expressions with const generic repetition count must always be `Copy`.
Besides the obvious change to behavior associated with the additional drop, there are three categories of examples where this also changes observable behavior. In all of these cases, the new behavior is consistent with what you would get by replacing `[foo; 0]` with `{ drop(foo); [] }`. As such, none of these give the user new powers to express more things.
**No longer allowed in const (breaking)**:
```rust
const _: [String; 0] = [String::new(); 0];
```
This compiles on stable today. Because we now introduce the drop of `String`, this no longer compiles as `String` may not be dropped in a const context.
**Reduced dataflow (non-breaking)**:
```rust
let mut x: i32 = 0;
let r = &x;
let a = [r; 0];
x = 5;
let _b = a;
```
Borrowck rejects this code on stable because it believes there is dataflow between `a` and `r`, and so the lifetime of `r` has to extend to the last statement. This change removes the dataflow and the above code is allowed to compile.
**More const promotion (non-breaking)**:
```rust
let _v: &'static [String; 0] = &[String::new(); 0];
```
This does not compile today because `String` having drop glue keeps it from being const promoted (despite that drop glue never being executed). After this change, this is allowed to compile.
### Alternatives
A previous attempt at this tried to reduce breakage by various tricks. This is still a possibility, but given that crater showed no regressions it seems unclear why we would want to introduce this complexity.
Disallowing `[foo; 0]` completely is also an option, but obviously this is more of a breaking change. I do not know how often this is actually used though.
r? `@oli-obk`
add a deep fast_reject routine
continues the work on #97136.
r? `@nnethercote`
Actually agree with you on the match structure 😆 let's see how that impacted perf 😅
Rollup of 5 pull requests
Successful merges:
- #93604 (Make llvm-libunwind a per-target option)
- #97026 (Change orderings of `Debug` for the Atomic types to `Relaxed`.)
- #97105 (Add tests for lint on type dependent on consts)
- #97323 (Introduce stricter checks for might_permit_raw_init under a debug flag )
- #97379 (Add aliases for `current_dir`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
`match_impl` has two call sites. For one of them (within `rematch_impl`)
the fast reject test isn't necessary, because any rejection would
represent a compiler bug.
This commit moves the fast reject test to the other `match_impl` call
site, in `assemble_candidates_from_impls`. This lets us move the fast
reject test outside the `probe` call in that function. This avoids the
taking of useless snapshots when the fast reject test succeeds, which
gives a performance win when compiling the `bitmaps` and `nalgebra`
crates.
Co-authored-by: name <n.nethercote@gmail.com>
Introduce stricter checks for might_permit_raw_init under a debug flag
This is intended to be a version of the strict checks tried out in #79296, but also checking number validity (under the assumption that `let _ = std::mem::uninitialized::<u32>()` is UB, which seems to be what https://github.com/rust-lang/unsafe-code-guidelines/issues/71 is leaning towards.)
Make `Lazy*<T>` types in `rustc_metadata` not care about lifetimes until decode
This allows us to remove the `'tcx` lifetime from `CrateRoot`. This is necessary because of #97287, which makes the `'tcx` lifetime on `Ty` invariant instead of covariant, so [this hack](0a437b2ca0/compiler/rustc_metadata/src/rmeta/decoder.rs (L89-92)) no longer holds under that PR.
Introduces a trait called `ParameterizedOverTcx` which has a generic associated type that allows a type to be parameterized over that lifetime. This means we can decode, for example, `Lazy<Ty<'static>>` into any `Ty<'tcx>` depending on the `TyCtxt<'tcx>` we pass into the decode function.
Make weird name lints trigger behind cfg_attr
The weird name lints (`unknown_lints`, `renamed_and_removed_lints`), the lints that lint the linting, were previously not firing for lint level declarations behind `cfg_attr`, as they were only running before expansion.
Now, this will give a `unknown_lints` warning:
```Rust
#[cfg_attr(all(), allow(this_lint_does_not_exist))]
fn foo() {}
```
Lint level declarations behind a `cfg_attr` whose condition is not applying are still ignored. So this still won't give a warning:
```Rust
#[cfg_attr(any(), allow(this_lint_does_not_exist))]
fn foo() {}
```
Furthermore, this PR also makes the weird name lints respect level delcarations for *them* that were hidden by `cfg_attr`, making them consistent to other lints. So this will now not issue a warning:
```Rust
#[cfg_attr(all(), allow(unknown_lints))]
mod foo {
#[allow(does_not_exist)]
fn foo() {
}
}
```
Fixes#97094
Ensure all error checking for `#[debugger_visualizer]` is done up front and not when the `debugger_visualizer` query is run.
Clean up potential ODR violations when embedding pretty printers into the `__rustc_debug_gdb_scripts_section__` section.
Respond to PR comments and update documentation.
Rollup of 4 pull requests
Successful merges:
- #97288 (Lifetime variance fixes for rustdoc)
- #97298 (Parse expression after `else` as a condition if followed by `{`)
- #97308 (Stabilize `cell_filter_map`)
- #97321 (explain how to turn integers into fn ptrs)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use new typed Fluent identifiers for the "missing type parameters"
diagnostic in the typeck crate which was manually creating
`DiagnosticMessage`s previously.
Signed-off-by: David Wood <david.wood@huawei.com>
Adds a new `fluent_messages` macro which performs compile-time
validation of the compiler's Fluent resources (i.e. that the resources
parse and don't multiply define the same messages) and generates
constants that make using those messages in diagnostics more ergonomic.
For example, given the following invocation of the macro..
```ignore (rust)
fluent_messages! {
typeck => "./typeck.ftl",
}
```
..where `typeck.ftl` has the following contents..
```fluent
typeck-field-multiply-specified-in-initializer =
field `{$ident}` specified more than once
.label = used more than once
.label-previous-use = first use of `{$ident}`
```
...then the macro parse the Fluent resource, emitting a diagnostic if it
fails to do so, and will generate the following code:
```ignore (rust)
pub static DEFAULT_LOCALE_RESOURCES: &'static [&'static str] = &[
include_str!("./typeck.ftl"),
];
mod fluent_generated {
mod typeck {
pub const field_multiply_specified_in_initializer: DiagnosticMessage =
DiagnosticMessage::fluent("typeck-field-multiply-specified-in-initializer");
pub const field_multiply_specified_in_initializer_label_previous_use: DiagnosticMessage =
DiagnosticMessage::fluent_attr(
"typeck-field-multiply-specified-in-initializer",
"previous-use-label"
);
}
}
```
When emitting a diagnostic, the generated constants can be used as
follows:
```ignore (rust)
let mut err = sess.struct_span_err(
span,
fluent::typeck::field_multiply_specified_in_initializer
);
err.span_default_label(span);
err.span_label(
previous_use_span,
fluent::typeck::field_multiply_specified_in_initializer_label_previous_use
);
err.emit();
```
Signed-off-by: David Wood <david.wood@huawei.com>
With `ignore (rust)` rather than `ignore (pseudo-Rust)` my editor
highlights the code in the block, which is nicer.
Signed-off-by: David Wood <david.wood@huawei.com>
Previously, we were emitting weird name lints (for renamed or unknown lints)
before expansion, most importantly before cfg expansion.
This meant that the weird name lints would not fire
for lint attributes hidden inside cfg_attr. The same applied
for lint level specifications of those lints.
By moving the lints for the lint names to the post-expansion
phase, these issues are resolved.
Parse expression after `else` as a condition if followed by `{`
Fixes#49361.
Two things:
1. This wording needs help. I can never find a natural/intuitive phrasing when I write diagnostics 😅
2. Do we even want to show the "wrap in braces" case? I would assume most of the time the "add an `if`" case is the right one.
Lifetime variance fixes for rustdoc
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be unified by shortening both to some common lifetime.
This is doable, since everything is already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the rustdoc team can review independently.
Split out the various responsibilities of `rustc_metadata::Lazy`
`Lazy<T>` actually acts like three different types -- a pointer in the crate metadata to a single value, a pointer to a list/array of values, and an indexable pointer of a list of values (a table).
We currently overload `Lazy<T>` to work differently than `Lazy<[T]>` and the same for `Lazy<Table<I, T>>`. All is well with some helper adapter traits such as [`LazyQueryDecodable`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/decoder/trait.LazyQueryDecodable.html) and [`EncodeContentsForLazy`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_metadata/rmeta/encoder/trait.EncodeContentsForLazy.html).
Well, changes in #97287 that make `Lazy` work with the now invariant lifetime `'tcx` make these adapters fall apart because of coherence reasons. So we split out these three types and rework some of the helper traits so it's both 1. more clear to understand, and 2. compatible with the changes later in that PR.
Split out from #97287 so it can be reviewed separately, since this PR stands on its own.
Refactor call terminator to always include destination place
In #71117 people seemed to agree that call terminators should always have a destination place, even if the call was guaranteed to diverge. This implements that. Unsurprisingly, the diff touches a lot of code, but thankfully I had to do almost nothing interesting. The only interesting thing came up in const prop, where the stack frame having no return place was also used to indicate that the layout could not be computed (or similar). I replaced this with a ZST allocation, which should continue to do the right things.
cc `@RalfJung` `@eddyb` who were involved in the original conversation
r? rust-lang/mir-opt
Move a bunch of branches together into one if block, for easier reading.
Resolve comments
Attempt to make some branches unreachable [tmp]
Revert unreachable branches
When constructing a MIR from a THIR field expression, introduce an
additional downcast projection before accessing a field of an enum.
When rebasing a place builder on top of a captured place, account for
the fact that a single HIR enum field projection corresponds to two MIR
projection elements: a downcast element and a field element.
Lifetime variance fixes for rustc
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be unified by shortening both to some common lifetime.
This is doable, since many lifetimes are already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the compiler team can review independently.
rustdoc: shrink GenericArgs/PathSegment with boxed slices
This PR also contains a few cleanup bits and pieces, but one of them is a broken intra-doc link, and the other is removing an unused Hash impl. The last commit is the one that matters.
Remove box syntax from rustc_mir_dataflow and rustc_mir_transform
Continuation of #87781, inspired by #97239. The usages that this PR removes have not appeared from nothing, instead the usage in `rustc_mir_dataflow` and `rustc_mir_transform` was from #80522 which split up `rustc_mir`, and which was filed before I filed #87781, so it was using the state from before my PR. But it was merged after my PR was merged, so the `box_syntax` uses were able to survive here. Outside of this introduction due to the code being outside of the master branch at the point of merging of my PR, there was only one other introduction of box syntax, in #95159. That box syntax was removed again though in #95555. Outside of that, `box_syntax` has not made its reoccurrance in compiler crates.
rustc_parse: Move AST -> TokenStream conversion logic to rustc_ast
In the past falling back to reparsing pretty-printed strings was common, so some of this logic had to live in `rustc_parse`, but now the reparsing fallback is only used in two corner cases so we can move this logic to `rustc_ast` which makes many things simpler.
It also helps to fix `MacArgs::inner_tokens` for `MacArgs::Eq` with non-literal expressions, which is done in the second commit.
r? `@nnethercote`
Move the extended lifetime resolution into typeck context
Related to #15023
This PR is based on the [idea](https://github.com/rust-lang/rust/issues/15023#issuecomment-1070931433) of #15023 by `@nikomatsakis.`
This PR specifically proposes to
- Delay the resolution of scopes of rvalues to a later stage, so that enough type information is available to refine those scopes based on relationships of lifetimes.
- Highlight relevant parts that would help future reviews on the next installments of works to fully implement a solution to RFC 66.
Implement proper stability check for const impl Trait, fall back to unstable const when undeclared
Continuation of #93960
`@jhpratt` it looks to me like the test was simply not testing for the failure you were looking for? Your checks actually do the right thing for const traits?
correctly deal with user type ascriptions in pat
supersedes #93856
`thir::PatKind::AscribeUserType` previously resulted in `CanonicalUserTypeAnnotations` where the inferred type already had a subtyping relation according to `variance` to the `user_ty`.
The bug can pretty much be summarized as follows:
- during mir building
- `user_ty -> inferred_ty`: considers variance
- `StatementKind::AscribeUserType`: `inferred_ty` is the type of the place, so no variance needed
- during mir borrowck
- `user_ty -> inferred_ty`: does not consider variance
- `StatementKind::AscribeUserType`: applies variance
This mostly worked fine. The lifetimes in `inferred_ty` were only bound by its relation to `user_ty` and to the `place` of `StatementKind::AscribeUserType`, so it doesn't matter where exactly the subtyping happens.
It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors.
cc #96514 which is pretty much the same issue
r? `@nikomatsakis`
Remove `crate` visibility modifier
FCP to remove this syntax is just about complete in #53120. Once it completes, this should be merged ASAP to avoid merge conflicts.
The first two commits remove usage of the feature in this repository, while the last removes the feature itself.
Drop Tracking: Implement `fake_read` callback
This PR updates drop tracking's use of `ExprUseVisitor` so that we treat `fake_read` events as borrows. Without doing this, we were not handling match expressions correctly, which showed up as a breakage in the `addassign-yield.rs` test. We did not previously notice this because we still had rather large temporary scopes that we held borrows for, which changed in #94309.
This PR also includes a variant of the `addassign-yield.rs` test case to make sure we continue to have correct behavior here with drop tracking.
r? `@nikomatsakis`
Cache more queries on disk
One of the principles of incremental compilation is to allow saving results on disk to avoid recomputing them.
This PR investigates persisting a lot of queries whose result are to be saved into metadata.
Some of the queries are cheap reads from HIR, but we may also want to get rid of these reads for incremental lowering.
Do not emit the lint `unused_attributes` for *inherent* `#[doc(hidden)]` associated items
Fixes#97205 (embarrassing oversight from #96008).
`@rustbot` label A-lint
Rollup of 6 pull requests
Successful merges:
- #96565 (rustdoc: show implementations on `#[fundamental]` wrappers)
- #97179 (Add new lint to enforce whitespace after keywords)
- #97185 (interpret/validity: separately control checking numbers for being init and non-ptr)
- #97188 (Remove unneeded null pointer asserts in ptr2int casts)
- #97189 (Update .mailmap)
- #97192 (Say "last" instead of "rightmost" in the documentation for `std::str:rfind`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove unneeded null pointer asserts in ptr2int casts
This removes an assert that a pointer with address 0 has no provenance. This change is needed to support permissive provenance work in Miri, and seems justified by `ptr.with_addr(0)` working and a discussion on Zulip regarding LLVM semantics.
r? `@RalfJung`
interpret/validity: separately control checking numbers for being init and non-ptr
This lets Miri control this in a more fine-grained way.
r? `@oli-obk`
generator_interior: Count match pattern bindings as borrowed for the whole guard expression
The test case `yielding-in-match-guard.rs` was failing with `-Zdrop-tracking` enabled. The reason is that the copy of a local (`y`) was not counted as a borrow in typeck, while MIR did consider this as borrowed.
The correct thing to do here is to count pattern bindings are borrowed for the whole guard. Instead, what we were doing is to record the type at the use site of the variable and check if the variable comes from a borrowed pattern. Due to the fix for #57017, we were considering too small of a scope for this variable, which meant it was not counted as borrowed.
Because we now unconditionally record the borrow, rather than only for bindings that are used, this PR is also able to remove a lot of the logic around match bindings that was there before.
r? `@nikomatsakis`
move processing of `source_scope_data` into `MutVisitor`'s impl of `Integrator` when inline
This PR fixes the FIXME in the inline mir-opt which moves processing of `source_scope_data` into `MutVisitor`'s impl of `Integrator` when inline
`simplify_type` improvements and cursed docs
the existing `TreatParams` enum pretty much mixes everything up. Not sure why this looked right to me in #94057
This also includes two changes which impact perf:
- `ty::Projection` with inference vars shouldn't be treated as a rigid type, even if fully normalized
- `ty::Placeholder` only unifies with itself, so actually return `Some` for them
r? `@nikomatsakis`
This alters the diagnostics a bit, as the trait method is still stable.
The only thing this check does is ensure that compilation fails if a
trait implementation is declared const-stable.
Rather than deferring to const eval for checking if a trait is const, we
now check up-front. This allows the error to be emitted earlier, notably
at the same time as other stability checks.
Also included in this commit is a change of the default const stability
level to UNstable. Previously, an item that was `const` but did not
explicitly state it was unstable was implicitly stable.
Permit `asm_const` and `asm_sym` to reference generic params
Related #96557
These constructs will be allowed:
```rust
fn foofoo<const N: usize>() {}
unsafe fn foo<const N: usize>() {
asm!("/* {0} */", const N);
asm!("/* {0} */", const N + 1);
asm!("/* {0} */", sym foofoo::<N>);
}
fn barbar<T>() {}
unsafe fn bar<T>() {
asm!("/* {0} */", const std::mem::size_of::<T>());
asm!("/* {0} */", const std::mem::size_of::<(T, T)>());
asm!("/* {0} */", sym barbar::<T>);
asm!("/* {0} */", sym barbar::<(T, T)>);
}
```
`@Amanieu,` I didn't switch inline asms to use `DefKind::InlineAsm`, as I see little value doing that; given that no type inference is needed, it will only make typecking slower and more complex but will have no real gains. I did switch them to follow the same code path as inline asm during symbol resolution, though.
The `error: unconstrained generic constant` you mentioned in #76001 is due to the fact that `to_const` will actually add a wfness obligation to the constant, which we don't need for `asm_const`, so I have that removed.
`@rustbot` label: +A-inline-assembly +F-asm
--remap-path-prefix: Fix duplicated path components in debuginfo
This PR fixes an issue with `--remap-path-prefix` where path components could appear twice in the remapped version of the path (e.g. https://github.com/rust-lang/rust/issues/78479). The underlying problem was that `--remap-path-prefix` is often used to map an absolute path to something that looks like a relative path, e.g.:
```
--remap-path-prefix=/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823=crates.io",
```
and relative paths in debuginfo are interpreted as being relative to the compilation directory. So if Cargo invokes the compiler with `/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823/some_crate-0.1.0/src/lib.rs` as input and `/home/calvin/.cargo/registry/src/github.com-1ecc6299db9ec823/some_crate-0.1.0` as the compiler's working directory, then debuginfo will state that the working directory was `crates.io/some_crate-0.1.0` and the file is question was `crates.io/some_crate-0.1.0/src/lib.rs`, which combined gives the path:
```
crates.io/some_crate-0.1.0/crates.io/some_crate-0.1.0/src/lib.rs
```
With this PR the compiler will detect this situation and set up debuginfo in LLVM in a way that makes it strip the duplicated path components when emitting DWARF.
The PR also extracts the logic for making remapped paths absolute into a common helper function that is now used by debuginfo too (instead of just during crate metadata generation).
Clean fix for #96223
Okay, so here we are (hopefully) 👍Closes#96223
Thanks a lot to `@jackh726` for your help and explanation 🙏
- Modified `InferCtxt::mk_trait_obligation_with_new_self_ty` to take as argument a `Binder<(TraitPredicate, Ty)>` instead of a `Binder<TraitPredicate>` and a separate `Ty` with no bound vars.
- Modified all call places to avoid calling `Binder::no_bounds_var` or `Binder::skip_binder` when it is not safe.
r? `@jackh726`
Mention traits and types involved in unstable trait upcasting
Fixes#95972 by printing the traits being upcasted and the types being coerced that cause that upcasting...
---
the poor span mentioned in the original issue has nothing to do with trait upcasting diagnostic here...
> The original example I had that made me run into this issue had an even longer expression there (multiple chained
iterator methods) which just got all highlighted as one big block saying "somewhere here trait coercion is used and it's not allowed".
I don't think I can solve that issue in general without fixing the ObligationCauseCode and span that gets passed into Coerce.
Suggest dereferencing non-lval mutable reference on assignment
1. Adds deref suggestions for LHS of assignment (or assign-binop) when it implements `DerefMut`
2. Fixes missing deref suggestions for LHS when it isn't a place expr
Fixes#46276Fixes#93980
interpret/validity: reject references to uninhabited types
According to https://doc.rust-lang.org/reference/behavior-considered-undefined.html, this is definitely UB. And we can check this without actually looking up anything in memory, we just need the reference value and its type, making this a great candidate for a validity invariant IMO and my favorite resolution of https://github.com/rust-lang/unsafe-code-guidelines/issues/77.
With this PR, Miri with `-Zmiri-check-number-validity` implements all my preferred options for what the validity invariants of our types could be. :)
CTFE has been doing recursive checking anyway, so this is backwards compatible but might change the error output. I will submit a PR with the new Miri tests soon.
r? `@oli-obk`
Add tmm_reg clobbers
This adds support for naming the 8 tile registers from intel AMX as clobbers from `asm!` invocations on x86_64 (only). It does not add the registers as input or output operands.
- Modified `InferCtxt::mk_trait_obligation_with_new_self_ty` to take as
argument a `Binder<(TraitPredicate, Ty)>` instead of a
`Binder<TraitPredicate>` and a separate `Ty` with no bound vars.
- Modified all call places to avoid calling `Binder::no_bounds_var` or
`Binder::skip_binder` when it is not safe.
Prevent unwinding when `-C panic=abort` is used regardless declared ABI
Ensures that Rust code will abort with `-C panic=abort` regardless ABI used.
```rust
extern "C-unwind" {
fn may_unwind();
}
// Will be nounwind with `-C panic=abort`, despite `C-unwind` ABI.
pub unsafe extern "C-unwind" fn rust_item_that_can_unwind() {
may_unwind();
}
```
Current behaviour is that unwind will propagate through. While the current behaviour won't cause unsoundness it is inconsistent with the text reading of [RFC2945](https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html).
I tweaked `fn_can_unwind` instead of tweaking `AbortUnwindingCalls` because this approach would allow Rust (non-direct) callers to also see that this function is nounwind, so it can prevent excessive landing pads generation.
For more discussions: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/soundness.20in.20mixed.20panic.20mode.
cc `@alexcrichton,` `@BatmanAoD`
r? `@Amanieu`
`@rustbot` label: T-compiler T-lang F-c_unwind
Change `Successors` to `impl Iterator<Item = BasicBlock>`
This PR fixes the FIXME in `compiler\rustc_middle\src\mir\mod.rs`.
This can omit several `&`, `*` or `cloned` operations on Successros' generated elements
Add a query for checking whether a function is an intrinsic.
work towards #93145
This will reduce churn when we add more ways to declare intrinsics
r? `@scottmcm`
Sync rustc_codegen_cranelift
Since the last sync there have mostly been fixes of various sorts. I also changed cg_clif from using a custom driver to `-Zcodegen-backend` when built as separate project. When built as part of rust it was already using `-Zcodegen-backend`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
rustc: Stricter checking for #[link] attributes
A subset of https://github.com/rust-lang/rust/pull/94962 that doesn't touch library renaming/reordering/deduplication.
`#[link]` attributes are checked for all kinds of unexpected arguments inside them.
I also tried to make wording for these errors more consistent, that's why some existing errors are changed, including errors for command line `-l` options.
Spans are also made more precise where possible.
Allow the unused_macro_rules lint for now
It was newly added by #96150 with warn by default, which is great as it gave exposure to the community, and their feedback gave me ideas for improvements.
Allowing the lint is good for two reasons:
* It makes the transition easier as e.g. allow directives won't fire the unknown lint warning once it is turned to warn by default in the future. The [commit that allowed the lint in fuchsia](https://fuchsia.googlesource.com/fuchsia/+/9d8f96517c3963de2f0e25598fd36061914524cd%5E%21/) had to allow unknown lints for example.
This is especially important compared to other lints in the unused group,
because the _ prefix trick doesn't exist for macro rules, allowing is the
only option (either of unused_macro_rules, or of the entire unused group,
but that is not as informative to readers). Allowing the lint also makes it
possible to work on possible heuristics for disabling the macro in specific
cases.
* It gives time for implementing heuristics for when to suppress the lint, e.g.
when `compile_error!` is invoked by that arm (so it's only there to yield an error).
See: https://github.com/rust-lang/rust/pull/96150#issuecomment-1126599107
I would also like this to be backported to the 1.62 beta branch (cc #97016).
Add EarlyBinder
Chalk has no concept of `Param` (e0ade19d13/chalk-ir/src/lib.rs (L579)) or `ReEarlyBound` (e0ade19d13/chalk-ir/src/lib.rs (L1308)). Everything is just "bound" - the equivalent of rustc's late-bound. It's not completely clear yet whether to move everything to the same time of binder in rustc or add `Param` and `ReEarlyBound` in Chalk.
Either way, tracking when we have or haven't already substituted out these in rustc can be helpful.
As a first step, I'm just adding a `EarlyBinder` newtype that is required to call `subst`. I also add a couple "transparent" `bound_*` wrappers around a couple query that are often immediately substituted.
r? `@nikomatsakis`
Initial work on Miri permissive-exposed-provenance
Rustc portion of the changes for portions of a permissive ptr-to-int model for Miri. The main changes here are changing `ptr_get_alloc` and `get_alloc_id` to return an Option, and also making ptr-to-int casts have an expose side effect.
This makes the transition easier as e.g. allow directives
won't fire the unknown lint warning once it is turned to
warn by default in the future. This is especially
important compared to other lints in the unused group
because the _ prefix trick doesn't exist for macro rules,
so allowing is the only option (either of unused_macro_rules,
or of the entire unused group, but that is not as informative
to readers). Allowing the lint also makes it possible to work
on possible heuristics for disabling the macro in specific
cases.
