惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Hackread – Cybersecurity News, Data Breaches, AI and More
C
Check Point Blog
Hacker News: Ask HN
Hacker News: Ask HN
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
WordPress大学
WordPress大学
P
Proofpoint News Feed
V
Visual Studio Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
N
Netflix TechBlog - Medium
C
CXSECURITY Database RSS Feed - CXSecurity.com
博客园 - 聂微东
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
博客园 - 叶小钗
Cisco Talos Blog
Cisco Talos Blog
S
Schneier on Security
T
Threat Research - Cisco Blogs
腾讯CDC
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
The Hacker News
The Hacker News
Google DeepMind News
Google DeepMind News
Microsoft Security Blog
Microsoft Security Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
GbyAI
GbyAI
N
News | PayPal Newsroom
L
LINUX DO - 最新话题
酷 壳 – CoolShell
酷 壳 – CoolShell
P
Palo Alto Networks Blog
T
Tenable Blog
S
Secure Thoughts
T
Threatpost
V2EX - 技术
V2EX - 技术
大猫的无限游戏
大猫的无限游戏
Martin Fowler
Martin Fowler
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Vercel News
Vercel News
罗磊的独立博客
P
Privacy & Cybersecurity Law Blog
Engineering at Meta
Engineering at Meta
小众软件
小众软件
Google DeepMind News
Google DeepMind News
N
News and Events Feed by Topic
Y
Y Combinator Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
C
Cybersecurity and Infrastructure Security Agency CISA
P
Proofpoint News Feed
L
Lohrmann on Cybersecurity
P
Privacy International News Feed
H
Heimdal Security Blog
量子位
B
Blog

Rust Blog

Security Advisory for Cargo (CVE-2026-5223) | Rust Blog Security Advisory for Cargo (CVE-2026-5222) | Rust Blog Project goals update — April 2026 (end of 2025H2) | Rust Blog Rust is participating in Outreachy | Rust Blog Raising the baseline for the `nvptx64-nvidia-cuda` target | Rust Blog Announcing Google Summer of Code 2026 selected projects | Rust Blog Announcing Rust 1.95.0 | Rust Blog docs.rs: building fewer targets by default | Rust Blog Changes to WebAssembly targets and handling undefined symbols | Rust Blog Announcing Rust 1.94.1 | Rust Blog Security advisory for Cargo | Rust Blog What we heard about Rust's challenges | Rust Blog Call for Testing: Build Dir Layout v2 | Rust Blog Announcing rustup 1.29.0 | Rust Blog Announcing Rust 1.94.0 | Rust Blog 2025 State of Rust Survey Results | Rust Blog Rust debugging survey 2026 | Rust Blog Update on the October 15, 2018 incident on crates.io Announcing Rust 1.29.2 Announcing Rust 1.29 Launching the 2018 State of Rust Survey Announcing Rust 1.28 What is Rust 2018? Announcing Rust 1.27.2 Announcing Rust 1.27.1 Security Advisory for rustdoc Announcing Rust 1.27 Announcing Rust 1.26.2 Announcing Rust 1.26.1 Rust turns three Announcing Rust 1.26 The Rust Team All Hands in Berlin: a Recap Increasing Rust’s Reach 2018 Announcing Rust 1.25 Rust's 2018 roadmap Announcing Rust 1.24.1 Announcing Rust 1.24 The 2018 Rust Event Lineup Announcing Rust 1.23 New Year's Rust: A Call for Community Blogposts Rust in 2017: what we achieved Announcing Rust 1.22 (and 1.22.1) Fearless Concurrency in Firefox Quantum Announcing Rust 1.21 impl Future for Rust Rust 2017 Survey Results Announcing Rust 1.20 Announcing Rust 1.19 The 2017 Rust Conference Lineup Rust's 2017 roadmap, six months in Increasing Rust’s Reach Announcing Rust 1.18 Two years of Rust The Rust Libz Blitz Launching the 2017 State of Rust Survey Announcing Rust 1.16 Rust's language ergonomics initiative Announcing Rust 1.15.1 Rust's 2017 roadmap Announcing Rust 1.15 Announcing Rust 1.14 Announcing the First Underhanded Rust Contest Announcing Rust 1.13 Announcing Rust 1.12.1 Announcing Rust 1.12 Incremental Compilation Announcing Rust 1.11 Shape of errors to come The 2016 Rust Conference Lineup Announcing Rust 1.10 State of Rust Survey 2016 Announcing Rust 1.9 One year of Rust Taking Rust everywhere with rustup Launching the 2016 State of Rust Survey Cargo: predictable dependency management Introducing MIR Announcing Rust 1.8 Announcing Rust 1.7 Announcing Rust 1.6 Announcing Rust 1.5 Announcing Rust 1.4 Announcing Rust 1.3 Rust in 2016 Announcing Rust 1.2 Rust 1.1 stable, the Community Subteam, and RustCamp Announcing Rust 1.0 Abstraction without overhead: traits in Rust Rust Once, Run Everywhere Mixing matching, mutation, and moves in Rust Fearless Concurrency with Rust Announcing Rust 1.0 Beta Announcing Rust 1.0.0.alpha.2 Rust 1.0: status report and final timeline Announcing Rust 1.0 Alpha Rust 1.0: Scheduling the trains Yehuda Katz and Steve Klabnik are joining the Rust Core Team Cargo: Rust's community crate host Stability as a Deliverable Road to Rust 1.0
Announcing Rust 1.17
The Rust Core Team · 2017-04-27 · via Rust Blog

The Rust team is happy to announce the latest version of Rust, 1.17.0. Rust is a systems programming language focused on safety, speed, and concurrency.

If you have a previous version of Rust installed, getting Rust 1.17 is as easy as:

$ rustup update stable

If you don't have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.17.0 on GitHub.

What's in 1.17.0 stable

The story of Rust 1.17.0 is mostly one of small, quality of life improvements. For example, the 'static lifetime is now assumed in statics and consts. When writing a const or static like this:

const NAME: &'static str = "Ferris";
static NAME: &'static str = "Ferris";

Rust 1.17 will allow you to elide the 'static, since that's the only lifetime that makes sense:

const NAME: &str = "Ferris";
static NAME: &str = "Ferris";

In some situations, this can remove lots of boilerplate:

// old
const NAMES: &'static [&'static str; 2] = &["Ferris", "Bors"];

// new
const NAMES: &[&str; 2] = &["Ferris", "Bors"];

Another similar improvement is "field init shorthand." Similar to ECMAScript 6, which calls this "Object Literal Property Value Shorthand", duplication can be removed when declaring structs, like this:

// definitions
struct Point {
    x: i32,
    y: i32,
}

let x = 5;
let y = 6;

// old
let p = Point {
    x: x,
    y: y,
};

// new
let p = Point {
    x,
    y,
};

That is, the x, y form will assume that its values are set to a variable with the same name in its scope.

For another small quality of life improvement, it's common for new Rustaceans to try to use + to add two &strs together. This doesn't work, you can only add String + &str. As such, a new error message was added to help users who make this mistake:

// code
"foo" + "bar"

// old
error[E0369]: binary operation `+` cannot be applied to type `&'static str`
 --> <anon>:2:5
  |
2 |     "foo" + "bar"
  |     ^^^^^
  |
note: an implementation of `std::ops::Add` might be missing for `&'static str`
 --> <anon>:2:5
  |
2 |     "foo" + "bar"
  |     ^^^^^

// new
error[E0369]: binary operation `+` cannot be applied to type `&'static str`
 --> <anon>:2:5
  |
2 |     "foo" + "bar"
  |     ^^^^^
  |
  = note: `+` can't be used to concatenate two `&str` strings
help: to_owned() can be used to create an owned `String` from a string
reference. String concatenation appends the string on the right to the string on
the left and may require reallocation. This requires ownership of the string on
the left.
  |     "foo".to_owned() + "bar"

When using Cargo's build scripts, you must set the location of the script in your Cargo.toml. However, the vast majority of people wrote build = "build.rs", using a build.rs file in the root of their project. This convention is now encoded into Cargo, and will be assumed if build.rs exists. We've been warning about this change for the past few releases, and you can use build = false to opt out.

This release marks the removal of the old Makefile based build system. The new system, announced in Rust 1.15, is written in Rust and primarily uses Cargo to drive the build. It is now mature enough to be the only build system.

As part of that change, packages from crates.io can now be used within Rust's build system. The first one to be added was mdBook, and it's now being used to render our various book-like documentation:

In addition, see those links to their respective repositories; they've been moved out of tree. Also, we've added a fourth book, still in-tree: The Unstable Book. This provides an overview of unstable features by name, contains links to their tracking issues, and may contain initial documentation. If there's a feature you want to see stabilized, please get involved on its tracking issue!

A few releases ago, rustup stopped installing documentation by default. We made this change to save some bandwidth and because not all users want a copy of the documentation locally. However, this created a pitfall: some users did not realize that this changed, and would only notice once they were no longer connected to the internet. In addition, some users did want to have a local copy of the docs, regardless of their connectivity. As such, we've reverted the change, and documentation is being installed by default again.

Finally, while this release is full of improvements, there is one small step back we want to regretfully inform you about. On Windows, Visual Studio 2017 has been released, and Microsoft has changed the structure of how the software is installed. Rust cannot automatically detect this location, and while we were working on the necessary changes, they did not make it in time for this release. Until then, Visual Studio 2015 still works fine, or you can run vcvars.bat on the command line. We hope to make this work in a seamless fashion soon.

See the detailed release notes for more.

Library stabilizations

19 new bits of API were stabilized this release:

In other changes, Cell<T> used to require that T: Copy for many of its methods, but this has been relaxed significantly.

Box<T> now implements over a dozen new conversions with From.

SocketAddr and IpAddr have some new conversions as well. Previously, you may have written code like this:

"127.0.0.1:3000".parse().unwrap()

Now, you can write

SocketAddr::from(([127, 0, 0, 1], 3000))
// or even
([127, 0, 0, 1], 3000).into()

This removes some unnecessary run-time parsing, and is roughly as readable, depending on your preferences.

Backtraces now have nicer formatting, eliding some things by default. For example, the full backtrace:

thread 'main' panicked at 'explicit panic', foo.rs:2
stack backtrace:
   1:     0x55c39a23372c - std::sys::imp::backtrace::tracing::imp::write::hf33ae72d0baa11ed
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x55c39a23571e - std::panicking::default_hook::{{closure}}::h59672b733cc6a455
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x55c39a235324 - std::panicking::default_hook::h1670459d2f3f8843
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:367
   4:     0x55c39a235afb - std::panicking::rust_panic_with_hook::hcf0ddb069e7beee7
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x55c39a22e866 - std::panicking::begin_panic::heb433e9aa28a7408
   6:     0x55c39a22e9bf - foo::main::hd216d4a160fcce19
   7:     0x55c39a23d44a - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
   8:     0x55c39a236006 - std::rt::lang_start::hd7c880a37a646e81
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panicking.rs:436
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/panic.rs:361
                        at /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libstd/rt.rs:57
   9:     0x55c39a22e9e9 - main
  10:     0x7f5e5ed3382f - __libc_start_main
  11:     0x55c39a22e6b8 - _start
  12:                0x0 - <unknown>

is now instead

thread 'main' panicked at 'explicit panic', foo.rs:2
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:371
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
   6: foo::main
   7: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
   8: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:433
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:57
   9: main
  10: __libc_start_main
  11: _start

By default. You can set the environment variable RUST_BACKTRACE=full to get the full backtrace. We may be able to do more cleanup in the future; see this bug for more.

See the detailed release notes for more.

Cargo features

Other than the previously mentioned build.rs changes, Cargo has a few new improvements. cargo check --all and cargo run --package are two missing flags that are now supported.

You can now opt in to ignoring SSL revocation checks. The default is still to check, of course.

A new field in Cargo.toml, required-features, lets you specify specific features that must be set for a target to be built. Here's an example: let's say that we are writing a crate that interacts with databases, and that we support multiple databases. We might have this in our Cargo.toml:

[features]
# ...
postgres = []
sqlite = []
tools = []

The tools feature allows us to include extra tooling, and the postgres and sqlite features control which databases we want to support.

Previously, cargo build would attempt to build all targets, which is normally what you want. But what if we had a src/bin/postgres-tool.rs, that would only really be relevant if the postgres and tools features would be enabled? Previously, we would have to write something like this:

#[cfg(not(all(feature = "postgres", feature = "tools")))]
fn main() {
    println!("This tool requires the `postgres` and `tools` features to be enabled.");
}

#[cfg(all(feature = "postgres", feature = "tools"))]
fn main() {
    // real code
}

This is a lot of boilerplate to work around cargo build's behavior. It's even more unfortunate with examples/, which are supposed to show off how to use your library, but this shenanigans is only relevant within the package, not if you were to try to use the example on your own.

With the new required-features key, we can add this:

[[bin]]
# ...
required-features = ["postgres", "tools"]

Now, cargo build will only build our postgres-tool if we have the two features set, and so we can write a normal fn main without all the cfg nonsense getting in the way.

See the detailed release notes for more.

Contributors to 1.17.0

Many people came together to create Rust 1.17. We couldn't have done it without all of you. Thanks!