new error style:
```
path.rs:4:6: 4:7 error: the trait `core::marker::Sized` is not implemented for the type `[u8]` [E0277]
path.rs:4 fn f(p: Path) {}
^
path.rs:4:6: 4:7 help: run `rustc --explain E0277` to see a detailed explanation
path.rs:4:6: 4:7 note: `[u8]` does not have a constant size known at compile-time
path.rs:4:6: 4:7 note: required because it appears within the type `std::sys::os_str::Slice`
path.rs:4:6: 4:7 note: required because it appears within the type `std::ffi::os_str::OsStr`
path.rs:4:6: 4:7 note: required because it appears within the type `std::path::Path`
path.rs:4:6: 4:7 note: all local variables must have a statically known size
path.rs:7:5: 7:36 error: the trait `core::marker::Send` is not implemented for the type `alloc::rc::Rc<()>` [E0277]
path.rs:7 foo::<BTreeMap<Rc<()>, Rc<()>>>();
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
path.rs:7:5: 7:36 help: run `rustc --explain E0277` to see a detailed explanation
path.rs:7:5: 7:36 note: `alloc::rc::Rc<()>` cannot be sent between threads safely
path.rs:7:5: 7:36 note: required because it appears within the type `collections::btree::node::Node<alloc::rc::Rc<()>, alloc::rc::Rc<()>>`
path.rs:7:5: 7:36 note: required because it appears within the type `collections::btree::map::BTreeMap<alloc::rc::Rc<()>, alloc::rc::Rc<()>>`
path.rs:7:5: 7:36 note: required by `foo`
error: aborting due to 2 previous errors
```
This improves the #21793/#23286 situation
There is a dead code in libsyntax/parser/parse.rs, when parsing structs.
Two functions are involved:
* [parse_item_struct](cd9c9f048f/src/libsyntax/parse/parser.rs (L4691))
* [parse_tuple_struct_body](cd9c9f048f/src/libsyntax/parse/parser.rs (L4769))
The problem is that both functions handle the case with unit structs. But because
`parse_tuple_struct_body` is called from `parse_item_struct`, it never faces
this case.
This PR removes unit struct case from `parse_tuple_struct_body` function. I tested with `make -j8 check-statge1`.
Commit 9104a902c0 fixed the generated
files, but that change would be lost (or require additional manual
intervention) if they are re-generated of if new architectures are
added.
cc #28273
This is something that I wish I had when I started contributing to Rust (not that long ago :). I plan on writing a manual for bors and the rust testing setup too, if there isn't one already.
- Headlines begin at 1st level now like the rest of the book
- All Headlines a blank line above and below
- Fix links in this chapter's TOC
r? @steveklabnik
Commit 9104a902c0 fixed the generated
files, but that change would be lost (or require additional manual
intervention) if they are re-generated of if new architectures are
added.
cc #28273
Redirect stdout on the python bogosity detector. This is printing
pwd to the terminal currently.
Reformat the bogus python/cmake messages so they format correctly.
echo does not always escape newlines (it doesn't here), and multiline
strings don't whitespace munch.
r? @alexcrichton
Redirect stdout on the python bogosity detector. This is printing
pwd to the terminal currently.
Reformat the bogus python/cmake messages so they format correctly.
echo does not always escape newlines (it doesn't here), and multiline
strings don't whitespace munch.
This commit does some refactoring to make almost all of the `std::rt` private.
Specifically, the following items are no longer part of its API:
* DEFAULT_ERROR_CODE
* backtrace
* unwind
* args
* at_exit
* cleanup
* heap (this is just alloc::heap)
* min_stack
* util
The module is now tagged as `#[doc(hidden)]` as the only purpose it's serve is
an entry point for the `panic!` macro via the `begin_unwind` and
`begin_unwind_fmt` reexports.
This commit does some refactoring to make almost all of the `std::rt` private.
Specifically, the following items are no longer part of its API:
* DEFAULT_ERROR_CODE
* backtrace
* unwind
* args
* at_exit
* cleanup
* heap (this is just alloc::heap)
* min_stack
* util
The module is now tagged as `#[doc(hidden)]` as the only purpose it's serve is
an entry point for the `panic!` macro via the `begin_unwind` and
`begin_unwind_fmt` reexports.
When the inliner has to decided if it wants to inline a function A into an
internal function B, it first checks whether it would be more profitable
to inline B into its callees instead. This means that it has to analyze
B, which involves checking the assumption cache. Building the assumption
cache requires scanning the whole function, and because inlining
currently clears the assumption cache, this scan happens again and
again, getting even slower as the function grows from inlining.
As inlining the huge find functions isn't really useful anyway, we can
mark them as noinline, which skips the cost analysis and reduces compile
times by as much as 70%.
cc #28273
When the inliner has to decided if it wants to inline a function A into an
internal function B, it first checks whether it would be more profitable
to inline B into its callees instead. This means that it has to analyze
B, which involves checking the assumption cache. Building the assumption
cache requires scanning the whole function, and because inlining
currently clears the assumption cache, this scan happens again and
again, getting even slower as the function grows from inlining.
As inlining the huge find functions isn't really useful anyway, we can
mark them as noinline, which skips the cost analysis and reduces compile
times by as much as 70%.
cc #28273
llvm seems to be having some trouble optimizing the iterator-based string comparsion method into some equivalent to memcmp. This explicitly calls out to the memcmp intrinisic in order to allow llvm to generate better code. In some manual benchmarking, this memcmp-based approach is 20 times faster than the iterator approach.
llvm seems to be having some trouble optimizing the iterator-based
string comparsion method into some equivalent to memcmp. This
explicitly calls out to the memcmp intrinisic in order to allow
llvm to generate better code. In some manual benchmarking, this
memcmp-based approach is 20 times faster than the iterator approach.
under OpenBSD, it could be have present multiples versions of gcc compiler:
- gcc-4.2 (with patchs) : c/c++ compiler present in `/usr/bin`. It is unusable to build recent LLVM (so rustc too).
- gcc/g++ -4.9 : c/c++ compiler, installed as third-party with "ports" mechanism. The compiler is installed in `/usr/local` as `egcc` (and `eg++`).
this PR adds probing for `egcc` for `CFG_GCC`, if the first probed `gcc` is too old. It will set `CC` and `CXX` too, in order to pass the variables to LLVM configure if builded.
please note this PR is a first step in order to build rustc under OpenBSD with unpatched tree.
r? @alexcrichton
cc @brson @dhuseby
