Changes in codegen.rs

4a168844 - Fix some minor `bindgen!` issues with `anyhow: true` (#12657)

Tue, 24 Feb 2026 23:36:26 +0000

Fix some minor `bindgen!` issues with `anyhow: true` (#12657)* Fix some minor `bindgen!` issues with `anyhow: true`Found when updating Spin to Wasmtime 42.0.0 where some cases weren'thandled:* Trappable functions with no result.* Resource destructors.* Functions with custom trappable errors.* Shuffle some features List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

8c03849b - Use `.` instead of `/` for interface members. (#11947)

Mon, 27 Oct 2025 21:23:36 +0000

Use `.` instead of `/` for interface members. (#11947)* Use `.` instead of `/` for interface members.In the `wasmtime::component::generate` macro, change the syntax forreferencing functions and types inside interfaces to use `.` insteadof `/`.For example, this changes strings like `wasi:http/types/outgoing-body`to `wasi:http/types.outgoing-body`.This makes the syntax more consistent with the syntax of[WIT `use` statements], which use `.` for this purpose.And, it avoids an incompatibility with the future nested namespaces syntax([��]), where the `/d` in `a:b/c/d` is for traversing a component exportrather than an interface member.[WIT `use` statements]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#wit-packages-and-use[��]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#gated-features* Use the new syntax in more places.* Revert changes to vendored WIT files.* Revert more changes to vendored files.* Update syntax in more places. List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

4dd4b890 - Fix(wit_bindgen): use declared defaults to decide on `Send` Bounds in `Wastime::world_add_to_linker` (#11761)

Wed, 01 Oct 2025 14:15:35 +0000

Fix(wit_bindgen): use declared defaults to decide on `Send` Bounds in `Wastime::world_add_to_linker` (#11761)* feat: make FonctionConfig.default pub(crate)Signed-off-by: Antoine Lavandier * fix: use declared imports/exports defaults when deciding on Send boundsSigned-off-by: Antoine Lavandier * fix: add Send bound on relevant test outputSigned-off-by: Antoine Lavandier * fix(tests): add test using imports to define send boundsSigned-off-by: Antoine Lavandier * fix(fmt): make rustfmt happySigned-off-by: Antoine Lavandier * fix(fmt): actually make rustfmt happy this timeSigned-off-by: Antoine Lavandier ---------Signed-off-by: Antoine Lavandier List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

9f47be2e - Support store-access in `bindgen!` generated imports (#11628)

Fri, 05 Sep 2025 21:28:49 +0000

Support store-access in `bindgen!` generated imports (#11628)* Support store-access in `bindgen!` generated importsThis commit adds support to accessing the store in `bindgen!`-generatedimport functions in traits. Since the inception of `bindgen!` this hasnever been possible and access to the store requires manually workingwith `Linker`, for example. This is not easy to do because it requiressurgically editing code or working around what bindings generation partsyou do want.The implementation here is a small step away from whatcomponent-model-async has already implemented for async functions.Effectively it's a small extension of the `*WithStore` traits to alsohave synchronous functions with `Access` parameters instead of `async`functions with an `Accessor` parameter.This is something we're going to want for the WASIp3 implementationwhere I've noticed some resource destructors are going to want access tothe store to close out streams and such and this'll provide the bindingsnecessary for that.Closes #11590* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

1155d6df - Redesign function configuration in `bindgen!` (#11328)

Mon, 28 Jul 2025 18:31:06 +0000

Redesign function configuration in `bindgen!` (#11328)* Redesign function configuration in `bindgen!`This commit is a redesign of how function-level configuration works inWasmtime's `bindgen!` macro. The main goal of this redesign is tobetter support WASIp3 and component model async functions. Prior to thisredesign there was a mish mash of mechanisms to configure behavior ofimports/exports:* The `async` configuration could turn everything async, nothing async, only some imports async, or everything except some imports async.* The `concurrent_{imports,exports}` keys were required to explicitly opt-in to component model async signatures and applied to all imports/exports.* The `trappable_imports` configuration would indicate a list of imports allowed to trap and it had special configuration for everything, nothing, and only a certain list.* The `tracing` and `verbose_tracing` keys could be applied to either nothing or all functions.Overall the previous state of configuration in `bindgen!` was clearly ahodgepodge of systems that organically grew over time. In my personalopinion it was in dire need of a refresh to take into account howcomponent-model-async ended up being implemented as well asconsolidating the one-off systems amongst all of these configurationkeys. A major motivation of this redesign, for example, was to inheritbehavior from WIT files by default. An `async` function in WIT shouldnot require `concurrent_*` keys to be configured, but rather it shouldgenerate correct bindings by default.In this commit, all of the above keys were removed. All keys have beenreplaced with `imports` and `exports` configuration keys. Each behavesthe same way and looks like so: bindgen!({ // ... imports: { // enable tracing for just this function "my:local/interface/func": tracing, // enable verbose tracing for just this function "my:local/interface/other-func": tracing | verbose_tracing, // this is blocking in WIT, but generate async bindings for // it "my:local/interface/[method]io.block": async, // like above, but use "concurrent" bindings which have // access to the store. "my:local/interface/[method]io.block-again": async | store, // everything else is, by default, trappable default: trappable, }, });Effectively all the function-level configuration items are now bitflags.These bitflags are by default inherited from the WIT files itself (e.g.`async` functions are `async | store` by default). Further configurationis then layered on top at the desires of the embedder. Supported keys are:* `async` - this means that a Rust-level `async` function should be generated. This is either `CallStyle::Async` or `CallStyle::Concurrent` as it was prior, depending on ...* `store` - this means that the generated function will have access to the store on the host. This is only implemented right now for `async | store` functions which map to `CallStyle::Concurrent`. In the future I'd like to support just-`store` functions which means that you could define a synchronous function with access to the store in addition to an asynchronous function.* `trappable` - this means that the function returns a `wasmtime::Result`. If `trappable_errors` is applicable then it means just a `Result` is returned (like before)* `tracing` - this enables `tracing!` integration for this function.* `verbose_tracing` - this logs all argument values for this function (including lists).* `ignore_wit` - this ignores the WIT-level defaults of the function (e.g. ignoring WIT `async`).The way this then works is all modeled is that for any WIT functionbeing generated there are a set of flags associated with that function.To calculate the flags the algorithm looks like:1. Find the first matching rule in the `imports` or `exports` map depending on if the function is imported or exported. If there is no matching rule then use the `default` rule if present. This is the initial set of flags for the function (or empty if nothing was found).2. If `ignore_wit` is present, return the flags from step 1. Otherwise add in `async | store` if the function is `async` in WIT.The resulting set of flags are then used to control how everything isgenerated. For example the same split traits of today are stillgenerated and it's controlled based on the flags. Note though that theprevious `HostConcurrent` trait was renamed to `HostWithStore` to makespace for synchronous functions in this trait in the future too.The end result of all these changes is that configuring imports/exportsnow uses the exact same selection system as the `with` replacement map,meaning there's only one system of selecting functions instead of 3.WIT-level `async` is now respected by default meaning that bindings workby default without further need to configure anything (unless morefunctionality is desired).One final minor change made here as well is that auto-generated`instantiate` methods are now always synchronous and an`instantiate_async` method is unconditionally generated for async mode.This means that bindings always generate both functions and it's up tothe embedder to choose the appropriate one.Closes #11246Closes #11247* Update expanded test expectationsprtest:full* Fix the min platform embedding example* Fix doc tests* Always generate `*WithStore` traitsThis helps when using the `with` mapping since that can always assumethat `HostWithStore` is available in the generated bindings, avoidingthe need to duplicate configuration options.* Update test expectations* Review comments List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

beca86b0 - Re-enable concurrent bindings generation tests (#10972)

Mon, 09 Jun 2025 14:15:18 +0000

Re-enable concurrent bindings generation tests (#10972)* Re-enable concurrent bindings generation testsThis commit re-enables tests for bindings generation for concurrentcalls in the main repo after all syncs have now finished with wasip3.This additionally adds some skeleton APIs that the bindings generatoruses which are necessary to get tests passing.* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

f6775a33 - Replace `GetHost` with a function pointer, add `HasData` (#10770)

Tue, 13 May 2025 05:47:01 +0000

Replace `GetHost` with a function pointer, add `HasData` (#10770)* Replace `GetHost` with a function pointer, add `HasData`This commit is a refactoring to the fundamentals of the `bindgen!` macroand the functions that it generates. Prior to this change thefundamental entrypoint generated by `bindgen!` was a function`add_to_linker_get_host` which takes a value of type `G: GetHost`. This`GetHost` implementation is effectively an alias for a closure whosereturn value is able to close over the parameter given lfietime-wise.The `GetHost` abstraction was added to Wasmtime originally to enableusing any type that implements `Host` traits, not just `&mut U` as wasoriginally supported. The definition of `GetHost` was _just_ right toenable a type such as `MyThing<&mut T>` to implement `Host` and aclosure could be provided that could return it. At the time that`GetHost` was added it was known to be problematic from anunderstandability point of view, namely:* It has a non-obvious definition.* It's pretty advanced Rust voodoo to understand what it's actually doing* Using `GetHost` required lots of `for<'a> ...` in places which is unfamiliar syntax for many.* `GetHost` values couldn't be type-erased (e.g. put in a trait object) as we couldn't figure out the lifetime syntax to do so.Despite these issues it was the only known solution at hand so we landedit and kept the previous `add_to_linker` style (`&mut T -> &mut U`) as aconvenience. While this has worked reasonable well (most folks just tryto not look at `GetHost`) it has reached a breaking point in the WASIp3work.In the WASIp3 work it's effectively now going to be required that the`G: GetHost` value is packaged up and actually stored inside ofaccessors provided to host functions. This means that `GetHost` valuesnow need to not only be taken in `add_to_linker` but additionallyprovided to the rest of the system through an "accessor". This was madepossible in #10746 by moving the `GetHost` type into Wasmtime itself (asopposed to generated code where it lived prior).While this worked with WASIp3 and it was possible to plumb `G: GetHost`safely around, this ended up surfacing more issues. Namely all"concurrent" host functions started getting significantly morecomplicated `where` clauses and type signatures. At the end of the day Ifelt that we had reached the end of the road to `GetHost` and wanted tosearch for alternatives, hence this change.The fundamental purpose of `GetHost` was to be able to express, in ageneric fashion:* Give me a closure that takes `&mut T` and returns `D`.* The `D` type can close over the lifetime in `&mut T`.* The `D` type must implement `bindgen!`-generated traits.A realization I had was that we could model this with a genericassociated type in Rust. Rust support for generic associated types isrelatively new and not something I've used much before, but it ended upbeing a perfect model for this. The definition of the new `HasData`trait is deceptively simple: trait HasData { type Data<'a>; }What this enables us to do though is to generate `add_to_linker`functions that look like this: fn add_to_linker( linker: &mut Linker, getter: fn(&mut T) -> D::Data<'_>, ) -> Result<()> where D: HasData, for<'a> D::Data<'a>: Host;This definition here models `G: GetHost` as a literal function pointer,and the ability to close over the `&mut T` lifetime with type (not just`&mut U`) is expressed through the type constructor `type Data<'a>`).Ideally we could take a generic generic associated type (I'm not evensure what to call that), but that's not something Rust has today.Overall this felt like a much simpler way of modeling `GetHost` and itsrequirements. This plumbed well throughout the WASIp3 work and thesignatures for concurrent functions felt much more appropriate in termsof complexity after this change. Taking this change to the limit meansthat `GetHost` in its entirety could be purged since all usages of itcould be replaced with `fn(&mut T) -> D::Data<'a>`, a hopefully muchmore understandable type.This change is not all rainbows however, there are some gotchas thatremain:* One is that all `add_to_linker` generated functions have a `D: HasData` type parameter. This type parameter cannot be inferred and must always be explicitly specified, and it's not easy to know what to supply here without reading documentation. Actually supplying the type parameter is quite easy once you know what to do (and what to fill in), but it may involve defining a small struct with a custom `HasData` implementation which can be non-obvious.* Another is that the `G: GetHost` value was previously a full Rust closure, but now it's transitioning to a function pointer. This is done in preparation for WASIp3 work where the function needs to be passed around, and doing that behind a generic parameter is more effort than it's worth. This means that embedders relying on the true closure-like nature here will have to update to using a function pointer instead.* The function pointer is stored in locations that require `'static`, and while `fn(T)` might be expected to be `'static` regardless of `T` is is, in fact, not. This means that practically `add_to_linker` requires `T: 'static`. Relative to just before this change this is a possible regression in functionality, but there orthogonal reasons beyond just this that we want to start requiring `T: 'static` anyway. That means that this isn't actually a regression relative to #10760, a related change.The first point is partially ameliorated with WASIp3 work insofar thatthe `D` type parameter will start serving as a location to specify whereconcurrent implementations are found. These concurrent methods don'ttake `&mut self` but instead are implemented for `T: HasData` types. Inthat sense it's more justified to have this weird type parameter, but inthe meantime without this support it'll feel a bit odd to have thislittle type parameter hanging off the side.This change has been integrated into the WASIp3 prototyping repositorywith success. This has additionally been integrated into the Spinembedding which has one of the more complicated reliances on`*_get_host` functions known. Given that it's expected that while thisis not necessarily a trivial change to rebase over it should at least bepossible.Finally the `HasData` trait here has been included with what I'm hopingis a sufficient amount of documentation to at least give folks a springboard to understand it. If folks have confusion about this `D` typeparameter my hope is they'll make their way to `HasData` which showcasesvarious patterns for "librarifying" host implementations of WITinterfaces. These patterns are all used throughout Wasmtime and WASIcurrently in crates and tests and such.* Update expanded test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

636435f1 - async/stream/future support for wasmtime-wit-bindgen (#10044)

Wed, 22 Jan 2025 17:19:46 +0000

async/stream/future support for wasmtime-wit-bindgen (#10044)* async/stream/future support for wasmtime-wit-bindgenI've split this out of #9582 to make review easier.This patch adds async/stream/future/error-context support to the host bindinggenerator, along with placeholder type and function definitions in the`wasmtime` crate which the generated bindings can refer to. Seehttps://github.com/dicej/rfcs/blob/component-async/accepted/component-model-async.md#componentbindgen-updatesfor the design and rationale.Note that I've added temporary `[patch.crates-io]` overrides in Cargo.toml untilhttps://github.com/bytecodealliance/wit-bindgen/pull/1130 andhttps://github.com/bytecodealliance/wasm-tools/pull/1978 have been released.Also note that we emit a `T: 'static` bound for `AsContextMut` whengenerating bindings with `concurrent_imports: true`. This is only because`rustc` insists that the closure we're passing to`LinkerInstance::func_wrap_concurrent` captures the lifetime of `T` despite mybest efforts to convince it otherwise. Alex and I suspect this is a limitationin the compiler, and I asked about it on the rust-lang Zulip, but we haven'tbeen able to determine a workaround so far.Signed-off-by: Joel Dice remove obsolete TODO commentSigned-off-by: Joel Dice make `futures` dep optionalSigned-off-by: Joel Dice update `wasm-tools` and `wit-bindgen`Signed-off-by: Joel Dice * run cargo vetSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

71cb94be - Burn down the `allow_attributes_without_reason` backlog (#9712)

Tue, 03 Dec 2024 16:57:45 +0000

Burn down the `allow_attributes_without_reason` backlog (#9712)* Burn down the `allow_attributes_without_reason` backlogJust a bit, not everything fixed.* Fix wasi-nn annotations* Tweak `#[cfg]` List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

a13d7823 - feat: component bindgen: add support for multiple wit paths (#9288)

Tue, 24 Sep 2024 17:55:10 +0000

feat: component bindgen: add support for multiple wit paths (#9288)* feat: bindgen: add support for multiple wit paths* expanded tests* fmt---------Co-authored-by: Lochlan Wansbrough <> List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

e38ffa19 - wit-bindgen: Don't trace values containing lists by default. (#9262)

Tue, 17 Sep 2024 17:10:37 +0000

wit-bindgen: Don't trace values containing lists by default. (#9262)* wit-bindgen: Don't trace values containing lists by default.`list` values in Wit interfaces can represent things like HTTP bodieswhich can be very large. To enable tracing without spamming logfileswith all this data, put printing of values containing `list`s behinda separate `verbose_tracing` option.This is a coarse-grained approach; but it seems like a pretty gooddefault for tracing, and enabling full tracing when one needs it isstraightforward.In the future, we may want to refine the option by implementingthe `Valuable` trait and using `tracing::field::valuable`, whichcould allow us to do things like print non-`list` fields of recordsthat otherwise contain `list`s.* Use `option_type_contains_lists` more.* Hook up `verbose_tracing` to the macro.* Update expected outputs for tests. List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

5f3597ea - Improve name lookup for `trappable_error_type` configuration (#8833)

Tue, 18 Jun 2024 15:45:47 +0000

Improve name lookup for `trappable_error_type` configuration (#8833)This commit improves the experience around using the`trappable_error_type` configuration by fixing two issues:* When an error can't be resolved it doesn't result in a `unwrap()`, instead a first-class error is returned to get reported.* The name lookup procedure is now consistent with the name lookup that the `with` key does, notably allowing the version to be optional but still supporting the version.This fixes an issue that came up recently where a path with a versionwas specified but the old lookup logic ended up requiring that theversion wasn't specified because there was only one package with thatversion. This behavior resulted in a panic with a very longbacktrace-based error message which was confusing to parse. By returningan error the error is much more succinct and by supporting more namesthe original intuition will work. List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

54d36958 - Always generate the same output structure with `bindgen!` (#8721)

Fri, 31 May 2024 19:53:52 +0000

Always generate the same output structure with `bindgen!` (#8721)Currently with the `bindgen!` macro when the `with` key is used then thegenerated bindings are different than if the `with` key was not used.Not only for replacement purposes but the generated bindings are missingtwo key pieces:* In the generated `add_to_linker` functions bounds and invocations of `with`-overridden interfaces are all missing. This means that the generated `add_to_linker` functions don't actually represent the full world.* The generated module hierarchy has "holes" for all the modules that are overridden. While it's mostly a minor inconvenience it's also easy enough to generate everything via `pub use` to have everything hooked up correctly.After this PR it means that each `bindgen!` macro should, in isolation,work for any other `bindgen!` macro invocation. It shouldn't benecessary to weave things together and remember how each macro wasinvoked along the way. This is primarily to unblock #8715 which isrunning into a case where tcp/udp are generated as sync but theirdependency, `wasi:sockets/network`, is used from an upstream asyncversion. The generated `add_to_linker` does not compile because tcp/udpdepend on `wasi:sockets/network` isn't added to the linker. After fixingthat it then required more modules to be generated, hence this PR. List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

3e4b0b9c - Fix missing additional derives (#8482)

Fri, 26 Apr 2024 00:03:01 +0000

Fix missing additional derives (#8482)Signed-off-by: Brian H List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

7de48789 - Support additional_derives option in bindgen (#8441)

Tue, 23 Apr 2024 17:13:30 +0000

Support additional_derives option in bindgen (#8441)Signed-off-by: Brian H List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

67adf149 - Update nightly used in CI and fix warnings (#8416)

Fri, 19 Apr 2024 20:16:47 +0000

Update nightly used in CI and fix warnings (#8416)Fixes some warnings that nightly Rust has started emitting. List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs

1cf0060b - Disable traps by default in `bindgen!` imports (#8310)

Wed, 10 Apr 2024 19:38:57 +0000

Disable traps by default in `bindgen!` imports (#8310)By default previously all return types were wrapped in`wasmtime::Result` to enable any import to return a trap to the wasmguest. This is a fair bit of boilerplate, however, and it's easy toaccidentally turn a normal error into a trap. This is additionallysomewhat of a power-user method as many imports probably don't end upwanting to trap.This commit adds a new configuration option to `bindgen!`:`trappable_imports`, and switches the default to `false`. The previousbehavior can be recovered with `trappable_imports: true`. List of files: /wasmtime-44.0.1/crates/component-macro/tests/codegen.rs