Soon the LLVM upgrade (#34743) will require an updated CMake installation, and
the easiest way to do this was to upgrade the Ubuntu version of the bots to
16.04. This in turn brings in a new MIPS compiler on the linux-cross builder,
which is now from the "official" ubuntu repositories. Unfortunately these
new compilers don't support compiling with the `-msoft-float` flag like we're
currently passing, causing compiles to fail.
This commit removes these flags as it's not clear *why* they're being passed, as
the mipsel targets also don't have it. At least if it's not supported by a
debian default compiler, perhaps it's not too relevant to support?
1. Fix the sections in the book to have the correct signatures. I've
also marked them as `ignore`; there's no way to set the `no_std`
feature for libc, so it pulls in the stdlib, so this wasn't even
testing the actual thing it was testing. Better to just ignore.
2. Correcting libcore's docs for factual inaccuracy, and add a note
about language items.
Fixes#33677
Simplify the macro hygiene algorithm
This PR removes renaming from the hygiene algorithm and treats differently marked identifiers as unequal.
This change makes the scope of identifiers in `macro_rules!` items empty. That is, identifiers in `macro_rules!` definitions do not inherit any semantics from the `macro_rules!`'s scope.
Since `macro_rules!` macros are items, the scope of their identifiers "should" be the same as that of other items; in particular, the scope should contain only items. Since all items are unhygienic today, this would mean the scope should be empty.
However, the scope of an identifier in a `macro_rules!` statement today is the scope that the identifier would have if it replaced the `macro_rules!` (excluding anything unhygienic, i.e. locals only).
To continue to support this, this PR tracks the scope of each `macro_rules!` and uses it in `resolve` to ensure that an identifier expanded from a `macro_rules!` gets a chance to resolve to the locals in the `macro_rules!`'s scope.
This PR is a pure refactoring. After this PR,
- `syntax::ext::expand` is much simpler.
- We can expand macros in any order without causing problems for hygiene (needed for macro modularization).
- We can deprecate or remove today's `macro_rules!` scope easily.
- Expansion performance improves by 25%, post-expansion memory usage decreases by ~5%.
- Expanding a block is no longer quadratic in the number of `let` statements (fixes#10607).
r? @nrc
doc: ffi referenced rust-snappy can not compile
r? @steveklabnik
The referenced code https://github.com/thestinger/rust-snappy can not work. Maybe it's the old rust version? I do not know.
So I try to rewrite these test cases. If it is not what you originally meaning, just ignored it.
doc: Mention that writeln! and println! always use LF
Fixes#34697
I'm not really satisfied with the wording, but I didn't have a better idea. Suggestions welcome.
Improve arc doc, fixing #32905
As issue #32905 detailed, I moved part of the module doc to the struct doc, and fixed some small places in the `alloc::arc`.
rustbuild: doc fixes
This fixes two issues rustbuild currently has when building documentation:
1. It fixes standalone builds of `doc-test` and `doc-rustc`.
2. It actually builds the compiler docs if requested in the config.
Closes#34275.
Fixed issue where importing a trait method directly and then calling the method causes a compiler panic
The code below triggers the panic, and is included in a new regression test.
```rust
trait Foo {
fn foo();
}
use Foo::foo;
fn main() {
foo();
}
```
The bug is caused by `librustc_resolve` allowing the illegal binding to be imported even after displaying the error message above.
The fix amounts to importing a dummy binding (`rustc::hir::def::Def::Err`) instead of the actual trait method.
test: Remove NOTE assertions from trace_macros-gate
If no NOTE assertions are present I believe they aren't asserted at all, and it
looks like the number of NOTEs differs on distcheck vs `make check`, so let's
just remove them all.
Closes#18154
If no NOTE assertions are present I believe they aren't asserted at all, and it
looks like the number of NOTEs differs on distcheck vs `make check`, so let's
just remove them all.
Closes#18154
Mention the crate type cdylib in rustc's usage
Hello,
I just tried to build a `cdylib` with the latest stable release, I've been passively waiting for this for quite some time now. Tested successfully on my machine, although it doesn't appear in `rustc`'s usage it seems to work like a charm so far. 😀
Thanks!
std: fix `readdir` errors for solaris
A `NULL` from `readdir` could be the end of stream or an error. The only
way to know is to check `errno`, so it must be set to a known value first,
like a 0 that POSIX will never use.
This currently only matters for solaris targets, as the other unix platforms
are using `readdir_r` with a direct error return indication. However, this is
getting deprecated (#34668) so they should all eventually switch to `readdir`.
This PR adds `set_errno`, uses it to clear the value before calling `readdir`,
then checks it again after to see the reason for a `NULL`. A few other small
fixes are included just to get solaris compiling at all.
I couldn't get cross-compilation completely going, so I don't have a good way
to test this beyond a smoke-test cargo build of std. I'd appreciate input from
someone more familiar with solaris -- cc @nbaksalyar?
