Don't use skolemized parameters but rather fresh variables in coherence. Skolemized parameters wind up preventing unification. Surprised we had no test for this! Fixes#24241.
r? @pnkfelix
Example showing sample inputs, old message, new message:
https://gist.github.com/nikomatsakis/11126784ac678b7eb6ba
Also adds infrastructure for reporting suggestions \"in situ\" and does some (minor) cleanups to `CodeMap`.
r? @brson
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).
I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
r? @brson
I'm using this to integrate rustc with [american-fuzzy-lop](http://lcamtuf.coredump.cx/afl/). Building with afl instrumentation is no different from loading any other plugin library.
I'd like this PR to include a `run-make` test with a custom LLVM pass; however I'm not sure it's worth the trouble of building C++ code and linking LLVM from the test suite (are there existing tests that do this?)
Modify the ExprUseVisitor to walk each part of an AutoRef, and in
particular to treat an AutoUnsize as as kind of \"instantaneous\" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a \"double AutoRef\", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that \"eager reborrow\" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
Fixes#20791.
r? @nrc
I've taken another look at extended errors - fixing up the printing and adding a few more for match expressions.
With regards to printing, the previous behaviour was to just print the error message string directly, despite it containing indentation which caused it to overflow the standard terminal width of 80 columns (try `rustc --explain E0004`). The first approach I considered was to strip the leading whitespace from each line and lay out the text dynamically, inserting spaces in between. This approach became quite messy when taking multi-paragraph errors into account (and seemed overkill). The approach I settled on removes the indentation in the string itself and begins each message with a newline that is stripped before printing.
I feel like complete extended errors would be nice to have for 1.0.0 and I'm happy to spearhead an effort to get them written. Brian got me onto writing them at an SF meetup and I think it shouldn't be too hard to get the remaining 80 or so written with the help of people who don't really work on compiler innards.
particular to treat an AutoUnsize as as kind of "instantaneous" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a "double AutoRef", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that "eager reborrow" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
Encode more precise scoping rules for function params
Function params outlive everything in the body (incl temporaries). Thus if we assign them their own `CodeExtent`, the region inference can properly show that it is sound to have temporaries with destructors that reference the parameters (because such temporaries will be dropped before the parameters are dropped).
Fix#23338
* All bounds are now discovered through the trait to be inlined.
* The `?Sized` bound now renders correctly for inlined associated types.
* All `QPath`s (`<A as B>::C`) instances are rendered as `A::C` where `C` is a
hyperlink to the trait `B`. This should improve at least how the docs look at
least.
* Supertrait bounds are now separated and display as the source lists them.
Closes#20727Closes#21145
In addition to being nicer, this also allows you to use `sum` and `product` for
iterators yielding custom types aside from the standard integers.
Due to removing the `AdditiveIterator` and `MultiplicativeIterator` trait, this
is a breaking change.
[breaking-change]
Hello!
I've been working towards a libsyntax without panics. See:
http://internals.rust-lang.org/t/changing-libsyntax-to-use-result-instead-of-panic/1670
This patch changes the internals of parser.rs to use Result<> rather than panicing. It keeps the following old-style panicing functions as a facade:
parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
I left these functions because I wasn't sure what to do about the quote_* macros or how many syntax-extensions would break if these and quoting macros returned Result.
The gyst of the rest of the patch is:
- Functions in parse/parser.rs return PResult<> rather than panicing
- Other functions in libsyntax call panic! explicitly if they rely on panicing behaviour.
- I added a macro 'panictry!()' to act as scaffolding for callers while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()).
Am I on the right track? I'd quite like to get something merged soon as keeping this rebased in the face of libsyntax changes is a lot of work. Please let me know what changes you'd like to see to make this happen.
Thanks!, Phil
`Trait`, prefer the object. Also give a nice error for attempts to
manually `impl Trait for Trait`, since they will be ineffectual.
Fixes#24015.
Fixes#24051.
Fixes#24037.
Fixes#23853.
Fixes#21942.
cc #21756.
- Functions in parser.rs return PResult<> rather than panicing
- Other functions in libsyntax call panic! explicitly for now if they rely on panicing behaviour.
- 'panictry!' macro added as scaffolding while converting panicing functions.
(This does the same as 'unwrap()' but is easier to grep for and turn into try!())
- Leaves panicing wrappers for the following functions so that the
quote_* macros behave the same:
- parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
Function params which outlive everything in the body (incl
temporaries). Thus if we assign them their own `CodeExtent`, the
region inference can properly show that it is sound to have
temporaries with destructors that reference the parameters (because
such temporaries will be dropped before the parameters are).
This allows us to address issue 23338 in a clean way.
As a drive-by, fix a mistake in the tyencode for
`CodeExtent::BlockRemainder`.
There are still some remnants we could remove from the compiler (e.g. references to "subtraitrefs"; traits still have variance entries in the variance table), but this removes all user-visible bits I believe.
r? @pnkfelix
Fixes#22806 (since such traits would no longer exist)
These constants are small and can fit even in `u8`, but semantically they have type `usize` because they denote sizes and are almost always used in `usize` context. The change of their type to `u32` during the integer audit led only to the large amount of `as usize` noise (see the second commit, which removes this noise).
This is a minor [breaking-change] to an unstable interface.
r? @aturon
