Release note on #[macroescape] #5566
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I intend to do some big refactoring and don't want to deal w/ std just now
The bots were showing a segfault that I can't reproduce. Assuming it's varargs related so let's not use printf
No more mapping uv structs to Rust structs
This is an internal interface. I want to use rt::io for public interfaces.
Can make turnaround of testing changes to core/std/syntax much faster.
I can already see these are going to get massive. Putting them into multiple files.
TESTARGS=--newrt make check-stage1-rpass Conflicts: src/rt/rustrt.def.in
I don't want any global one-time initalization functions because that will make embedding harder.
… environment, and return pointer
I'm making this change because the _reverse suffix is more commonly used in libcore/libstd.
This is the first step in refactoring the deriving code in libsyntax. No code is changed, just rearranged.
…trans_call, r=graydon Refactor trans_call to separate out the translation of the arguments, environment, and return pointer. Towards rust-lang#3678. r? @brson
the assert_eq! macro compares its arguments and fails if they're not equal. It's more informative than fail_unless!, because it explicitly writes the given and expected arguments on failure.
The version recognition was failing for version 1.11, thinking the minor version was 1 rather than 11.
As per rust-lang#2521. Inlining seems to improve performance slightly: Inlined Not Inlined x86: 13.5482 14.4112 x86_64: 17.4712 18.0696 (Average of 5 runs timed with `time`) ```Rust fn foo() -> int { int::from_str(~"28098").unwrap() } fn main() { for 1000000.times { foo(); foo(); foo(); foo(); foo(); } } ``` All run on: Linux 3.2.0-0.bpo.4-amd64 rust-lang#1 SMP Debian 3.2.35-2~bpo60+1 x86_64 GNU/Linux The MIPS and ARM bits I didn't inline since I'm not as familiar with them and I also can't test them. All green on try.
Conflicts: src/libcore/rt/context.rs src/libcore/rt/sched.rs src/libcore/rt/thread.rs src/libcore/rt/uv.rs
r? There are a lot of commits here, but not all that much substance. Mostly just refactoring. I started sketching out the beginnings of a very simple I/O API in `core::rt::io` that represents I/O streams as a single `Stream` trait instead of `Reader` / `Writer` pairs. This seems to be the more common pattern (at least this is how the .NET BCL does it) and it seems to me that separate readers and writers would make duplex streams very awkward. Regardless, I don't intend to go very far down the I/O API design road without some mailing list discussion. I've also started on the uv bindings for file I/O but haven't gotten very far. Also hooked up the new scheduler to `rust_start` and the compiletest driver. 70% of run-pass test cases already pass, but I wouldn't read too much into that. I also split the direct, low-level uv bindings in two so that the scheduler can have its own set, leaving `std::net` on its own.
Just some editing-to-reflect-reality on release notes and manual.
The reasoning for doing it this way is that it's much easier to transition method-by-method to the `Map` API than trying to do the migration all at once. I found an issue unrelated to my changes in one of the run-fail tests - if it uses `LinearMap`, it still fails but exits with 0. I xfailed it for now and opened [an issue](rust-lang#5512), because it's not caused by these changes.
This removes some explicit implementations of `Eq` in favor of `#[deriving(Eq)]` and derives `Clone` for a few core types.
`let v = [24, ..1000];` now more or less emits the same IR as:
```Rust
let mut i = 0;
while i < 1000 {
v[i] = 24;
i += 1;
}
```
LLVM will still turn it into a memset if possible with optimization on.
Kills some warnings, and implements str::each_char_reverse so that it actually iterates. The test case wasn't detecting a failure, since the loop body was never executed.
This currently requires workarounds for the borrow checker not being flow-sensitive for `LinearMap` and `TrieMap`, but it can already be expressed for `TreeMap` and `SmallIntMap` without that.
In order to mitigate typo of target-triples, error notification of unsupported target triples which defined in mk/platform.mk added. minor fix for arm-linux-androideabi added.
…r=brson The version recognition was failing for pandoc version 1.11, thinking the minor version was 1 rather than 11, and thus not building the documentation.
…n, r=catamorphism r? @catamorphism
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
May 11, 2020
Update to rustc changes
changelog: none
So, turns out `git subtree push` dies in various interesting ways, but the source cause is that the rustc repo looks like
```
--- A --- B --- C ---
\--- D ---/
```
where `B` is the commit where I added clippy to rustc and `D` is an arbitrary other PR and `C` is the master branch (or an earlier commit in it). When we now do `git subtree push`, it doesn't stop looking for things to merge at `B` as it needs to look at `D`, too, but then the bad thing happens, and it doesn't stop at `A` either, and just goes on looking at the entire history of rustc in a recursive bash script. That recursion then quickly runs into a stack overflow. While we can increase the stack size via `ulimit -s 60000`, that just means I was waiting for 30 minutes looking at `git subtree push` counting up the number of commits it has looked at. I aborted that, as a process that needs 30 mins for a push is not reasonable.
This PR cheats by just doing a `cp -r ../rustc/src/tools/clippy/* .` inside my clippy checkout and committing all changes. I'm working on getting us a better workflow, but until then, this workaround will work nicely. Note that this requires a `git subrepo pull` to have occurred in the `rustc` checkout. It's not necessary to merge that pull in order to update clippy, it's just necessary in order to not revert code in the clippy repo that hasn't been synced yet to the rustc repo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.