Move private bignum module to core::num, because it is not only used in flt2dec.
Extract private 80-bit soft-float into new core::num module for the same reason.
This breaks out some of the lints defined in `librustc_lint/builtin.rs` into two new modules: `unused` for the `UNUSED_*` lints and `bad_style` for the various style related lints as suggested in #22206. `builtin.rs` could probably get broken up more but this is a start.
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
r? @alexcrichton
this commit needs #28495 to be commited first. It should be the last piece for building rustc under OpenBSD from scratch.
By default, the linker in use under OpenBSD is the linker of base, which
don't include /usr/local/lib where libstdc++ of gcc-4.9 lives. We need
to add this directory to linker-path-search (using -L).
Search the path of libstdc++.a, which is a known name (libstdc++.so has
SO_VERSION) in the same directory.
Move private bignum module to core::num, because it is not only used in flt2dec.
Extract private 80-bit soft-float into new core::num module for the same reason.
This changes how rustic generate `id` and `href` attributes for section header anchor. Now they are more github-like.
Also fixes breakage in docs caused by this and broken links in "Error Handling" section of book.
r? @steveklabnik
cc @alexcrichton
This reduces some clones of `Vec`s. These are not deep copies since the
token tree is made using `Rc`s, so this won't be a major improvement.
r? @eddyb
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
r? @nikomatsakis
I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.
When both the key and value types were zero-sized, `BTreeMap` previously
called `heap::allocate` with `size == 0` for leaf nodes, which is
undefined behavior, and jemalloc would attempt to read invalid memory,
crashing the process.
This avoids undefined behavior by allocating enough space to store one
edge in leaf nodes that would otherwise have `size == 0`. Although this
uses extra memory, maps with zero-sized key types that have sensible
implementations of the ordering traits can only contain a single
key-value pair (and therefore only a single leaf node), and maps with
key and value types that are both zero-sized have few uses, if any.
Furthermore, this is a temporary fix that will likely be unnecessary
once the `BTreeMap` implementation is rewritten to use parent pointers.
Closes#28493.
In code like `let x = 5`, I am initially confused as to the meaning of "let doesn't take a name on the left hand side, it actually accepts a pattern." - I interpret that as the pattern being located as: `<pattern> let [...]`.
I think what is meant is that the name/pattern is on the left hand side *of the assignment*, rather than to the left of the *let* statement. This change clarifies that.
history.pushState is defined, but not working whenever document.origin is "null"
(literally that string, not just the null object).
This is due to some security considerations and is unlikely to be ever working.
For now just disable the usage of the history API when the documentation
is accessed through a file:/// URL.
See https://code.google.com/p/chromium/issues/detail?id=301210 for a
Chrome-specific issue on the history API on file:/// URLs
Closes#25953
VecDeque: Use power of two capacity even for zero sized types
VecDeque depends on using a power of two capacity. Use the largest
possible power of two capacity for ZSTs.
Fixes#28488
it makes rustc compatible with gcc installation that are using
`--program-transform-name' configure flag (on OpenBSD for example).
- detects at configure the name of stdc++ library on the system
- use the detected name in llvm makefile (with enable-static-stdcpp),
and pass it to mklldeps.py
- generate mklldeps.rs using this detected name
note that CFG_STDCPP_NAME is about stdc++ name, not about libc++. If
using libc++, the default name will be `stdc++', but it won't be used
when linking.
r? @alexcrichton
I added this support globally instead of just for OpenBSD as it isn't specially related to OpenBSD (except OpenBSD use it for gcc-4.9). And as I would had to change `llvm.mk', having just a default value in `configure' for others platforms won't be very useful.
