| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
These are identical to what already exists in compiler-builtins except
for some base image changes, so we can eliminate the duplicates.
|
|
Apply the same formatting rules to both `libm` and `compiler-builtins`.
|
|
Use the 2024 style edition for all crates and enable import sorting.
2024 already applies some smaller heuristics that look good in
compiler-builtins, I have dropped `use_small_heuristics` that was set in
`libm` because it seems to negatively affect the readibility of anything
working with numbers (e.g. collapsing multiple small `if` expressions
into a single line).
|
|
These should build and test correctly. `libm-test` and others that
depend on it are excluded since the necessary CI is not yet set up.
|
|
Update paths and submodules to fix `libm-test` and `util` building so we
will be able to add them to the workspace.
|
|
|
|
|
|
|
|
Distribute everything from `libm/` to better locations in the repo.
`libm/libm/*` has not moved yet to avoid Git seeing the move as an edit
to `Cargo.toml`.
Files that remain to be merged somehow are in `etc/libm`.
|
|
Since `libm` is now part of the `compiler-builtins` repo, the crate to
test that they work together is no longer needed.
|
|
|
|
|
|
|
|
Absorb the libm repository into `compiler-builtins`.
This was done using `git-filter-repo` to ensure hashes mentioned in
commit messages were correctly rewritten, I used the same strategy to
merge `ctest` into `libc` [1] and it worked quite well. Approximately:
# `git filter-repo` requires a clean clone
git clone https://github.com/rust-lang/libm.git
# Move all code to a `libm` subdirectory for all history
git filter-repo --to-subdirectory-filter libm
# The default merge messages are "merge pull request #nnn from
# user/branch". GH links these incorrectly in the new repo, so
# rewrite messages from `#nnn` to `rust-lang/libm#nnn`.
echo 'regex:(^|\s)(#\d+)==>\1rust-lang/libm\2' > messages.txt
git filter-repo --replace-message messages.txt
# Re-add a remote and push as a new branch
git remote add upstream https://github.com/rust-lang/libm.git
git switch -c merge-into-builtins-prep
git push --set-upstream upstream merge-into-builtins-prep
# Now in a compiler-builtins, add `libm` as a remote
git remote add libm https://github.com/rust-lang/libm.git
git fetch libm
# Do the merge that creates this commit
git merge libm/merge-into-builtins-prep --allow-unrelated-histories
The result should be correct git history and blame for all files, with
messages that use correct rewritten hashes when they are referenced.
There is some reorganization and CI work needed, but that will be a
follow up.
After this merges I will need to push tags from `libm`, which I have
already rewritten to include a `libm-` prefix. Old tags in
compiler-builtins should likely also be rewritten to add a prefix (we
already have this for newer tags), but this can be done at any point.
* Original remote: https://github.com/rust-lang/libm.git
* Default HEAD: c94017af75c3ec4616d5b7f9b6b1b3826b934469 ("Migrate all
crates except `libm` to edition 2024")
* HEAD after rewriting history: 15fb6307f6dc295fb965d1c4f486571cc18ab6b3
("Migrate all crates except `libm` to edition 2024")
[1]: https://github.com/rust-lang/libc/pull/4283#issuecomment-2773986492
|
|
|
|
add next_index to Enumerate
Proposal: https://github.com/rust-lang/libs-team/issues/435
Tracking Issue: #130711
This basically just reopens #130682 but squashed and with the new function and the feature gate renamed to `next_index.`
There are two questions I have already:
- Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be.
- Maybe I could actually also add a doctest?
- For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
|
|
Move `pal::env` to `std::sys::env_consts`
Combine the `std::env::consts` platform implementations as a single file. Use the Unix file as the base, since it has 28 entries, and fold the 8 singleton platforms into it. The Unix file was roughly grouped into Linux, Apple, BSD, and everything else, roughly in alphabetical order. Alphabetically order them to make it easier to maintain and discard the Unix-specific groups to generalize it to all platforms.
I'd prefer to have no fallback implementation, as I consider it a bug; however TEEOS, Trusty, and Xous have no definitions here. Since they otherwise have `pal` abstractions, that indicates that there are several platforms without `pal` abstractions which are also missing here. To support unsupported, create a little macro to handle the fallback case and not introduce ordering between the `cfg`s like `cfg_if!`.
I've named the module `std::sys::env_consts`, because they are used in `std::env::consts` and I intend to use the name `std::sys::env` for the combination of `Args` and `Vars`.
cc `@joboet` `@ChrisDenton`
Tracked in #117276.
|
|
std: Use fstatat() on illumos
|
|
fix incorrect type in cstr `to_string_lossy()` docs
Restoring what it said prior to commit 67065fe in which it was changed incorrectly with no supporting explanation.
Closes #139835.
|
|
Implement `Default` for raw pointers
ACP: https://github.com/rust-lang/libs-team/issues/571
This is instantly stable so we will need an FCP here.
Closes https://github.com/rust-lang/rfcs/issues/2464
|
|
|
|
|
|
|
|
|
|
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
|
|
Also mention them from `as_flattened(_mut)`.
|
|
Prepare for having the repositories combined by ensuring EMULATED,
RUST_BACKTRACE, and CI are set or forwarded as applicable. Also
re-indent the file to four spaces and do some reorganization.
|
|
Apply a handful of changes to reduce the diff between the two:
* Cancel running jobs on new pushes
* Enable log color and backtraces
* Add timeouts
* Specify CI runner versions
* Add an armv7 job
* Replace the name NO_STD with BUILD_ONLY
* Update the extension to the canonical .yaml
* Set AR_ and CC_ environments in docker
* Install requirements to build MPFR
|
|
|
|
|
|
The repo will soon have `libm` as a top-level crate, so make it clear
that this is only the test crate for `compiler-builtins`.
|
|
They were roughly grouped into Linux, Apple, BSD, and everything else,
roughly in alphabetical order. Alphabetically order them to make it
easier to maintain and discard the Unix-specific groups to generalize it
to all platforms.
|
|
Unfortunately this means we lose use of the convenient name `gen`, so
this includes a handful of renaming.
We can't increase the edition for `libm` yet due to MSRV, but we can
enable `unsafe_op_in_unsafe_fn` to help make that change smoother in the
future.
|
|
Move the workspace configuration to a virtual manifest. This
reorganization makes a more clear separation between package contents
and support files that don't get distributed. It will also make it
easier to merge this repository with `compiler-builtins` which is
planned (builtins had a similar update done in [1]).
LICENSE.txt and README.md are symlinkedinto the new directory to ensure
they get included in the package.
[1]: https://github.com/rust-lang/compiler-builtins/pull/702
|
|
In preparation for switching to a virtual manifest, move the `libm`
crate into a subdirectory and update paths to match.
Updating `Cargo.toml` is done in the next commit so git tracks the moved
file correctly.
|
|
Benchmarks for [1] seemed to indicate that repository organization for
some reason had an effect on performance, even though the exact same
rustc commands were running (though some with a different order). After
investigating more, it appears that dependencies may have an affect on
inlining thresholds for generic functions.
It is surprising that this happens, we more or less expect that public
functions will be standalone but everything they call will be inlined.
To help ensure this, mark all generic functions `#[inline]` if they
should be merged into the public function.
Zulip discussion at [2].
[1]: https://github.com/rust-lang/libm/pull/533
[2]: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Dependencies.20affecting.20codegen/with/513079387
|
|
|
|
Since `fmod` is generic, there isn't any need to have the small wrappers
in separate files. Most operations was done in [1] but `fmod` was
omitted until now.
[1]: https://github.com/rust-lang/libm/pull/537
|
|
|
|
|
|
This is consistent with the style of `ByteString`.
|
|
Rollup of 7 pull requests
Successful merges:
- #138528 (deref patterns: implement implicit deref patterns)
- #139393 (rustdoc-json: Output target feature information)
- #139553 (sync::mpsc: prevent double free on `Drop`)
- #139615 (Remove `name_or_empty`)
- #139853 (Disable combining LLD with external llvm-config)
- #139913 (rustdoc/clean: Fix lowering of fn params (fixes correctness & HIR vs. middle parity regressions))
- #139942 (Ignore aix for tests/ui/erros/pic-linker.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Fixes: https://github.com/rust-lang/libm/issues/201
|
|
This is the case for CI after merge that is no longer associated with a
pull request.
|
|
|
|
|
