Standardize Changelog content by kirtchev-adacore · Pull Request #691 · rust-lang/fls

kirtchev-adacore · 2026-04-06T10:07:38Z

This MR updates the contents of the Changelog to follow the instructions given in the Developer Guide.

Closes #690

tshepang · 2026-04-07T03:15:39Z

I do wonder, should we refer to it as FLS or the FLS

outside the scope of FLS

outside the scope of the FLS

If you spell out FLS, then "outside the scope of the Functional Language Specification" is proper English. So I think "the FLS" is correct. But then again English is not my native language...

@traviscross what do you think

"The FLS" is correct.

tshepang · 2026-04-07T03:51:03Z

+- `Show a warning when \`-Ctarget-feature\` is used to toggle features that can lead to unsoundness due to ABI mismatches <https://github.com/rust-lang/rust/pull/129884>`_

-  * No change: `target-feature` is outside the scope of the FLS
+  - Code generation options are  is outside the scope of the FLS.


I think they should be. What should be outside the scope is the command line part of this, since FLS only documents lang behavior, but not tool use.

Maybe something like...

Tool usage is outside the scope of the FLS.

Any details about a conforming tool should be outside the scope of the FLS, including code generation options.

Some code generation options are at language level (as in, visible in the source code), and those would be in scope I think. Am looking at https://rust-lang.github.io/fls/attributes.html#code-generation-attributes.

Note that what you linked are code generation attributes, which are within the scope of the FLS.

-Ctarget-feature is a code generation option, which should not be documented in the FLS. Hence my proposed wording.

I think then we should use more generic wording, to be more clear, because being this specific, like "Code generation options are not in scope", could imply some command line options are in scope.

Could you post your suggested wording? I feel like I am trying to guess what you are thinking of.

see #691 (comment)

I incorporated your suggestion.

tshepang · 2026-04-07T04:29:36Z

+- `Stabilize \`#[cfg(target_abi = ...)]\` <https://github.com/rust-lang/rust/pull/119590/>`_

-  * No change: ``cfg`` and ``cfg_attr`` configuration predicates are not part of the FLS
+  - Configuration predicates are outside the scope of the FLS.


this is outside the scope of this PR (pun), but it does not sound true, does it

I do not understand what you mean. We document configuration predicates as part of cfg and cfg_attr, and we define them as

A configuration predicate is a construct that evaluates statically to either true or false, and controls conditional compilation.

Are you trying to say that individual configuration options are outside the scope of the FLS?

the claim is that "Configuration predicates are outside the scope of the FLS", but it would be outside the scope of this PR to change that claim, since it only changes message format

I think the proper wording should be "Configuration options are outside the scope of the FLS.". What do you think?

if that is referring to command line options (tool use), yeah, but this is not the case here, or is it

The text I proposed is referring to

ConfigurationOption ::= ConfigurationOptionName ConfigurationOptionValue?

but now I am noticing that we do not define the term "configuration option".

in that case, those are in scope (I believe)

note that I was not suggesting a change here, but more a confirmation that this changelog entry is wrong (but I am not very confident)

The FLS does not list specific configuration options. All it says is

The evaluation of a configuration option is tool-defined.

The syntax is in scope, but the actual pairs of option names and option values are not, because they are tool-specific.

Oh, I see, thanks. I should look at improving that text... it's not so clear to me.

In the mean time, I updated the changelog entry.

tshepang · 2026-04-07T04:35:07Z

+- `Remove unnecessary type inference when using associated types inside of higher ranked \`where\`-bounds <https://github.com/rust-lang/rust/pull/119849>`_

-  * No change: the FLS does not specify type inference to such a degree
+  - Concrete type inference resolution is outside the scope of the FLS.


is it called type inference resolution

note: there are other uses of the term in this pr

I changed the occurrences into "The mechanism of type inference resolution is outside the scope of the FLS."

my question is more on "resolution"... it's not a word I have seen used with "type inference"

After skimming through the related PR, this looks like a compiler bug fix. Agreed?

I would not call call it a bug. It is, however, a behavior change that delves more deep than the FLS cares to describe.

My comment here, though, was about the inclusion of the word, "resolution".

OK. I reworded the text to be similar to the original.

just a note that other instances of "type inference resolution" introduced by this pr remain

rustbot · 2026-04-07T12:24:36Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

tshepang

last consistency nits, and this is good enough for me

View changes since this review

tshepang · 2026-04-08T10:39:51Z

 - `Revert “Update wasm-related dependencies in CI” <https://github.com/rust-lang/rust/pull/152259>`_

-  - No change: the target is outside the scope of FLS
+  - The target is outside the scope of FLS.


Suggested change

- The target is outside the scope of FLS.

- The target is outside the scope of the FLS.

tshepang · 2026-04-08T10:40:07Z

 - `Stabilize several s390x vector-related target features and the is_s390x_feature_detected! macro <https://github.com/rust-lang/rust/pull/145656>`_

-  - No change: the target is outside the scope of FLS
+  - The target is outside the scope of FLS.


Suggested change

- The target is outside the scope of FLS.

- The target is outside the scope of the FLS.

tshepang · 2026-04-08T10:40:28Z

 - `Add warn-by-default const_item_interior_mutations lint to warn against calls which mutate interior mutable const items <https://github.com/rust-lang/rust/pull/148407>`_

-  - Lints are outside the scope of FLS
+  - Lints are outside the scope of FLS.


Suggested change

- Lints are outside the scope of FLS.

- Lints are outside the scope of the FLS.

tshepang · 2026-04-08T10:40:37Z

 - `Add warn-by-default function_casts_as_integer lint <https://github.com/rust-lang/rust/pull/141470>`_

-  - Lints are outside the scope of FLS
+  - Lints are outside the scope of FLS.


Suggested change

- Lints are outside the scope of FLS.

- Lints are outside the scope of the FLS.

This MR updates the contents of the Changelog to follow the instructions given in the Developer Guide. Closes rust-lang#690

tshepang · 2026-04-08T14:35:53Z

this was more work than I expected... thanks @kirtchev-adacore

kirtchev-adacore self-assigned this Apr 6, 2026

kirtchev-adacore force-pushed the fls-690-standardize-changelog branch 2 times, most recently from ab01740 to 3fdb09e Compare April 6, 2026 10:19

kirtchev-adacore requested review from PLeVasseur and tshepang April 6, 2026 10:19