| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Drop binutils on powerpc-unknown-freebsd
FreeBSD 13.1 and 13.2 can build Rust with LLD just fine on powerpc.
|
|
Canonicalize float var as float in new solver
Typo in new canonicalizer -- we should be canonicalizing float vars as `CanonicalTyVarKind::Float`, not `CanonicalTyVarKind::Int`.
Fixes compiler-errors/next-solver-hir-issues#9
|
|
Don't ICE on `DiscriminantKind` projection in new solver
As title says, since we now actually call `Ty::discriminant_kind` on placeholder types 😃
Also drive-by simplify `Pointee::Metadata` projection logic, and fix the UI test because the `<T as Pointee>::Metadata` tests weren't actually exercising the new projection logic, since we still eagerly normalize (which hits `project.rs` in the old solver) in HIR typeck.
r? `@lcnr` tho feel free to re-roll, this pr is very low-priority and not super specific to the new trait solver.
Fixes compiler-errors/next-solver-hir-issues#14
|
|
RELEASES: Add "Only support Android NDK 25 or newer" to 1.68.0
See https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html and https://internals.rust-lang.org/t/rust-1-68-0-pre-release-testing/18481/2
|
|
compiletest: Don't allow tests with overlapping prefix names
Some tests will delete their output directory before starting. The output directory is based on the test names. If one test is the prefix of another test, then when that test starts, it could try to delete the output directory of the other test with the longer path, or otherwise clash with it while the two tests are trying to create/delete/modify the same directory.
In practice, this manifested as a random error on macOS where two tests were trying to create/delete/create `rustdoc/primitive` and `rustdoc/primitive/no_std`, which resulted in an EINVAL (InvalidInput) error.
This renames some of the offending tests, adds `compiletest-ignore-dir` to prevent compiletest from processing some files, and adds a check to prevent this from happening in the future.
Fixes #109397
|
|
Enhanced doucmentation of binary search methods for `slice` and `VecDeque` for unsorted instances
Fixes #106746. Issue #106746 raises the concern that the binary search methods for slices and deques aren't explicit enough about the fact that they are only applicable to sorted slices/deques. I changed the explanation for these methods. I took the relatively harsh description of the behaviour of binary search on unsorted collections ("unspecified and meaningless") from the description of the [`partition_point`](https://doc.rust-lang.org/std/primitive.slice.html#method.partition_point) method:
> If this slice is not partitioned, the returned result is unspecified and meaningless, as this method performs a kind of binary search.
|
|
|
|
FreeBSD 13.1 and 13.2 can build Rust with LLD just fine on powerpc.
|
|
Give return-position impl traits in trait a (synthetic) name to avoid name collisions with new lowering strategy
The only needed commit from this PR is the last one.
r? `@compiler-errors`
Needs #109455.
|
|
Stable MIR: Add basic MIR body datastructures
At this point it will panic on most useful MIR, but you can do basic assignments
r? `@pnkfelix`
|
|
|
|
|
|
|
|
Use `getentropy()` instead of `/dev/urandom` on Emscripten
`/dev/urandom` is usually available on Emscripten, except when using
the special `NODERAWFS` filesystem backend, which replaces all normal
filesystem access with direct Node.js operations.
Since this filesystem backend directly access the filesystem on the
OS, it is not recommended to depend on `/dev/urandom`, especially
when trying to run the Wasm binary on OSes that are not Unix-based.
This can be considered a non-functional change, since Emscripten
implements `/dev/urandom` in the same way as `getentropy()` when not
linking with `-sNODERAWFS`.
|
|
Rollup of 8 pull requests
Successful merges:
- #107387 (Use random `HashMap` keys on Hermit)
- #109511 (Make `EvalCtxt`'s `infcx` private)
- #109554 (Suggest ..= when someone tries to create an overflowing range)
- #109675 (Do not consider elaborated projection predicates for objects in new solver)
- #109693 (Remove ~const from alloc)
- #109700 (Lint against escape sequences in Fluent files)
- #109716 (Move `mir::Field` → `abi::FieldIdx`)
- #109726 (rustdoc: Don't strip crate module)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: Don't strip crate module
Until we decide something for https://github.com/rust-lang/rust/issues/109695, rustdoc won't crash anymore because the crate folder doesn't exist.
r? `@notriddle`
|
|
Move `mir::Field` → `abi::FieldIdx`
The first PR for https://github.com/rust-lang/compiler-team/issues/606
This is just the move-and-rename, because it's plenty big already. Future PRs will start using `FieldIdx` more broadly, and concomitantly removing `FieldIdx::new`s.
|
|
Lint against escape sequences in Fluent files
Fixes #109686 by checking for `\n`, `\"` and `\'` in Fluent files. It might be useful to have a way to opt out of this check, but all messages with violations currently do seem to be incorrect.
|
|
Remove ~const from alloc
There is currently an effort underway to stop using `~const Trait`, temporarily, so as to refactor the logic underlying const traits with relative ease. This means it has to go from the standard library, as well.
I have taken the initial step of just removing these impls from alloc, as removing them from core is a much more tangled task. In addition, all of these implementations are one more-or-less logically-connected group, so reverting their deconstification as a group seems like it will also be sensible.
r? `@fee1-dead`
|
|
Do not consider elaborated projection predicates for objects in new solver
Object types have projection bounds which are elaborated during astconv. There's no need to do it again for projection goals, since that'll give us duplicate projection candidatesd that are distinct up to regions due to the fact that we canonicalize every region to a separate variable. See quick example below the break for a better explanation.
Discussed this with lcnr, and adding a stop-gap until we get something like intersection region constraints (or modify canonicalization to canonicalize identical regions to the same canonical regions) -- after which, this will hopefully not matter and may be removed.
r? `@lcnr`
---
See `tests/ui/traits/new-solver/more-object-bound.rs`:
Consider a goal: `<dyn Iter<'a, ()> as Iterator>::Item = &'a ()`.
After canonicalization: `<dyn Iter<'!0r, (), Item = '!1r ()> as Iterator>::Item == &!'2r ()`
* First object candidate comes from the item bound in the dyn's bounds itself, giving us `<dyn Iter<'!0r, (), Item = '?!r ()> as Iterator>::Item == &!'1r ()`. This gives us one region constraint: `!'1r == !'2r`.
* Second object candidate comes from elaborating the principal trait ref, gives us `<dyn Iter<'!0r, (), Item = '!1r ()> as Iterator>::Item == &!'0r ()`. This gives us one region constraint: `!'0r == !'2r`.
* Oops! Ambiguity!
|
|
Suggest ..= when someone tries to create an overflowing range
Fixes #109529
|
|
Make `EvalCtxt`'s `infcx` private
To better protect against people doing bad things with the inner `InferCtxt`
r? `@lcnr`
|
|
Use random `HashMap` keys on Hermit
Initializing the keys with random data provided by the libOS avoids HashDOS attacks and similar issues.
CC `@stlankes`
|
|
pnkfelix:rollback-part-of-pr-104137-that-broke-wasm-linker-overriding, r=petrochenkov
Rollback part of pr 104137 that broke wasm linker overriding
This is a quick fix to address #108910
|
|
|
|
Support TLS access into dylibs on Windows
This allows access to `#[thread_local]` in upstream dylibs on Windows by introducing a MIR shim to return the address of the thread local. Accesses that go into an upstream dylib will call the MIR shim to get the address of it.
`convert_tls_rvalues` is introduced in `rustc_codegen_ssa` which rewrites MIR TLS accesses to dummy calls which are replaced with calls to the MIR shims when the dummy calls are lowered to backend calls.
A new `dll_tls_export` target option enables this behavior with a `false` value which is set for Windows platforms.
This fixes https://github.com/rust-lang/rust/issues/84933.
|
|
|
|
|
|
removing regression test
|
|
removing regression test
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make init mask lazy for fully initialized/uninitialized const allocations
There are a few optimization opportunities in the `InitMask` and related const `Allocation`s (e.g. by taking advantage of the fact that it's a bitset that represents initialization, which is often entirely initialized or uninitialized in a single call, or gradually built up, etc).
There's a few overwrites to the same state, multiple writes in a row to the same indices, the RLE scheme for `memcpy` doesn't always compress, etc.
Here, we start with:
- avoiding materializing the bitset's blocks if the allocation is fully initialized/uninitialized
- dealloc blocks when fully overwriting, including when participating in `memcpy`s
- take care of the fixme about allocating blocks of 0s before overwriting them to the expected value
- expanding unit test coverage of the init mask
This should be most visible on benchmarks and crates where const allocations dominate the runtime (like `ctfe-stress-5` of course), but I was especially looking at the worst cases from #93215.
This first change allows the majority of `set_range` calls to stay with a lazy init mask when bootstrapping rustc (not that the init mask is a big part of the process in cpu time or memory usage).
r? `@oli-obk`
I have another in-progress branch where I'll switch the singular initialized/uninitialized value to a watermark, recording the point after which everything is uninitialized. That will take care of cases where full initialization is monotonic and done in multiple steps (e.g. an array of a type without padding), which should then allow the vast majority of const allocations' init masks to stay lazy during bootstrapping (though interestingly I've seen such gradual initialization in both left-to-right and right-to-left directions, and I don't think a single watermark can handle both).
|
|
Rollup of 7 pull requests
Successful merges:
- #108335 (rustdoc + rustdoc-json support for `feature(non_lifetime_binders)`)
- #109534 (rustdoc: Unsupport importing `doc(primitive)` and `doc(keyword)` modules)
- #109659 (llvm-wrapper: adapt for LLVM API change)
- #109664 (Use span of placeholders in format_args!() expansion.)
- #109683 (Check for overflow in `assemble_candidates_after_normalizing_self_ty`)
- #109713 (Fix mismatched punctuation in Debug impl of AttrId)
- #109718 (Rename `IndexVec::last` → `last_index`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`getentropy()` is available since Emscripten 2.0.5.
See:
https://github.com/emscripten-core/emscripten/pull/12240
|
|
unsorted instances
|
|
|
|
Rename `IndexVec::last` → `last_index`
As I've been trying to replace a `Vec` with an `IndexVec`, having `last` exist on both but returning very different types makes the transition a bit awkward -- the errors are later, where you get things like "there's no `ty` method on `mir::Field`" rather than a more localized error like "hey, there's no `last` on `IndexVec`".
So I propose renaming `last` to `last_index` to help distinguish `Vec::last`, which returns an element, and `IndexVec::last_index`, which returns an index.
(Similarly, `Iterator::last` also returns an element, not an index.)
|
|
Fix mismatched punctuation in Debug impl of AttrId
I noticed this odd line in `ast-tree` output.
```console
$ echo '#[attr] struct S;' | rustc -Zunpretty=ast-tree -
```
```rust
...
attrs: [
Attribute {
kind: Normal(
NormalAttr {
item: AttrItem {
path: Path {
segments: [
PathSegment {
ident: attr#0,
args: None,
},
],
tokens: None,
},
args: Empty,
},
},
),
id: AttrId(0)], // <------
style: Outer,
},
```
|
|
Check for overflow in `assemble_candidates_after_normalizing_self_ty`
Prevents a stack overflow (:warning: :exclamation:) in the new solver when we have param-env candidates that look like: `T: Trait<Assoc = <T as Trait>::Assoc>`
The current error message looks bad, but that's because we don't distinguish overflow and other ambiguity errors. I'll break that out into a separate PR since the fix may be controversial.
r? `@lcnr`
|
|
Use span of placeholders in format_args!() expansion.
`format_args!("{}", x)` expands to something that contains `Argument::new_display(&x)`. That entire expression was generated with the span of `x`.
After this PR, `&x` uses the span of `x`, but the `new_display` call uses the span of the `{}` placeholder within the format string. If an implicitly captured argument was used like in `format_args!("{x}")`, both use the span of the `{x}` placeholder.
This fixes https://github.com/rust-lang/rust/issues/109576, and also allows for more improvements to similar diagnostics in the future, since the usage of `x` can now be traced to the exact `{}` placeholder that required it to be `Display` (or `Debug` etc.)
|
|
llvm-wrapper: adapt for LLVM API change
Adapts the wrapper for the LLVM commit https://github.com/llvm/llvm-project/commit/377e1311d50c7e5b5aab3db081938e0d0ceebdfc.
Found by the experimental rust + LLVM @ HEAD bot: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/18141#01872217-de22-4826-b0d6-2dd4884d8893
|
|
rustdoc: Unsupport importing `doc(primitive)` and `doc(keyword)` modules
These are internal features used for a specific purpose, and modules without imports are enough for that purpose.
|
|
r=GuillaumeGomez
rustdoc + rustdoc-json support for `feature(non_lifetime_binders)`
Makes `for<T> T: Trait` and `for<const N: usize> ..` in where clause operate correctly.
Fixes #108158
|
|
|
|
As I've been trying to replace a `Vec` with an `IndexVec`, having `last` exist on both but returning very different types makes the transition a bit awkward -- the errors are later, where you get things like "there's no `ty` method on `mir::Field`" rather than a more localized error like "hey, there's no `last` on `IndexVec`".
So I propose renaming `last` to `last_index` to help distinguish `Vec::last`, which returns an element, and `IndexVec::last_index`, which returns an index.
(Similarly, `Iterator::last` also returns an element, not an index.)
|
