Continue parsing function after finding `...` arg
When encountering a variadic argument in a function definition that
doesn't accept it, if immediately after there's a closing paren,
continue parsing as normal. Otherwise keep current behavior of emitting
error and stopping.
Fix#31481.
Update ops range example to avoid confusion between indexes and values.
Makes clearer the numbers in the range refer to indexes, not the values at those indexes.
Correct a few stability attributes
* `core_float_bits`, `duration_core`, `path_component_asref`, and `repr_align` were stabalized in 1.25.0 not 1.24.0.
* Impls for `NonNull` involving unstable things should remain unstable.
* `Duration` should remain stable since 1.3.0 so it appears correctly in the `std` docs.
* `cursor_mut_vec` is an impl on only stable things so should be marked stable.
Add Range[Inclusive]::is_empty
During https://github.com/rust-lang/rfcs/pull/1980, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- such as `Range<i64>` and `RangeInclusive<usize>`.
Things to ponder:
- Unless this is stabilized first, this makes stabilizing ExactSizeIterator::is_empty more icky, since this hides that.
- This is only on `Range` and `RangeInclusive`, as those are the only ones where it's interesting. But one could argue that it should be on more for consistency, or on RangeArgument instead.
- The bound on this is PartialOrd, since that works ok (see tests for float examples) and is consistent with `contains`. But ranges like `NAN..=NAN`_are_ kinda weird.
- [x] ~~There's not a real issue number on this yet~~
Apply optimization from #44355 to retain
As discussed in #44355 this PR applies a similar optimization to `Vec::retain`. For `drain_filter`, a very similar function, this improved performance by up to 20%.
Work around LLVM OCAML binding installation failure
Hello,
I have OCaml installed on my machine, and compiling rust systematically fails when LLVM attempts installing the OCaml bindings in `/usr/lib/ocaml`, which is write-protected. Here are the logs: https://gist.github.com/roblabla/3f147914c5df627c9d97ab311ba133ad
Some digging around the issue reveals:
- The code that finds if OCaml is installed, and sets the bindings to be compiled/installed: b24a45d2e9/cmake/config-ix.cmake (L612)
- b24a45d2e9/bindings/ocaml/llvm/CMakeLists.txt Some code that does the installation.
The problem seems to be that `LLVM_OCAML_INSTALL_PATH` is set to `OCAML_STDLIB_PATH` by default, which is in `/usr/lib/ocaml`, instead of the prefix.
This PR "fixes" the issue by setting `LLVM_OCAML_INSTALL_PATH` to `usr/lib/ocaml`. I haven't found a way to make LLVM not build OCaml, which would probably be a superior fix.
Changed color of struct link from #ff794d to #2dbfb8 for Rust docs
This is in reference to https://github.com/rust-lang/rust/issues/47801
here I have changed the default color of struct link for `#ff794d` to `#2dbfb8`
cc: @nagisa @timClicks
rustc: Add the ability to not run dsymutil
This commit adds the ability for rustc to not run `dsymutil` by default
on OSX. A new codegen option, `-Z run-dsymutil=no`, was added to specify
that `dsymutil` should *not* run and instead the compiler should
unconditionally keep the object files around in a compilation if
necessary for debug information.
cc #47240
This commit adds the ability for rustc to not run `dsymutil` by default
on OSX. A new codegen option, `-Z run-dsymutil=no`, was added to specify
that `dsymutil` should *not* run and instead the compiler should
unconditionally keep the object files around in a compilation if
necessary for debug information.
cc #47240
When encountering a variadic argument in a function definition that
doesn't accept it, if immediately after there's a closing paren,
continue parsing as normal. Otherwise keep current behavior of emitting
error and stopping.
This isn't a perfect heuristic, but since the amount of run-fail tests
is far lower than run-pass tests for now, it should be sufficient to
ensure that we don't run into CI limits. This makes it possible to run
the test binary manually (e.g., under gdb/lldb) if it failed to attempt
to find out why.
Fix oversized loads on x86_64 SysV FFI calls
The x86_64 SysV ABI should use exact sizes for small structs passed in
registers, i.e. a struct that occupies 3 bytes should use an i24,
instead of the i32 it currently uses.
Refs #45543
Emit data::Impl in save-analysis
As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis.
A number of questions are outstanding:
- [x] A few `???` around row 356. We need to discuss what goes here, if anything.
- [ ] ~~Deriving `id` for impl using hashing. Is this going to clash with rustc defids?~~
- [ ] ~~Deriving `id` for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?~~
- [x] Need a new rls-data with an `id` field in `Impl` struct.
- [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~
rustc_mir: insert a dummy access to places being matched on, when building MIR.
Fixes#47412 by adding a `_dummy = Discriminant(place)` before each `match place {...}`.
r? @nikomatsakis
Document the behaviour of infinite iterators on potentially-computable methods
It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
Explain unusual debugging code in librustc
Introduced in #47828 to help track down some bugs, it landed a bit hastily so
this is intended on cleaning it up a bit.
Update the dlmalloc submodule
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
A bug was recently fixed in dlmalloc which meant that released memory to the
system accidentally wasn't getting reused, causing programs to be far slower
than they should be!
Add fetch_nand to atomics
I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...
cc #13226 (the tracking issue)
