This is a first patch towards an opt-in built-in trait world. This patch removes the restriction on built-in traits and allows such traits to be derived.
[RFC#3]
cc #13231
@nikomatsakis r?
This allows writing code examples which pass all analysis of the compiler, but
don't actually link. A good example is examples that use extern {} blocks.
Closes#12903
Rustdoc currently doesn't inline documentation of a `pub use` if the target is
publicly reachable. This changes rustdoc to allow a #[doc(inline)] attribute to
force inlining the documentation, regardless of whether the targe is public or
not.
Closes#13045
The outer attributes were manually appended when a module file was parsed, but
the attributes were also added higher up the stack of parsing (when the module
finished parsing). This removes the append in parsing the module file.
Closes#13826
These fonts were moved into place by rust's makefiles, but rustdoc is widely
used outside of rustc itself. This moves the fonts into the rustdoc binary,
similarly to the other static assets, and writes them to the output location
whenever rustdoc generates documentation.
Closes#13593Closes#13787
This change allow a speedup of ~1.5 on shootout-pidigits on a i32
system. `MachineUint` is used to abstract the internal machine
unsigned integer to simplity future architecture specialization.
This ensures that private functions exported through static initializers will
actually end up being public in the object file (so other objects can continue
to reference the function).
Closes#13620
This has long since not been too relevant since the introduction of many crate
type outputs. This commit removes the flag entirely, adjusting all logic to do
the most reasonable thing when building both a library and an executable.
Closes#13337
Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.
The goal of this commit is to enable *some* use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.
There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.
cc #10729
Namely:
* Added conversion traits both to and from the various vector types,
analogous to how `str::MaybeOwned` works with `str::IntoMaybeOwned`
and `str::Str`. This led me to add the `FixedLen` variant of
`MaybeOwnedVector` for interoperability with `std::slice`.
* Revised client example code to make use of `into_maybe_owned`
* Added implementations of `Show` and `CloneableVector` for
`MaybeOwnedVector`.
* As suggested by kballard, added `into_vec` method that is analogous
to `CloneableVector::into_owned` except it produces a `Vec` rather
than a `~[T]`.
Commits for details.
This shouldn't change the generated code at all (except for switching to `LitBinary` from an explicit ExprVec of individual ExprLit bytes for `prefix_bytes`).
char literals now work in a quotation.
There were several instances of duplicated functionality in regex_macros
compared to AstBuilder so refactor those out.
Clearly storing them as `char` is semantically nicer, but this also
fixes a bug whereby `quote_expr!(cx, 'a')` wasn't working, because the
code created by quotation was not matching the actual AST definitions.
I switched the `assert!` calls in `RefCell` over to `debug_assert!`.
There are probably other instances that should be converted as well, but
I couldn't think of any off the top of my head.
RFC: 0015-assert
