chore(issue-template): fix branch name
It was renamed to "main" from "master".
It might seem not important (actually it is not important) but I think there is no need to see this every time when we clicked this link:
And this way is faster I guess.
fix(x): fix a regex used to find python executable
Isn't the regex `^python[2-3]\.[0-9]\+$` wrong? It doesn't match, for example, with `python2.8`. There should be a plus sign at the end for a match, like `python2.8+`. I think `[0-9]+` is meant here instead of `[0-9]\+`. In that case a string like `python2.8` would match. This wasn't noticed because the script probably find and run the Python executable before this line.
bootstrap: add quoting support to avoid splitting
With this change, it is now possible to pass quotes to the configure script, such as
`./configure.py --set=target.\"thumbv8m.main-none-eabi\".linker=/linker`
or
`./configure.py '--set=target."thumbv8m.main-none-eabi".linker=/linker'`
, which will treat `thumbv8.main-none-eabi` as a whole part. Currently, the string would be split into two elements: `thumbv8`, and `main-none-eabi`.
The approach taken is to perform custom splitting instead of using `str.split()` and then repairing the split. Also, There are numerous corner cases not handled: the custom split doesn't differentiate between single quotes or double quotes, so it is perfectly possible to pass `./configure.py --set=target.\"thumbv8m.main-none-eabi\'.linker=/linker` and the behaviour would be the same as with all double quotes or single quotes.
As for the code, i'm unsure on whether to delimit strings with double or single quotes. I've seen both single quotes and double quotes used to delimit strings, like in
```py
err("Option '{}' provided more than once".format(key))
```
and this a handful of lines down:
```py
if option.name == 'sccache':
set('llvm.ccache', 'sccache', config)
```
Please advise on the wanted one.
Fixes#130602
r? `@onur-ozkan`
Thanks in advance for the feedback!
Inline str::repeat
`str` is non-generic and `str.repeat()` doesn't get inlined, which makes it use a slower algorithm in case of 1-char repetitions. Equivalent byte slice does get inlined: https://rust.godbolt.org/z/4arvh97r4
Revert using `HEAP` static in Windows alloc
Fixes#131468
This does the minimum to remove the `HEAP` static that was causing chromium issues. It would be worth having a more substantial look at this module but for now I think this addresses the immediate issue.
cc `@danakj`
Only disable cache if predicate has opaques within it
This is an alternative to https://github.com/rust-lang/rust/pull/132075.
This refines the check implemented in https://github.com/rust-lang/rust/pull/126024 to only disable the global cache if the predicate being considered has opaques in it. This is still theoretically unsound, since goals can indirectly rely on opaques in the defining scope, but we're much less likely to hit it.
It doesn't totally fix https://github.com/rust-lang/rust/issues/132064: for example, `lemmy` goes from 1:29 (on rust 1.81) to 9:53 (on nightly) to 4:07 (after this PR). But I think it's at least *more* sound than a total revert :/
r? lcnr
With this change, it is now possible to pass quotes to the configure
script, such as
`./configure.py --set=target.\"thumbv8m.main-none-eabi\".linker=/linker`
, which will treat `thumbv8.main-none-eabi` as a whole part. Currently,
the string would be split into two elements: `thumbv8`, and
`main-none-eabi`.
Fix an extra newline in rendered std doc
Fixes#132564
(taken from the issue above)
The problem with the formatting is due to that newline between `<code>` and `<svg>`. Any newlines outside of the code (i.e., within elements inside of it) are fine.
Clean middle generics using paren sugar if trait has `#[rustc_paren_sugar]`
That is to say, generalize the `Fn()` paren sugar handling to *any* trait that is marked with `rustc_paren_sugar`. This means that `AsyncFn` is also covered here.
r? fmease
Add new unstable feature `const_eq_ignore_ascii_case`
Tracking issue - #131719
Mark `[u8]`, `str` `eq_ignore_ascii_case` functions const
---
The codegen for this implementation matches the existing `iter::zip` implementation better than incrementing with a counter
while loop with counter - https://rust.godbolt.org/z/h9cs5zajc
while let - https://rust.godbolt.org/z/ecMeMjjEb
make char::is_whitespace unstably const
I am adding this to the existing https://github.com/rust-lang/rust/issues/132241 feature gate, since `is_digit` and `is_whitespace` seem similar enough that one can group them together.
Remove the `wasm32-wasi` target from rustc
This commit is the final step in the journey of renaming the historical `wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of `wasm32-wasip1` has currently been available for 6 months. Users have already seen warnings on stable for 2 months about usage of `wasm32-wasi` and stable users have another 2 months of warnings before the target is removed from stable.
This commit is intended to be the final step in this transition so the source tree should no longer mention `wasm32-wasi` except in historical reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
Add a new `wide-arithmetic` feature for WebAssembly
This commit adds a new rustc target feature named `wide-arithmetic` for WebAssembly targets. This corresponds to the [wide-arithmetic] proposal for WebAssembly which adds new instructions catered towards accelerating integer arithmetic larger than 64-bits. This proposal to WebAssembly is not standard yet so this new feature is flagged as an unstable target feature. Additionally Rust's LLVM version doesn't support this new feature yet since support will first be added in LLVM 20, so the feature filtering logic for LLVM is updated to handle this.
I'll also note that I'm not currently planning to add wasm-specific intrinsics to `std::arch::wasm32` at this time. The currently proposed instructions are all accessible through `i128` or `u128`-based operations which Rust already supports, so intrinsic shouldn't be necessary to get access to these new instructions.
[wide-arithmetic]: https://github.com/WebAssembly/wide-arithmetic
bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip
Fixes#131206.
- Includes `llvm-strip` (a symlink to `llvm-objcopy`) in the compiler dist artifact so that it can be used for `-Cstrip` instead of the system tooling.
- Uses `llvm-strip` instead of `/usr/bin/strip` for macOS. macOS needs a specific linker and the system one is preferred, hence #130781 but that doesn't work when cross-compiling, so use the `llvm-strip` utility instead.
cc #123151
