| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unify `CoroutineWitness` sooner in typeck, and stall coroutine obligations based off of `TypingEnv`
* Stall coroutine obligations based off of `TypingMode` in the old solver.
* Eagerly assign `TyKind::CoroutineWitness` to the witness arg of coroutines during typeck, rather than deferring them to the end of typeck.
r? lcnr
This is part of https://github.com/rust-lang/rust/issues/143017.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
parse `const trait Trait`
r? oli-obk or anyone from project-const-traits
cc `@rust-lang/project-const-traits`
|
|
Also make it *only* usable on nightly
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#143326 (Remove deprecated `Error::description` impl from `c_str::FromBytesWithNulError`)
- rust-lang/rust#143431 (Use relative visibility when noting sealed trait to reduce false positive)
- rust-lang/rust#143550 (resolve: Use interior mutability for extern module map)
- rust-lang/rust#143631 (update to literal-escaper-0.0.5)
- rust-lang/rust#143793 (Opaque type collection: Guard against endlessly recursing free alias types)
- rust-lang/rust#143880 (tests: Test line debuginfo for linebreaked function parameters)
- rust-lang/rust#143914 (Reword mismatched-lifetime-syntaxes text based on feedback)
- rust-lang/rust#143926 (Remove deprecated fields in bootstrap)
- rust-lang/rust#143955 (Make frame spans appear on a separate trace line)
- rust-lang/rust#143975 (type_id_eq: check that the hash fully matches the type)
- rust-lang/rust#143984 (Fix ice for feature-gated `cfg` attributes applied to the crate)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
the same name from different traits
|
|
|
|
Fix ice for feature-gated `cfg` attributes applied to the crate
This PR fixes two fixes:
1. When a feature gated option of the `cfg` attribute is applied to the crate, an ICE would occur because features are not yet available at that stage. This is fixed by ignoring the feature gate at that point, the attribute will later be re-checked (this was already done) when the feature gate is available. Fixes https://github.com/rust-lang/rust/issues/143977
2. Errors and lints on the `cfg` attribute applied to the crate would be produced twice, because of the re-checking. This is fixed by not producing any errors and lints during the first run.
The added regression test checks both problems.
r? ``@jdonszelmann``
|
|
type_id_eq: check that the hash fully matches the type
The previous logic wouldn't always detect when the hash mismatches the provenance. Fix that by adding a new helper, `read_type_id`, that reads a single type ID while fully checking it for validity and consistency.
r? ``@oli-obk``
|
|
Make frame spans appear on a separate trace line
This PR changes tracing_chrome's `tracing::Layer` so that if a span has the "tracing_separate_line" field as one of the span arguments, that span is put on a separate trace line. See https://github.com/rust-lang/miri/pull/4451 for an earlier attempt and for screenshots explaining better what I mean by "separate trace line".
This PR also makes the "frame" span use this feature (so it appears on a separate trace line, see https://github.com/rust-lang/miri/pull/4451 for motivation), but passes `tracing::field::Empty` as the span parameter value so it is ignored by other tracing layers (e.g. the logger):
```rust
info_span!("frame", tracing_separate_line = Empty, "{}", instance);
```
<details><summary>Also see the following discussion I had with ``@RalfJung</summary>``
> Is there no way to attach metadata we could use instead?
[These](https://docs.rs/tracing-core/0.1.34/src/tracing_core/metadata.rs.html#57) are the **static** metadata items we can control about a span. We can't add more metadata outside of them. The most relevant are:
- `name` (for the frame span it's currently "frame")
- `target` which acts as the category (for the frame span it's currently "rustc_const_eval::interpret::stack" by default)
- `fields` which contains a list of the *names* of each of the arguments passed to the `span!` macro (for the frame span it's currently ["message"], where "message" is the default identifier for data passed in the `format!` syntax)
When the tracing code is called at runtime, the **dynamic** values of the arguments are collected into a [`ValueSet`](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#166). Each argument value stored there corresponds with one of the static names stored in `fields` (see above).
---
We have already determined that filtering out spans by `name` is not a good idea, and I would say the same goes for `target`. Both the `name` and the `target` fields are printed to stderr when `MIRI_LOG=` is enabled, so changing them to contain an identifier (e.g. "frame:tracing_separate_root" instead of "frame" as the name) would uselessly clutter the text logs (unless we add one more filter [there](https://github.com/rust-lang/rust/blob/master/compiler/rustc_log/src/lib.rs#L137), but then it gets even more complicated).
```rust
// examples of how the above (problematic) solutions would look like
info_span!("frame:tracing_separate_root", "{}", instance);
info_span!(target: "tracing_separate_root", "frame", "{}", instance);
```
---
So that leaves us with `fields` and their runtime values. Now, my initial thought (inspired by [this comment](https://github.com/rust-lang/miri/pull/4451#issuecomment-3068072303)) was to use a field with the static name "tracing_separate_root" and with a dynamic boolean value of "true". In `tracing_chrome.rs` we can easily check if this field is true and act accordingly. This would work but then again this field would also be picked up by the logger when `MIRI_LOG=` is enabled, and would uselessly clutter the text logs.
```rust
// example of how the above (problematic) solution would look like
info_span!("frame", tracing_separate_root = true, "{}", instance);
```
---
To avoid cluttering the text logs, we can instead set "tracing_separate_root" to the dynamic value of `tracing::field::Empty`. Citing from [here](https://docs.rs/tracing/0.1.41/tracing/field/struct.Empty.html), "when a field’s value is `Empty`, it will not be recorded". "not being recorded" means that the field and its value won't be printed to stderr text logs, nor will it be printed by any other tracing layers that might be attached in the future. In `tracing_chrome.rs` we would still be able to check if "tracing_separate_root" is in the list of static `fields`, and act accordingly. So I believe this solution would effectively allow us to attach metadata to a span in a way that does not clutter logs and still allows being read in `tracing_chrome.rs`.
If we ever wanted to pass arbitrary metadata (i.e. not just a present/not present flag), it would be possible with a custom `Empty` that also holds data and implement `Value` without doing anything ([like `Empty` does](https://docs.rs/tracing-core/0.1.34/src/tracing_core/field.rs.html#775)).
```rust
// example of how the above solution would look like
info_span!("frame", tracing_separate_root = tracing::field::Empty, "{}", instance);
```
</details>
|
|
r=traviscross,jieyouxu
Reword mismatched-lifetime-syntaxes text based on feedback
Key changes include:
- Removal of the word "syntax" from the lint message. More accurately, it could have been something like "syntax group" or "syntax category", but avoiding it completely is easier.
- The primary lint message now reflects exactly which mismatch is occurring, instead of trying to be general. A new `help` line is general across the mismatch kinds.
- Suggestions have been reduced to be more minimal, no longer also changing non-idiomatic but unrelated aspects.
- Suggestion text no longer mentions changes when those changes don't occur in that specific suggestion.
r? ``@jieyouxu``
|
|
Opaque type collection: Guard against endlessly recursing free alias types
See test description for technical details.
Fixes https://github.com/rust-lang/rust/issues/131994.
r? oli-obk (sry, your queue is large, so no rush & feel free to reassign)
|
|
update to literal-escaper-0.0.5
Quoting from the changelog, this version brings:
- Use `NonZero<char/u8>` in `unescape_c_str` and `check_raw_c_str` to statically exclude nuls
- Add `#[inline]` to small functions for improved performance
|
|
resolve: Use interior mutability for extern module map
Module map for extern modules is a lazily populated cache, it's not *significantly* mutable.
If some logic in name resolver is parallelized, then this cache can be populated from any thread, and without affecting results of any speculative resolution.
Unblocks https://github.com/rust-lang/rust/pull/143884.
This is a part of [#gsoc > Project: Parallel Macro Expansion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Parallel.20Macro.20Expansion/with/527348747).
cc `@LorrensP-2158466`
|
|
Use relative visibility when noting sealed trait to reduce false positive
Fixes rust-lang/rust#143392
I used relative visibility instead of just determining if it's public or not.
r? compiler
|
|
Only inherit local hash for paths
`DefPathHash`, as the counterpart of `DefId` that is stable across compiler invocations, is comprised of 2 parts. The first one is the `StableCrateId`, stable form of `CrateNum`. The second is 64 complementary bits to identify the crate-local definition.
The current implementation always hashes the full 128 bits when (1) trying to create a new child `DefPathHash` or (2) hashing a `CrateNum` or a `LocalDefId`. But we only need half that information: `LocalDefId` means that the `StableCrateId` is always the current crate's ; `CrateNum` means that we do not care about the local part.
As stable hashing is very hot in the query system, in particular hashing definitions, this is a big deal.
We still want the local part to change when the `StableCrateId` changes, to make incr-compilation errors less painful, ie. increase the likelihood that if will magically disappear by changing some code.
This PR sprinkles some `#[inline]` attributes on small functions that appeared in profiles.
|
|
|
|
|
|
Rollup of 15 pull requests
Successful merges:
- rust-lang/rust#142304 (tests: Add `RUST_BACKTRACE` and `-Cpanic` revisions to `panic-main.rs` test)
- rust-lang/rust#143388 (Various refactors to the LTO handling code)
- rust-lang/rust#143409 (Enable xgot feature for mips64 musl targets)
- rust-lang/rust#143592 (UWP: link ntdll functions using raw-dylib)
- rust-lang/rust#143595 (add `const_make_global`; err for `const_allocate` ptrs if didn't call)
- rust-lang/rust#143678 (Added error for invalid char cast)
- rust-lang/rust#143820 (Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets)
- rust-lang/rust#143829 (Trim `BorrowedCursor` API)
- rust-lang/rust#143851 (ci cleanup: rustdoc-gui-test now installs browser-ui-test)
- rust-lang/rust#143856 (Linting public reexport of private dependencies)
- rust-lang/rust#143895 (Dont collect assoc ty item bounds from trait where clause for host effect predicates)
- rust-lang/rust#143922 (Improve path segment joining)
- rust-lang/rust#143964 (Fix handling of SCRIPT_ARG in docker images)
- rust-lang/rust#144002 (Update poison.rs)
- rust-lang/rust#144016 (trait_sel: `MetaSized` always holds temporarily)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
trait_sel: `MetaSized` always holds temporarily
As a temporary measure while a proper fix for `tests/ui/sized-hierarchy/incomplete-inference-issue-143992.rs` is implemented, make `MetaSized` obligations always hold. In effect, temporarily reverting the `sized_hierarchy` feature. This is a small change that can be backported.
cc rust-lang/rust#143992
r? ```@lcnr```
|
|
Improve path segment joining
Currently paths are joined with `::` in many places, in a variety of ways. This PR unifies things.
r? ``@petrochenkov``
|
|
r=oli-obk
Dont collect assoc ty item bounds from trait where clause for host effect predicates
For background, we uplift `where Self::Assoc: Trait` bounds in a trait's where clauses into *item bounds* on `type Assoc;`. This is because before we *had* syntactical item bounds, users would express their item bounds like so.
Let's opt out of doing this same behavior for `HostEffect` predicates like `where Self::Assoc: [const] Trait`. I left a comment in the code:
```rust
// FIXME(const_trait_impl): We *could* uplift the
// `where Self::Assoc: [const] Trait` bounds from the parent trait
// here too, but we'd need to split `const_conditions` into two
// queries (like we do for `trait_explicit_predicates_and_bounds`)
// since we need to also filter the predicates *out* of the const
// conditions or they lead to cycles in the trait solver when
// utilizing these bounds. For now, let's do nothing.
```
As an aside, this was an ICE that was only triggerable when building libraries and not binaries because we never were calling `tcx.ensure_ok().explicit_implied_const_bounds(def_id);` on associated types like we should have been. I adjusted the calls to `ensure_ok` to make sure this happens, so we catch bugs like this in the future more easily.
As another aside, I fixed the bound uplifting logic for *always const* predicates, since those act like normal clauses and have no notion of conditional constness.
r? ```@oli-obk``` ```@fee1-dead``` or anyone really
Fixes rust-lang/rust#133275
|
|
Linting public reexport of private dependencies
Part of public/private dependencies rust-lang/rust#44663
Partially addresses rust-lang/rust#71043
I'm adding a warning for reexports of private dependencies into `rustc_resolve`. I get that this should not be a warning, but should instead be a lint to be controlled by the feature gate, but I did not figure out how exactly to do that at that point. I tried doing the same thing as is done in `rustc_privacy`, but the linting system is not ready yet as far as I understand the error I got, so I made a warning for now instead. Some guidance on how to emit lints with `dcx` would be appreciated.
This also sets the `std_detect` crate as a public dependency of `std` because some macros are reexported from there. I did not check closer, but the other option may be to allow the specific reexports instead.
|
|
Added error for invalid char cast
fixes rust-lang/rust#143597
not really sure if I did it right, but according to cast-char test -- it is right, also this code gave me false positive result
```
for _ in 0..(256 as u8) {}
```
so this is why I added this check `if lit_val <= 0xFF`
Also I believe that error message could be improved, but I'm not sure how exactly
cc ```@hkBst```
r? compiler
|
|
r=RalfJung,fee1-dead
add `const_make_global`; err for `const_allocate` ptrs if didn't call
Implements as discussed on Zulip: [#t-compiler/const-eval > const heap](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const.20heap/with/527125421)
r? ```@rust-lang/wg-const-eval```
Fixes https://github.com/rust-lang/rust/issues/129233
|
|
Enable xgot feature for mips64 musl targets
This was missed in b65c2afdfd9aaee977302516c9ef177861abfe74, which only enabled it for the glibc targets.
I didn't feel comfortable touching the OpenWRT target, whoever maintains that will probably want to take a look whether it is necessary there as well.
|
|
Various refactors to the LTO handling code
In particular reducing the sharing of code paths between fat and thin-LTO and making the fat LTO implementation more self-contained. This also moves some autodiff handling out of cg_ssa into cg_llvm given that Enzyme only works with LLVM anyway and an implementation for another backend may do things entirely differently. This will also make it a bit easier to split LTO handling out of the coordinator thread main loop into a separate loop, which should reduce the complexity of the coordinator thread.
|
|
Implement unstable trait impl
This PR allows marking impls of stable trait with stable type as unstable.
## Approach
In std/core, an impl can be marked as unstable by annotating it with ``#[unstable_feature_bound(feat_name)]``. This will add a ``ClauseKind::Unstable_Feature(feat_name)`` to the list of predicates in ``predicates_of`` .
When an unstable impl's function is called, we will first iterate through all the goals in ``param_env`` to check if there is any ``ClauseKind::UnstableFeature(feat_name)`` in ``param_env``.
The existence of ``ClauseKind::Unstable_Feature(feat_name)`` in ``param_env`` means an``#[unstable_feature_bound(feat_name)]`` is present at the call site of the function, so we allow the check to succeed in this case.
If ``ClauseKind::UnstableFeature(feat_name)`` does not exist in ``param_env``, we will still allow the check to succeed for either of the cases below:
1. The feature is enabled through ``#[feature(feat_name)]`` outside of std / core.
2. We are in codegen because we may be monomorphizing a body from an upstream crate which had an unstable feature enabled that the downstream crate do not.
For the rest of the case, it will fail with ambiguity.
## Limitation
In this PR, we do not support:
1. using items that need ``#[unstable_feature_bound]`` within stable APIs
2. annotate main function with ``#[unstable_feature_bound]``
3. annotate ``#[unstable_feature_bound]`` on items other than free function and impl
## Acknowledgement
The design and mentoring are done by `@BoxyUwU`
|
|
|
