Create UTF-8 version of `OsStr`/`OsString`
Implement a UTF-8 version of `OsStr`/`OsString`, in addition to the existing bytes and WTF-8 platform-dependent encodings.
This is applicable for several platforms, but I've currently only implemented it for Motor OS:
- WASI uses Unicode paths, but currently reexports the Unix bytes-assuming `OsStrExt`/`OsStringExt` traits.
- [wasi:filesystem](https://wa.dev/wasi:filesystem) APIs:
> Paths are passed as interface-type `strings`, meaning they must consist of a sequence of Unicode Scalar Values (USVs). Some filesystems may contain paths which are not accessible by this API.
- In [wasi-filesystem#17](https://github.com/WebAssembly/wasi-filesystem/issues/17#issuecomment-1430639353), it was decided that applications can use any Unicode transformation format, so we're free to use UTF-8 (and probably already do). This was chosen over specifically UTF-8 or an ad hoc encoding which preserves paths not representable in UTF-8.
> The current API uses strings for filesystem paths, which contains sequences of Unicode scalar values (USVs), which applications can work with using strings encoded in UTF-8, UTF-16, or other Unicode encodings.
>
> This does mean that the API is unable to open files which do not have well-formed Unicode encodings, which may want separate APIs for handling such paths or may want something like the arf-strings proposal, but if we need that we should file a new issue for it.
- As of Redox OS [0.7.0](https://www.redox-os.org/news/release-0.7.0/), "All paths are now required to be UTF-8, and the kernel enforces this". This appears to have been implemented in commit [d331f72f](d331f72f2a) (Use UTF-8 for all paths, 2021-02-14). Redox does not have `OsStrExt`/`OsStringExt`.
- Motor OS guarantees that its OS strings are UTF-8 in its [current `OsStrExt`/`OsStringExt` traits](a828ffcf5f/library/std/src/os/motor/ffi.rs), but they're still internally bytes like Unix.
This is an alternate approach to https://github.com/rust-lang/rust/pull/147797, which reuses the existing bytes `OsString` and relies on the safety properties of `from_encoded_bytes_unchecked`. Compared to that, this also gains efficiency from propagating the UTF-8 invariant to the whole type, as it never needs to test for UTF-8 validity.
Note that Motor OS currently does not build until https://github.com/rust-lang/rust/pull/147930 merges.
cc `@tgross35` (for earlier review)
cc `@alexcrichton,` `@rylev,` `@loganek` (for WASI)
cc `@lasiotus` (for Motor OS)
cc `@jackpot51` (for Redox OS)
Code refactoring on hir report_no_match_method_error
While working on rust-lang/rust#147753, I found `report_no_match_method_error` now is too long for maintain, 1200 lines of code now:
57ef8d642d/compiler/rustc_hir_typeck/src/method/suggest.rs (L589-L1736)
this PR try to refactor it.
I tried my best to group most related code into same places, but the logic here is still very complex, there are some variables across different functions, maybe we need more work to make it better understand.
Maybe we could add a tidy check to avoid long spaghetti code.
r? `@nnethercote`
Add NonNull pattern types
These are the final piece missing for
* https://github.com/rust-lang/rust/pull/136006
We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns
r? `@BoxyUwU`
Add `FromIterator` impls for `ascii::Char`s to `String`s
Wanted to `collect` ascii chars into a `String` while working on #141369 , and was surprised these impls don't exist. Seems to me to be simply oversight.
BTW, I only added `impl FromIterator<ascii::Char> for Cow<'_, str>`, without a corresponding `FromIterator<&Char>` impl, because there's no existing impl for `FromIterator<&char>`, but that might be oversight too.
cc #110998
`-Znext-solver` instantiate predicate binder without recanonicalizing goal
This strengthens the leak check to match the old trait solver. The new trait solver now also instantiates higher ranked goals in the same scope as candidate selection, so the leak check in each candidate detects placeholder errors involving this higher ranked goal.
E.g. let's look at tests/ui/higher-ranked/leak-check/leak-check-in-selection-2.rs
```rust
trait Trait<T, U> {}
impl<'a> Trait<&'a str, &'a str> for () {}
impl<'a> Trait<&'a str, String> for () {}
fn impls_trait<T: for<'a> Trait<&'a str, U>, U>() {}
fn main() {
impls_trait::<(), _>();
}
```
Here proving `(): for<'a> Trait<&'a str, ?u>` via `impl<'a> Trait<&'a str, &'a str> for ()` equates `?u` with `&'!a str` which results in a leak check error as `?u` cannot name `'a`. If this leak check error happens while considering candidates we drop the first impl and infer `?u` to `String`. If not, this remains ambiguous.
This behavior is a bit iffy, see the FCP proposal in rust-lang/rust#119820 for more details on why this current behavior is somewhat undesirable. However, considering placeholders from higher-ranked goals for candidate selection does allow more code to compile and a lot of the code *feels like it should compile*. **This caused us to revert the change of rust-lang/rust#119820 in rust-lang/rust#127568.**
I originally expected that we can avoid breakage with the new solver differently here, e.g. by considering OR-region constraints. However, doing so is a significant change and I don't have a great idea for how that should work. Matching the old solver behavior for now should not make this cleaner approach any more difficult in the future, so let's just go with what actually allows us to stabilize the new solver for now.
This PR changing the new solver to match the behavior of the old one wrt the leak check. As the new solver is already used by default in coherence, this allows more code to compile, see `tests/ui/higher-ranked/leak-check/leak-check-in-selection-7-coherence.rs`:
```rust
struct W<T, U>(T, U);
trait Trait<T> {}
// using this impl results in a higher-ranked region error.
impl<'a> Trait<W<&'a str, &'a str>> for () {}
impl<'a> Trait<W<&'a str, String>> for () {}
trait NotString {}
impl NotString for &str {}
impl NotString for u32 {}
trait Overlap<U> {}
impl<T: for<'a> Trait<W<&'a str, U>>, U> Overlap<U> for T {}
impl<U: NotString> Overlap<U> for () {}
fn main() {}
```
This behavior is quite arbitrary and not something I expect users to rely on in practice, however, it should still go through an FCP imo.
r? `@BoxyUwU` originally implemented by `@compiler-errors` in https://github.com/rust-lang/rust/pull/136997. Closes https://github.com/rust-lang/trait-system-refactor-initiative/issues/120.
compiletest: More directive handling tweaks
- Follow-up to rust-lang/rust#147903.
---
These are some more preparatory changes that were extracted from a larger overhaul of directive handling that I'm still working on.
---
The revision check was introduced by rust-lang/rust#61778, and later modified by rust-lang/rust#113603. It doesn't appear to be doing anything particularly load-bearing (since a bogus mode seems to cause a panic later anyway), and getting rid of it avoids the need to pass the current test revision to directive-handling code.
- rust-lang/rust#61778
- rust-lang/rust#113603
r? jieyouxu
compiletest: Don't set `TARGET` for non run-make tests
There are a few tests that were using `TARGET` to quietly do nothing on `i586` targets, but it's cleaner to just add support for `//@ ignore-i586` instead.
This lets us get rid of an unsafe `env::set_var` in compiletest, which really should have been setting the environment variable on individual build/run subprocess commands anyway.
- The original code and tests were introduced way back in rust-lang/rust#39068
Add a test for the cold attribute
This adds a test for the cold attribute to verify that it actually does something, and that it applies correctly in all the positions it is expected to work.
If something like this is needed again in the future, please set environment
variables for the build and run subprocesses, instead of setting them on the
compiletest process.
There are a few tests that were trying to skip i586 targets via the `TARGET`
environment variable instead, so better to just add support for the directive.
move `once` module out of `poison`
From https://github.com/rust-lang/rust/issues/134645#issuecomment-3324577500, since `Once` will not have a non-poisoning variant, we remove it from the `poison` module.
Additionally:
1. Renames `once::ExclusiveState` to `OnceExclusiveState` since it was a bit confusing reading just `ExclusiveState` where it is used.
2. Reorders a few module definitions and re-exports in `library/std/src/sync/mod.rs` for clarity.
Also, once this is merged, I think that we can begin the process of stabilizing [`sync_poison_mod`](https://github.com/rust-lang/rust/issues/134646)
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#147577 (Improve error message for ambiguous numeric types in closure parameters)
- rust-lang/rust#147785 (fix incorrect line number when building trimmed multi-line suggestions)
- rust-lang/rust#147814 (btree: some cleanup with less unsafe)
- rust-lang/rust#147843 (Change the tidy license checker)
r? `@ghost`
`@rustbot` modify labels: rollup
Change the tidy license checker
This adds a bunch of licenses to the global list of allowed licenses that are at least as permissive as some other license in the list. In addition it adds another list for licenses that are allowed to be used by tools, but not by the runtime. All permissive licenses from the exception lists are added here. This makes it clearer what actual exceptions to our permissive licensing policy are and will hopefully make it a bit easier to review future changes to the list of licenses rather than just adding whatever license is necessary to the global list of allowed licenses or to the list of exceptions.
fix incorrect line number when building trimmed multi-line suggestions
While fixing the issue https://github.com/rust-lang/rust-clippy/issues/15883 from `rust-clippy`, I tracked it down to a problem in `rustc` where line numbers were incorrect when building trimmed multi-line suggestions.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#147734 (Further tighten up relaxed bounds)
- rust-lang/rust#147888 (enzyme/autodiff is compatible with download-ci=true)
- rust-lang/rust#147898 (compiletest: Move `AuxProps` out of `EarlyProps`)
- rust-lang/rust#147903 (compiletest: Store the selected edition in `TestProps`)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Store the selected edition in `TestProps`
While working on a larger overhaul of directive processing, I ran into difficulty with the `has_edition` local variable.
Storing the selected edition in `TestProps` should make it easier to extract parts of directive processing into independent handler functions, because the `//@ edition` handler won't need access to additional mutable state outside of `TestProps`.
We still automatically add the edition to `compile_flags`, because there is too much existing compiletest code relying on that behaviour.
r? jieyouxu
compiletest: Move `AuxProps` out of `EarlyProps`
The primary purpose of `EarlyProps` is to discover revisions, so that we can create a separate test structure for each revision.
Revisions can (and do) have different auxiliaries, and up-to-date checking is already done per-revision, so it makes more sense to perform up-to-date checks based on the current revisions's auxiliaries only.
r? jieyouxu
enzyme/autodiff is compatible with download-ci=true
To my surprise autodiff just works out of the box with download-ci=true. Thanks to all the bootstrap people who over the past helped me to link properly against the sysroot LLVM, which seems to pay off here.
That also helps with enabling Rust in Enzyme CI, since CCache for some reason doesn't seem to cache LLVM correctly on their runners.
I verified that this works with
` ./configure --release-channel=nightly --enable-llvm-enzyme --enable-option-checking --disable-docs --enable-llvm-assertions --set llvm.download-ci-llvm=true`. However, shouldn't download-ci-llvm already be the default? Why do I still have to manually set it with this pr?
I tested it afterwards with
`./x.py test --stage 1 tests/codegen-llvm/autodiff`
r? bootstrap
closes https://github.com/rust-lang/rust/issues/147535
