This is theoretically a breaking change, but GitHub search turns up no
uses of it, and most non-built-in cfg's are passed via cargo features,
which look like `feature = "..."`, and hence can't overlap.
Current behaviour demo: http://is.gd/l3FEgo
(The span is printed at the start of the source code)
This patch moves the span to the use of `$i` in the macro rhs (as the code comment already claims)
This commit is an implementation of [RFC 1183][rfc] which allows swapping out
the default allocator on nightly Rust. No new stable surface area should be
added as a part of this commit.
[rfc]: https://github.com/rust-lang/rfcs/pull/1183
Two new attributes have been added to the compiler:
* `#![needs_allocator]` - this is used by liballoc (and likely only liballoc) to
indicate that it requires an allocator crate to be in scope.
* `#![allocator]` - this is a indicator that the crate is an allocator which can
satisfy the `needs_allocator` attribute above.
The ABI of the allocator crate is defined to be a set of symbols that implement
the standard Rust allocation/deallocation functions. The symbols are not
currently checked for exhaustiveness or typechecked. There are also a number of
restrictions on these crates:
* An allocator crate cannot transitively depend on a crate that is flagged as
needing an allocator (e.g. allocator crates can't depend on liballoc).
* There can only be one explicitly linked allocator in a final image.
* If no allocator is explicitly requested one will be injected on behalf of the
compiler. Binaries and Rust dylibs will use jemalloc by default where
available and staticlibs/other dylibs will use the system allocator by
default.
Two allocators are provided by the distribution by default, `alloc_system` and
`alloc_jemalloc` which operate as advertised.
Closes#27389
This PR implements the majority of RFC 1214. In particular, it implements:
- the new outlives relation
- comprehensive WF checking
For the most part, new code receives warnings, not errors, though 3 regressions were found via a crater run.
There are some deviations from RFC 1214. Most notably:
- we still consider implied bounds from fn ret; this intersects other soundness issues that I intend to address in detail in a follow-up RFC. Fixing this without breaking a lot of code probably requires rewriting compare-method somewhat (which is probably a good thing).
- object types do not check trait bounds for fear of encountering `Self`; this was left as an unresolved question in RFC 1214, but ultimately feels inconsistent.
Both of those two issues are highlighted in the tracking issue, https://github.com/rust-lang/rust/issues/27579. #27579 also includes a testing matrix with new tests that I wrote -- these probably duplicate some existing tests, I tried to check but wasn't quite sure what to look for. I tried to be thorough in testing the WF relation, at least, but would welcome suggestions for missing tests.
r? @nrc (or perhaps someone else?)
This commit removes all unstable and deprecated functions in the standard
library. A release was recently cut (1.3) which makes this a good time for some
spring cleaning of the deprecated functions.
warnings. It also checks more conditions than the old code. Keep the
old wf code around unchanged so that we can continue to issue errors for
the cases where we used to report errors.
As part of this, remove the where-clauses-must-reference-parameter rule,
which is easily circumvented.
This commit removes all unstable and deprecated functions in the standard
library. A release was recently cut (1.3) which makes this a good time for some
spring cleaning of the deprecated functions.
LLVM might perform tail merging on the calls that initiate the unwinding
process which breaks debuginfo and therefore this test. Since tail
merging is guaranteed to break debuginfo, it should be disabled for this
test.
This allows us to restore a testcase that I had to remove earlier
because of the same problem, because back then I didn't realize that
disabling tail merging was an option.
cc #27619
See line 181: The lookup should start with the random index and iterate from there.
Also locked stdout (which makes it a bit faster on my machine). And the `make_lookup` function now uses `map` (as the TODO asked for).
Perhaps the multi-thread output from the fasta benchmark could be used to speed it up even more.
Because I wanted to change the pretty test as little as possible I added `// compiler-flags: --crate-type=lib` to those test that failed because of a missing `main`. Passes `make check-stage1-pretty` locally.
cc @nrc
cc #27567
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
I'm opening this PR as a platform for discussion - there may be some method renaming to do as part of the stabilization process.
Rust's current compilation model makes it impossible on Windows to generate one
object file with a complete and final set of dllexport annotations. This is
because when an object is generated the compiler doesn't actually know if it
will later be included in a dynamic library or not. The compiler works around
this today by flagging *everything* as dllexport, but this has the drawback of
exposing too much.
Thankfully there are alternate methods of specifying the exported surface area
of a dll on Windows, one of which is passing a `*.def` file to the linker which
lists all public symbols of the dynamic library. This commit removes all
locations that add `dllexport` to LLVM variables and instead dynamically
generates a `*.def` file which is passed to the linker. This file will include
all the public symbols of the current object file as well as all upstream
libraries, and the crucial aspect is that it's only used when generating a
dynamic library. When generating an executable this file isn't generated, so all
the symbols aren't exported from an executable.
To ensure that statically included native libraries are reexported correctly,
the previously added support for the `#[linked_from]` attribute is used to
determine the set of FFI symbols that are exported from a dynamic library, and
this is required to get the compiler to link correctly.
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
This commit removes all morestack support from the compiler which entails:
* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required
The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.
This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.
cc #16012 (still need stack probes)
Closes#26458 (a drive-by fix to help diagnostics on stack overflow)
r? @brson
