`make docs` fails when (xe)latex is not installed. The output is pretty weird, looks like it's doing some `eval` tricks but something is blank:
/bin/sh: -output-directory=.: command not found
/home/tim/dev/rust/rust/mk/docs.mk:220: recipe for target 'doc/reference.pdf' failed
I have neither latex or xelatex installed. It seems like the following snippet is meant for me, but the logic is backwards:
ifeq ($(CFG_XELATEX),)
CFG_LATEX := $(CFG_XELATEX)
XELATEX = 1
else
$(info cfg: no xelatex found, disabling LaTeX docs)
NO_PDF_DOCS = 1
endif
I verified with:
$ make doc/reference.pdf CFG_XELATEX=/bin/foo
cfg: no xelatex found, disabling LaTeX docs
Largely adapted from pcwalton's original branch, with following
notable modifications:
Use `regionck::type_must_outlive` to generate `SafeDestructor`
constraints. (this plugged some soundness holes in the analysis).
Avoid exponential time blowup on compile-fail/huge-struct.rs by
keeping the breadcrumbs until end of traversal.
Avoid premature return from regionck::visit_expr.
Factored drop-checking code out into dropck module.
Added `SafeDestructor` to enum `SubregionOrigin` (for error reporting).
----
Since this imposes restrictions on the lifetimes used in types with
destructors, this is a (wait for it)
[breaking-change]
immediately surrounding a node that is a terminating_scope
(e.g. statements, looping forms) during which the destructors run (the
destructors for temporaries from the execution of that node, that is).
Introduced DestructionScopeData newtype wrapper around ast::NodeId, to
preserve invariant that FreeRegion and ScopeChain::BlockScope carry
destruction scopes (rather than arbitrary CodeExtents).
Insert DestructionScope and block Remainder into enclosing CodeExtents
hierarchy.
Add more doc for DestructionScope, complete with ASCII art.
Switch to constructing DestructionScope rather than Misc in a number
of places, mostly related to `ty::ReFree` creation, and use
destruction-scopes of node-ids at various calls to
liberate_late_bound_regions.
middle::resolve_lifetime: Map BlockScope to DestructionScope in `fn resolve_free_lifetime`.
Add the InnermostDeclaringBlock and InnermostEnclosingExpr enums that
are my attempt to clarify the region::Context structure, and that
later commmts build upon.
Improve the debug output for `CodeExtent` attached to `ty::Region::ReScope`.
Loosened an assertion in `rustc_trans::trans::cleanup` to account for
`DestructionScope`. (Perhaps this should just be switched entirely
over to `DestructionScope`, rather than allowing for either `Misc` or
`DestructionScope`.)
----
Even though the DestructionScope is new, this particular commit should
not actually change the semantics of any current code.
Updates to the bison grammar:
* Fixes to range syntax - allow `expr[..]`, and fix precedence to allow `for _ in i.. { }`
* Allow "extern crate" in stmts
* Add qualified path expressions (`<TYPE as TRAIT_REF>::item`)
I was working on adding examples to the documentation in `std::num::Float`. I got to `exp2`, which says "Returns 2 raised to the power of the number, `2^(self)`."
So I tried running this code:
```
use std::num::Float;
#[test]
fn test_exp2() {
assert_eq!(32.0, 5.0.exp2());
}
```
and it resulted in a failure of `(left: `32`, right: `148.413159`)`. That 148.413159 is the value for e^5, which is `exp()`, not `exp2()`.
Sure enough, `exp2` is calling `exp` and shouldn't be, looks like a copy-paste error.
I haven't added any tests for this since it's unlikely to break again, but I will happily do so if people think that would be a good idea. The doc examples are coming :)
I scanned through the other functions in these files for similar sorts of errors and didn't notice any.
As the function comment already says, the types generated in the
foreign_signture function don't necessarily match the types used for a
corresponding rust function. Therefore we can't just use these types to
guide the translation of the wrapper function that bridges between the
external ABI and the rust ABI. Instead, we can query LLVM about the
types used in the rust function and use those to generate an appropriate
wrapper.
Fixes#21454
As the function comment already says, the types generated in the
foreign_signture function don't necessarily match the types used for a
corresponding rust function. Therefore we can't just use these types to
guide the translation of the wrapper function that bridges between the
external ABI and the rust ABI. Instead, we can query LLVM about the
types used in the rust function and use those to generate an appropriate
wrapper.
Fixes#21454
The live code analysis only visited the function's body when visiting a
method, and not the FnDecl and the generics, resulting in code to be
incorrectly marked as unused when it only appeared in the generics, the
arguments, or the return type, whereas the same code in non-method
functions was correctly detected as used. Fixes#20343.
When trying to build against a newer, local LLVM version it might be
preferable to have a flag to disable the LLVM version check instead of
having to modify the configure script.
Fixes#21998
r? @alexcrichton
* Remove type parameters from `IteratorExt::cloned`
* Rename `IntoIterator::Iter` to `IntoIterator::IntoIter`
* Mark `IntoIterator::into_iter` as stable (but not the trait, only the method).
Crate types from multiple sources appear to be deduplicated properly, but not
deduplicated if they come from the command line arguments. At worst, this used
to cause compiler failures when `--crate-type=lib,rlib` (the same as
`--crate-type=rlib,rlib`, at least at the time of this commit) is provided and
generate the output multiple times otherwise.
r? @alexcrichton
Replace links to `../index.html` with `index.html` as they are linking to the `std` module and not `std::cell` as intended.
See for example [RefCell documentation](http://doc.rust-lang.org/std/cell/struct.RefCell.html).
I started to write up some docs on this, and then realized I was just repeating http://huonw.github.io/blog/2015/01/peeking-inside-trait-objects/ but worse. @huonw previously said that we can use this content if we wanted, so I made some tweaks and integrated it into the book.
Fixes#21707
Fixes#22091
I'm not sure how to write a test for this. An ICE happens with spans that start near (after?) a null character or some other zero-width unicode character.
Rename several remaining `Show`s to Debug, `String`s to Display (mostly in comments and docs).
Update reference.md:
- derive() no longer supports Zero trait
- derive() now supports Copy trait
- c-link-to-rust-staticlib: use `EXTRACFLAGS` defined by tools.mk for
choose the good libraries to link to.
tools.mk define a variable `EXTRACFLAGS` that contains the needed library per target. So it is better to use it, instead of duplicate the code here. I keep the `ifndef IS_WINDOWS` has tools.mk define something for WINDOWS... so I don't change things that I couldn't test.
- no-stack-check: disabled for openbsd (no segmented stacks here)
- symbols-are-reasonable: use portable grep pattern
- target-specs: use POSIX form for options when invoking grep
- use-extern-for-plugins: disable as OpenBSD only support x86_64 for now
When self.start > self.end, these iterators simply return None,
so we adjust the size_hint to just return zero in this case.
Certain optimizations can be implemented in and outside libstd if we
know we can trust the size_hint for all inputs to for example
Range<usize>.
This corrects the ExactSizeIterator implementations, which IMO were
unsound and incorrect previously, since they allowed a range like (2..1)
to return a size_hint of -1us in when debug assertions are turned off.
Given `<expr> as Box<Trait>`, infer that `Box<_>` is expected type for `<expr>`.
This is useful for addressing fallout from newly proposed box protocol; see #22006 for examples of such fallout, much of which will be unnecessary with this fix.
