public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Thomas Schwinge <tschwinge@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc/devel/rust/master] Merge #1408 #1503 #1511
Date: Wed, 31 Aug 2022 10:41:35 +0000 (GMT)	[thread overview]
Message-ID: <20220831104135.EA2EA3851142@sourceware.org> (raw)

https://gcc.gnu.org/g:ebb127f2aed32f21a37b31e8a5330defc6bfe5e7

commit ebb127f2aed32f21a37b31e8a5330defc6bfe5e7
Merge: 45f80a2d86c 2a607410e59 fc82b68cc1e 702bb4bb01b
Author: bors[bot] <26634292+bors[bot]@users.noreply.github.com>
Date:   Wed Aug 31 09:47:45 2022 +0000

    Merge #1408 #1503 #1511
    
    1408: Experiment: add optional error codes to diagnostics r=CohenArthur a=davidmalcolm
    
    rustc has error codes to identify specific errors, with URLs documenting each error.
    
    In GCC 13 I've extended GCC's diagnostic subsystem so that a diagnostic can be associated with zero or more `diagnostic_metadata::rule` instances, which have a textual description and a URL.  I meant this for rules in coding standards and specifications, but it struck me that potentially gccrs could reuse the same error codes as rustc.
    
    The following pull request implements an experimental form of this; I picked a single error at random: [E0054](https://doc.rust-lang.org/error-index.html#E0054).
    
    With this patch, gccrs emits e.g.:
    
    ```
    bad_as_bool_char.rs:8:19: error: invalid cast [u8] to [bool] [E0054]
        8 |   let nb = 0u8 as bool;
          |            ~      ^
    
    ```
    where the trailing [E0054] is colorized, and, in a suitably capable terminal is a clickable URL to https://doc.rust-lang.org/error-index.html#E0054.
    
    The error code is after the diagnostic message, whereas rustc puts it after the word "error".  I could change that in gcc's diagnostic.cc, perhaps.
    
    I'm not sure if this is a good idea (e.g. is it OK and maintainable to share error codes with rustc?), but thought it was worth sharing.
    
    
    1503: Add overflow traps r=CohenArthur a=CohenArthur
    
    Opening as a draft since the code is really ugly and some tests still fail. I am looking for feedback on the implementation and my approximative use of functions like `temporary_variable` which I feel I might be using the wrong way.
    
    I'll open up an issue of what still needs to be done, namely:
    - [x] Properly handle sub and mul operations
    - [ ] Disable the check in `release` mode (`-frust-disable-overflow-checks`)
    - [ ] Handle specific rust overflow attribute (needs checkup on the name)
    
    I'll open up some PRs to clean up some parts of the backend as well.
    
    1511: lint: Do not emit unused warnings for public items r=CohenArthur a=CohenArthur
    
    This fixes the overzealous warnings on public items from the unused pass
    
    Co-authored-by: David Malcolm <dmalcolm@redhat.com>
    Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>

Diff:

 .github/bors_log_expected_warnings                 |   2 +-
 gcc/diagnostic-core.h                              |   3 +
 gcc/diagnostic.cc                                  |  15 ++
 gcc/rust/backend/rust-builtins.h                   |  51 +++++--
 gcc/rust/backend/rust-compile-expr.cc              |  55 +++++--
 gcc/rust/backend/rust-compile-item.cc              |   6 +
 gcc/rust/backend/rust-compile-type.cc              |   4 +
 gcc/rust/checks/lints/rust-lint-scan-deadcode.h    |   9 +-
 gcc/rust/rust-backend.h                            |  19 ++-
 gcc/rust/rust-diagnostics.cc                       |  11 ++
 gcc/rust/rust-diagnostics.h                        |  18 +++
 gcc/rust/rust-gcc-diagnostics.cc                   |  33 ++++
 gcc/rust/rust-gcc.cc                               | 170 +++++++++++++++------
 gcc/rust/rust-gcc.h                                |  58 +++++++
 gcc/rust/typecheck/rust-casts.cc                   |   2 +-
 gcc/testsuite/rust/compile/bad_as_bool_char.rs     |   4 +-
 gcc/testsuite/rust/compile/issue-1031.rs           |   2 -
 gcc/testsuite/rust/compile/issue-1289.rs           |   2 -
 gcc/testsuite/rust/compile/privacy7.rs             |   9 ++
 gcc/testsuite/rust/compile/test_mod.rs             |   1 -
 .../rust/compile/torture/raw_identifiers.rs        |   4 +-
 .../compile/torture/raw_identifiers_keywords.rs    |   4 +-
 gcc/testsuite/rust/debug/win64-abi.rs              |   8 +-
 .../torture/macro-issue1426.rs                     |   9 +-
 gcc/testsuite/rust/execute/torture/overflow1.rs    |  20 +++
 25 files changed, 420 insertions(+), 99 deletions(-)

                 reply	other threads:[~2022-08-31 10:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220831104135.EA2EA3851142@sourceware.org \
    --to=tschwinge@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).